Smashing Podcast Episode 25 с Энтони Камполо: что такое RedwoodJS?

Мы говорим о RedwoodJS. Что именно означает быть полнофункциональным фреймворком Jamstack? Я поговорил с чемпионом сообщества Энтони Камполо, чтобы выяснить это.

Показать примечания

• РедвудJS
• Энтони в Твиттере
• Серия статей Энтони «Первый взгляд на RedwoodJS»

Еженедельное обновление

• «Введение в программный запуск Lighthouse»
  автор Кэти Боуман
• «Анимация компонентов React с помощью GreenSock»
  автор Блессинг Крофега
• «Дизайн для внимания»
  автор Виктор Йокко
• «Расширенное использование GraphQL на веб-сайтах Gatsby»
  автор Алим Исиака
• «Сравнение методов оформления в Next.js»
  автор Адебии Адедотун

Стенограмма

Дрю Маклеллан: Он учится в школе Lambda, изучает веб-разработку с полным стеком, а также является участником RedwoodJS. Что-то вроде чемпиона сообщества, недавно он написал серию статей из 12 частей под названием «Первый взгляд на RedwoodJS», которая помогает объяснить происхождение и мотивы Redwood, а также множество различных концепций, которые вводит фреймворк. Итак, мы знаем, что он эксперт в RedwoodJS, но знаете ли вы, что он никогда не видел собак? Мои потрясающие друзья, пожалуйста, поприветствуйте Энтони Камполо.

Дрю: Привет, Энтони. Как твои дела?

Энтони Камполо: Здравствуйте. Я разбиваю, большое спасибо, что вы со мной.

Дрю: Я хотел поговорить с вами сегодня о RedwoodJS, и это, вероятно, очевидно из вступления. Для тех, кто раньше не слышал о RedwoodJS, на высоком уровне, что это такое?

Энтони: Я думаю, что есть несколько способов, которыми вы можете описать это в зависимости от того, откуда приходят люди, но каноническое определение — это бессерверный фреймворк с полным стеком для Jamstack. Таким образом, он сочетает в себе полнофункциональную веб-разработку с бессерверными вещами типа AWS Lambda и Jamstack, что в наши дни очень важно.

Дрю: Итак, это фреймворк с полным стеком, который пытается объединить множество идей вокруг экосистемы разработки Jamstack? Это правильно?

Энтони: Да, это раздвигает границы того, чем может быть приложение Jamstack, поэтому, называя его полным стеком, Jamstack, речь идет о том, как мы можем выйти за рамки только внешнего интерфейса и иметь такую ​​же парадигму развертывания, когда просто получаешь толчок, получаешь весь ваш код развернут. Как мы можем получить это, а также с нашим бэкендом, и как все это будет связано?

Дрю: Теперь, прежде чем мы углубимся в это, я думаю, довольно интересно услышать, что это от довольно опытной команды, не так ли? Люди, стоящие за Редвудом, не весенние цыплята. Не сказать, что они старые, но они были повсюду, не так ли, с точки зрения веб-разработки?

Энтони: Они приправлены. Да, на самом деле я потратил приличное количество времени на то, чтобы написать об истории фреймворка и идеях, которые привели к нему, а Том Престон-Вернер — его создатель, поэтому он также известен как создатель Jekyll, который является действительно влиятельным генератором статических сайтов. Он также сделал TOML, язык файлов конфигурации. И изначально он был генеральным директором GitHub. Итак, его работа со страницами Jekyll и GitHub и подобными вещами, я думаю, действительно привела к тому, что мы теперь называем Jamstack. Многие люди сказали бы: «О, Jamstack новинка. Они делали это всегда». Вот как мы говорили о том, как это расширение этих старых идей, статических поколений сайтов, но с GraphQL и без сервера, и этих идей о том, как использовать связующий код и API, чтобы заставить ваше приложение работать.

Дрю: Значит, это определенно от людей, которые тесно связаны с этим сообществом? Я имею в виду, что, генеральный директор GitHub, вы действительно не можете больше влиться в сообщество с открытым исходным кодом, чем это. Итак, Redwood — это фреймворк с полным стеком, и я думаю, это означает, что у вас есть код Redwood, работающий во внешнем и внутреннем интерфейсе. Это правильно?

Энтони: Да, первое, что я люблю объяснять людям, когда показываю им проект Redwood, это то, что это монорепозиторий. Итак, у вас есть ваш интерфейс и ваш сервер в одном и том же репо, и затем каждый из них живет в своих собственных папках. У вас есть веб-папка, которая является вашим внешним интерфейсом, и она очень похожа на то, что вы получаете из приложения Create React. Затем у вас есть папка API, которая является вашей серверной частью, и именно здесь все ваши функции по существу помещаются в один большой обработчик GraphQL, который развертывается в AWS Lambda через Netlify.

Дрю: Итак, начнем с самого начала, как вы упомянули, оно основано на React. Это React плюс куча кода Redwood или просто React? Какой там баланс?

Энтони: Это много вещей. Это определенно просто React в том смысле, что вы не добавляете много библиотек управления состоянием, на самом деле вы даже не используете маршрутизатор. У них есть собственный маршрутизатор, который они написали, и они используют много материалов GraphQL. Итак, когда люди говорят о React, GraphQL и их друзьях, это то, что здесь происходит, это то, что он дает вам множество интеграций по умолчанию, чтобы заставить React общаться с вашим GraphQL. Потому что теперь у нас есть много соглашений о том, как использовать React, но выборка данных по-прежнему доставляет массу хлопот.

Дрю: Итак, это React, настроенный с кучей других инструментов, которые хорошо работают с React, чтобы предоставить вам функционирующую экосистему для выполнения этого конкретного стиля задач. Это справедливое описание?

Энтони: Да, нет, да, это отличный способ выразить это. Как сказал Том, существуют все эти лучшие в своем классе решения, а также действительно сложные инструменты и технологии, которые мы можем использовать, но на самом деле их действительно сложно использовать, потому что у вас такие огромные начальные затраты и необходимость их изучения. , нужно выяснить, как их интегрировать. Итак, они поставили слоган: «Мы делаем конфигурацию вашего веб-пакета для вас».

Дрю: Я думаю, что это обычная боль, которую вы слышите от многих людей, когда они пытаются начать работу в современной среде разработки с приложениями JavaScript на стороне клиента и настройкой веб-пакета, настройкой всех различных вещей, процессов сборки, построить шаги. Это может быть настоящим минным полем, не так ли, чтобы все соединилось вместе и заработало? И это далеко, прежде чем вы доберетесь до «Hello, World!». Итак, Redwood дает нам все это предварительно сконфигурированное?

Энтони: Да, это скорее соглашение, а не идея типа конфигурации, потому что у вас есть… Том был, например, он построил GitHub с Ruby on Rails, а Роб, один из других основных участников, он всегда был разработчиком Rails. У них есть много идей, с которыми они философски согласуются в терминах Rails, но они хотят взять это соглашение за идеи конфигурации, идеи фреймворка полного стека и реализовать это со всеми современными технологиями, которые у нас есть сейчас.

Дрю: Итак, вы упомянули, что Redwood дает вам маршрутизатор или маршрутизатор, как мы говорим на этой стороне пруда, он поставляется с такими вещами, как компоненты по умолчанию и что-то в этом роде в React, или вы просто реализовать все это самостоятельно?

Энтони: Да, роутер очень сложный. Он делает большую часть вещей, которые вы могли бы получить только от маршрутизатора React, у него просто разные идеи с точки зрения того, как это должно быть реализовано, потому что Next у них также есть свой собственный маршрутизатор, и до сих пор не совсем понятно, как мы хотите, чтобы наша одностраничная маршрутизация приложений работала. Из-за Suspense у вас возникает много подобных вопросов о том, где будут появляться асинхронные вещи? У нас с Редвудом есть идея ячейки, и это то, что действительно делает ваши данные доступными для вас.

Дрю: Итак, может быть, мы могли бы немного углубиться в это? Что такое клетка с точки зрения Редвуда?

Энтони: Да, поэтому ячейка — это способ по умолчанию написать запрос GraphQL, а затем ваша страница в основном сообщает, получаете ли вы данные обратно, получаете ли вы сообщение об ошибке, находитесь ли вы в состоянии загрузки, то ли... Есть еще одно состояние, забыл. Но да, так что это дает вам различные состояния, в которых вы можете находиться, в зависимости от того, получаете ли вы свои данные или нет. Это установка с Аполлоном под одеялом. Итак, если вы используете Redwood, вы используете Apollo в качестве своего клиента GraphQL, но вам никогда не нужно об этом думать. Вам никогда не нужно писать какой-либо Apollo или даже думать об этом, все это встроено. Он позволяет вам просто писать запросы GraphQL, что было действительно мечтой о том, почему люди хотели GraphQL, потому что это был действительно простой язык запросов, который разработчики интерфейса мог бы использовать. Но затем вам нужно было выяснить, как настроить сервер GraphQL, вам нужно было выяснить все эти другие вещи и как все это подключить. Таким образом, он выполняет всю интеграцию GraphQL за вас, поэтому вы можете просто написать GraphQL, вам даже не нужно думать о том, как мне реализовать GraphQL.

Дрю: Итак, я полагаю, что одна из классических задач фреймворка состоит в том, чтобы взять весь шаблонный код, который вы могли бы написать самостоятельно, и реализовать его для себя, а также очистить путь за кулисами, чтобы вам никогда не приходилось смотреть на этот шаблонный шаблон. когда-либо, и вы можете просто написать код, который уникален для ваших обстоятельств. Я думаю, это то, что происходит с ячейкой, не так ли? Здесь нет ничего революционного, вы можете настроить компонент React так, чтобы он имел все эти разные состояния, и вы могли бы подключить Apollo, и вы могли бы сделать все это самостоятельно, но на самом деле это довольно много работы, и это общий шаблон. Итак, Редвуд привел в порядок красивый шаблон многократного использования, который вы можете просто начать использовать, не задумываясь об этом. Это хорошее описание?

Энтони: Да, они придумали название, но они определенно признают, что это была практика, которую они часто видели, и что они видели, что многие люди просто кодируют ее сами, и они решили, что им нужен декларативный способ получения ваших данных. Итак, вот почему у вас есть эта настройка, потому что она позволяет вам просто иметь разные состояния, и вам не нужно делать логику если/то, чтобы выяснить, нужно сделать это, если это произойдет. Итак, речь идет о том, чтобы иметь единственный способ объявить все различные состояния, в которых могут находиться ваши данные, когда вы их загружаете.

Дрю: Это одна из характеристик React, не так ли? React не пытается дать вам архитектуру для вашего проекта, он позволяет вам решить, как вы собираетесь структурировать вещи. В этом, конечно, есть плюсы и минусы. Но похоже, что Redwood навязывает вам часть этой структуры, чтобы вам не приходилось об этом думать, и чтобы она могла установить для вас сантехнику и как бы продолжить с того места, где React остановился с точки зрения предоставления вам такая структура.

Энтони: Да, и я думаю, что это действительно интересно, что мы видели несколько разных попыток решения этой проблемы, потому что я имею в виду, что у вас были люди, которые всегда говорили: «Почему нет Rails для JavaScript или Rails для React?» На Full Stack Radio есть отличное интервью между Майклом Ченом и Адамом Уотаном под названием React — это не конкурент Rails. Это один из различных фреймворков.

Энтони: Другие — это BlitzJS, который получил приличное количество слухов, а затем Bison — что-то новое и перспективное. Все они имеют похожий стек, но используют разные части. У вас будет запрос React вместо Apollo, или у вас будет Chakra вместо Tailwind. Люди, которые собирают все эти кусочки в свои стопки, все эти стопки как бы сражаются друг с другом, это очень дружеское соревнование. На самом деле, это одна вещь, которую я действительно ценю, это то, что мы действительно сотрудничаем между фреймворками. Там нет вражды.

Дрю: Итак, мы упомянули Apollo и GraphQL, Redwood довольно активно использует GraphQL как одну из основных частей фреймворка, не так ли? Мы, вероятно, можем посвятить целый выпуск подкаста только GraphQL, но для тех, кто не знаком, какую часть работы здесь делает GraphQL, какую проблему он решает в этом контексте?

Энтони: Да, это отличный вопрос. Когда я говорю людям, что они должны знать, чтобы хорошо начать работу с Redwood, я бы сказал, что вы должны были использовать приложение Create React, просто если вы создали приложение Create React и развернули его в Netlify или Версель, это даст тебе хороший старт. Затем узнайте хотя бы немного о GraphQL, потому что он занимает центральное место. Итак, GraphQL — это то, как ваш интерфейс будет общаться с вашим сервером. Они говорят, что это язык запросов для API, и идея состоит в том, что он должен быть альтернативой методам RESTful API, и что вместо того, чтобы делать то, что RESTful, вы отправляете запросы, которые точно определяют иерархическую структуру данных, которую вы хотите получить обратно. базу данных. Таким образом, требуется немного больше времени для запуска, чтобы заставить ваш сервер GraphQL общаться с двумя частями. Затем, как только вы это сделаете, разработчики внешнего интерфейса смогут получать данные гораздо более гибким способом. Вам не нужны все эти различные конечные точки API, которые должны создавать ваши серверные специалисты.

Дрю: Итак, если есть изменения в требованиях к внешнему интерфейсу, по-видимому, вы можете просто настроить свой запрос GraphQL, и вам не нужна помощь кого-то, кто работает на бэкэнде, чтобы внести это изменение для вас?

Энтони: Я имею в виду, настоящая мечта заключается в том, чтобы вы могли добавить к нему мобильный клиент, чтобы в конечном итоге он был настолько гибким, каким он становится, вы можете иметь несколько клиентов, которые общаются с вашим одним API. Ваш GraphQL API становится вашим источником правды, где вся ваша логика централизована. Затем вы можете построить все эти различные слои представления сверху.

Дрю: Итак, у нас есть GraphQL, дающий нам возможность запрашивать какую-то серверную часть. В Редвуде какая задняя часть?

Энтони: Ага. Есть несколько разных способов создать бэкэнд. Есть способ, которым вы выйдете из коробки с учебным пособием, а именно: вы используете базу данных Postgres, развернутую на Heroku, очень просто, супер просто. Затем ваше приложение Redwood взаимодействует с Prisma. Я не знаю, знакомы ли вы вообще с Prisma, но это похоже на O/RM. Они специально говорят, что это не O/RM, это построитель запросов, который находится на более низком уровне. Но просто для того, чтобы объяснить это людям, Prisma — это то, что позволяет вам общаться с вашей базой данных. Он выполняет ваши миграции и настраивает ваши таблицы. Он выполняет все функции SQL, поэтому вам не нужно писать SQL. Для меня это звучит как O/RM. Вам не обязательно использовать Prisma, чтобы использовать Redwood.

Энтони: На самом деле я создал приложение для проверки концепции, в котором вместо этого мы использовали FaunaDB. FaunaDB, у них есть собственный GraphQL API, так что вы можете просто отправить GraphQL API прямо в Fauna, а затем таким же образом внести изменения в свою базу данных. Вы теряете большую часть функциональности интерфейса командной строки Prisma, но Prisma действительно является фактором удобства, позволяющим действительно легко работать с вашей реляционной базой данных. Но на самом деле, все, о чем вы могли бы подумать, вы могли бы понять, как подключить его к Redwood, — это то, что я узнал только потому, что он построен на GraphQL, и весь смысл в том, чтобы иметь возможность общаться со всеми этими различными частями.

Дрю: Итак, Prisma — это, по сути, своего рода уровень абстракции между вашим кодом и любым хранилищем данных, которое вы используете, предположительно поддерживаемое Prisma, это… или оно делает более разумные вещи, чем это?

Энтони: Да, вы пишете схему, создаете файл schema.Prisma, и в нем будет запись о модели, а затем идентификатор, целое число и автоматический приращение, например, строка заголовка, строка тела, дата и время создания. . Таким образом, вы должны создать в своей базе данных то, что хотите, с типами, а затем она сделает за вас все, что нужно для базы данных, чтобы вам не приходилось взаимодействовать с базой данных.

Дрю: Итак, вы используете Prisma, чтобы определить, я думаю, с какой базой данных или хранилищем данных вы общаетесь. Затем там вы размещаете свои различные модели mvc, чтобы использовать этот язык. Итак, когда ваше приложение взаимодействует с хранилищами данных, оно как бы использует экземпляр клиента Prisma, не так ли? Это то, что происходит?

Энтони: Да. Да, это точно. Итак, в папке API вашей серверной части у вас есть папка lib с db.js, и только по умолчанию в ней настроен ваш клиент Prisma. Итак, это все, что вы получаете из коробки, и, как вы сказали, Prisma может работать с разными базами данных. Он может переключаться между SQLite для разработки и Postgres для производства и тому подобное. Сейчас это в основном отношения, но в дорожной карте есть такие вещи, как Mongo и Fauna.

Дрю: Итак, это очень полезно, если вы можете настроить и использовать SQLite в своей локальной среде разработки, пока вы запускаете и запускаете вещи, а затем запускаете что-то вроде MySQL.

Энтони: Это именно то, как настроен учебник, это рабочий процесс, который он вам показывает.

Дрю: Довольно интересно, не правда ли, увидеть очень современный подход к фреймворку, а затем вернуться к некоторым из этих более традиционных баз данных, таких как MySQL. Я хорошо знаком с MySQL. Мне нравится его стабильность и реляционный способ хранения данных. Я думаю, что это работает так хорошо для очень многих вещей. Часто вы видите выброшенного ребенка, который был водой из ванны, когда дело доходит до новых типов хранилищ данных, поэтому довольно интересно видеть, что Redwood по умолчанию поддерживает эти старые добрые реляционные базы данных.

Энтони: Да, нет, это такой хороший момент, потому что я говорю, что из всех новых вещей, которые Redwood объединяет вместе, есть некоторые вещи, которые на самом деле говорят, что старый, проверенный и верный способ на самом деле лучший. Итак, они действительно хороши в реляционных базах данных. Это исходит из опыта Тома в использовании Rails и наличии реляционной серверной части. Active Record был уровнем O/RM, к которому Prisma стремилась приблизиться.

Дрю: Думаю, мы говорим о бессерверной архитектуре здесь с Редвудом, и мы говорили с Крисом Койером, я думаю, два или три эпизода назад, все о бессерверном использовании API, облачных функциях и прочем. Итак, сделаем шаг назад, если бы вы думали о фреймворке на основе сервера, как мы упоминали Ruby on Rails или что-то вроде Laravel в мире PHP. Даже с внешним интерфейсом React ваш запрос API будет запускать код, который является кодом Rails или кодом Laravel, а затем вашим пользовательским кодом и конфигурацией. То же самое с Редвудом? Существует ли работающий серверный код Redwood или это просто дополнительные инструменты, структура и клей, которые позволяют вам реализовать свой собственный?

Энтони: Да, так что в бэкенде есть файл, специально предназначенный для вашего SDL, так что у вас есть свой язык определения схемы, а затем у вас есть то, что называется вашими сервисами, которые похожи на ваши методы для общения с вашими задний конец. Затем все это объединяется в обработчик GraphQL, который развертывается в одной функции Lambda. Итак, он оптимизирован специально для Lambda. На самом деле совсем недавно кто-то сделал это с бессерверной структурой, и у нас есть люди, работающие над Azure и Google Cloud. Это не функция Google Cloud, это функция, созданная поверх нее. Но да, так что прямо сейчас он в основном оптимизирован для развертывания вашей серверной части в качестве функции GraphQL в AWS Lambda. Это вся магия, происходящая в коде, который я не понимаю, но это объяснение высокого уровня.

Дрю: Итак, существуют инструменты развертывания, которые берут весь код, который вы написали, сжимают его вместе в какой-то волшебный шар кода, который можно выполнить в облаке, и размещают его на AWS, или вы все еще должны управлять этим процессом самостоятельно?

Энтони: Да, так что все это делается через Netlify, если вы будете следовать руководству. Вам действительно не нужно возиться с какими-либо бессерверными функциями. Все, что связывает вашу серверную часть вместе, чтобы вставить ее в AWS Lambda, обрабатывается, вам не нужно трогать какой-либо код. Все это сгенерировано из коробки в качестве ваших соглашений по вашим конфигурациям, поэтому вам действительно не нужно слишком много думать о том, как сделать его бессерверным. По умолчанию это без сервера. Это действительно сложно уложить в голове. Мне потребовалось некоторое время, чтобы обернуть вокруг себя голову.

Дрю: Да, потому что это важный момент, а не потому, что на самом деле сейчас есть несколько разных областей, которые мы здесь отслеживаем. У нас есть, я думаю, три разных области. У нас есть внешнее приложение React, которое работает в браузере, а затем у нас есть API на основе GraphQL, работающий как облачная функция, который отвечает на наши запросы, но затем взаимодействует с хранилищем данных. который использует Prisma. И это хранилище данных, что и где в этом, потому что вы не можете запустить сервер MySQL на Netlify, не так ли?

Энтони: Да, именно здесь появляется Heroku. Итак, в самой последней части руководства вы развертываете свой интерфейс в Netlify, а затем развертываете серверную часть в Heroku Postgres, и вы просто берете переменные конфигурации из Heroku, подключаете их. в Нетлайфай. Заставить интерфейс Netlify общаться с сервером Postgres очень и очень просто. Они хотели использовать то, что было бы проще всего раскрутить для всех, но при этом иметь хорошую стабильную, проверенную в боях технологию. В конце концов, то, что вы получаете из коробки, просто следуя инструкциям, действительно невероятно.

Дрю: Энтузиасты Jamstack должны быть знакомы с такими сервисами, как упомянутая вами FaunaDB, которая предоставляет хранилище данных в качестве API, у AWS есть DynamoDB, у Google есть Cloud SQL и так далее. Итак, вы упомянули, что Redwood рассматривает возможность интеграции, или, я полагаю, Prisma является тем компонентом, который планирует интеграцию с подобными сервисами в будущем?

Энтони: Да, это хороший вопрос. Это то, о чем я на самом деле разговаривал с Райаном Ченки из Prisma о том, как помочь: что это за история с базой данных для Redwood для вещей, которые не обязательно работают с Prisma? Было бы лучше найти способ заставить Redwood работать с ним напрямую, как я сделал с Fauna, или было бы разумнее реализовать драйвер для Prisma? Итак, есть разные подходы к этому. Очевидно, сейчас существует миллион различных баз данных, которые все хотят использовать, поэтому важно, насколько вы мотивированы разместить в них свое хранилище данных. Там много вкладов сообщества.

Дрю: Итак, поскольку Prisma понимает вашу модель и знает, как их запрашивать, может ли она генерировать какие-то миграции или что-то подобное, чтобы помочь вам настроить эту базу данных?

Энтони: Это именно то, что вы теряете, когда вам нужно вывести Prisma и получить свои данные, так это то, что вы теряете все функции миграции. У него действительно продвинутый интерфейс командной строки, который делает за вас массу вещей, поэтому вы можете пройти весь учебник Redwood и ввести команды Prisma, и вам не нужно иметь никакого представления о том, что он делает, он просто работает. Это действительно отличный инструмент для выполнения всего такого рода вещей типа базы данных, которые вы хотите убедиться, что вы делаете правильно, и вы хотите убедиться, что это сделано правильно.

Дрю: Кажется, что иметь действительно хороший инструментарий для работы с фреймворками — довольно современная тенденция, не так ли? Чтобы не просто сказать: «Вот все, что может сделать этот фреймворк, но, возможно, вот некоторые инструменты CLI, которые сделают за вас целую кучу». Есть ли у Redwood инструменты для таких вещей, как генераторы командной строки и прочее, которые помогут вам быстро начать работу?

Энтони: Это, вероятно, самая большая ключевая особенность, которую вы получаете от Redwood, — вы получаете целый набор очень сложных генераторов. Для тех, кто когда-либо видел оригинальную демонстрацию Ruby on Rails, которую дал DHH, он создает блог примерно за 15 минут и делает все это с помощью Rails, и люди говорят: «Вау, это потрясающе». Это эффект, с которым работает Редвуд. Они хотят, чтобы вы могли очень быстро раскручивать все, чтобы вы могли генерировать страницы, макеты, создавать свои ячейки, о которых я говорил, и выполнять команду scaffold, которая будет создавать все ваши CRUD-интерфейс. У меня есть целый раздел, четвертая часть серии блогов, в которой просто объясняется весь код, который дает вам скаффолд. Это дает вам так много кода. Есть генератор выключения, есть даже генератор попутного ветра, который настраивает для вас ваш попутный ветер.

Дрю: Это потрясающе. Я помню, как видел демо-версию Rails от DHH. Я имею в виду, это было, вероятно, что, 15 лет назад, когда он впервые сделал эти леса и показал вам, и вы получаете довольно примитивную, но функциональную панель управления, позволяющую вам создавать новые элементы, редактировать их, удалять их и так далее. . Это может быть неоценимо в проекте, особенно при работе в своего рода динамической среде, где, ладно, может быть, вы собираетесь внедрить лучшие инструменты в будущем для редактирования этого контента, но это означает, что вы можете быстро что-то раскрутить, вы можете получить тестовые данные, или вы даже можете передать их команде по контенту, которая может начать работать, пока вы работаете над внешним интерфейсом, так что это действительно полезно.

Дрю: Если вы хотите просто развернуть это и использовать в продакшне, вероятно, вы можете просто развернуть его вместе со своим интерфейсным кодом, но вам нужен какой-то способ защитить этот аспект, эти корни в вашем приложении.

Энтони: Да, есть несколько разных вариантов аутентификации. Вы можете использовать идентификацию Netlify. Это значение по умолчанию, если вы перейдете к учебнику, а затем вы также можете использовать Auth0, а затем тот, с которым я не знаком, называется Magic.Link, и, вероятно, в будущем будет добавлено несколько дополнительных. Но да, так что там уже есть пара встроенных решений, и это самое последнее, что вы делаете, так что самая последняя часть всей моей серии блогов из 12 частей — это Auth. Я не думаю, что когда-либо разбирался в Auth до того, как использовал Redwood. Это сложно, и они определенно хорошо с этим справились.

Дрю: Это интегрируется на уровне маршрута или на уровне маршрута, простите, как вы обеспечиваете безопасность?

Энтони: Да, часть того, что у них есть собственный маршрутизатор, у них также есть… Вы можете создавать частные маршруты, поэтому у них есть компонент частного маршрута. Затем ваша фактическая форма входа, это то, что вы получаете от удостоверения Netlify, поэтому вам не нужно фактически создавать форму и управлять своим состоянием с ее помощью, вот где в игру вступает множество проблем. Убрав действительно ключевые части, вы можете просто реализовать доступ на основе ролей. У нас есть дополнение к управлению доступом на основе ролей, которое было сделано за последние пару недель Дэвидом Т. Итак, сейчас много работы по созданию других способов сделать это, но то, что они получили сейчас, уже… это работает, это ' Я сделаю тебя функциональным.

Дрю: Люди всегда говорят о криптографии хеширования алгоритмов безопасности, что вы никогда не должны писать свои собственные, потому что они никогда не будут такими же хорошими, как существующие. Я все чаще думаю, что это верно и для аутентификации на более высоком уровне; что аутентификация в наши дни является настолько сложной областью, что люди хотят не просто войти на ваш сайт с уникальными учетными данными, но они могут захотеть пройти аутентификацию с помощью Google, или они могут захотеть пройти аутентификацию с помощью устройства Apple, или они могут захотеть двухфакторную аутентификацию , или они могут захотеть интегрировать его со службой единого входа, которую они используют на предприятии. Все эти вещи являются такой головной болью, если вы пытаетесь реализовать это самостоятельно, и так много возможностей сделать что-то не так и выявить дыры в безопасности в вашем приложении, что использование службы аутентификации кажется мне на данный момент почти не проблематичным. Таким образом, просто возможность добавить что-то с помощью нескольких строк кода и быть в рабочем состоянии звучит как действительно продуктивный способ работы и обеспечения безопасности.

Дрю: Похоже, что развертывание как внешнего интерфейса, так и серверных аспектов, бессерверных функций, естественным образом подходит для развертывания в Netlify. Вы связаны этим с Редвудом? Я имею в виду, мы упоминали, что Том Престон-Вернер является одним из основных сторонников этой структуры, он также входит в совет директоров Netlify. Как вы думаете, есть ли вероятность слишком тесной связи, если вы выберете Редвуд в качестве основы для проекта?

Энтони: Да, Том определенно осознает это. Он инвестировал во множество компаний, которые плавают вокруг. Он инвестировал в Prisma и Fauna. Он хочет просто делать инструменты, которые он хочет использовать. Дело не в том, что мы хотим запереть вас в этом, а в том, что Netlify построил, он считает, что это лучший вариант, поэтому они построили вокруг этого. Но они не хотят, чтобы он был привязан к какой-либо одной цели развертывания, и именно поэтому мы проводим работу над такими вещами, как бессерверная среда, и некоторые люди говорили о Begin. Мы хотим быть прагматичными, мы хотим, чтобы это работало для любого варианта использования. Итак, мы выполнили 90% работы, а затем вам просто нужно подключить последние пару вещей, чтобы заставить его работать с любым сервером по вашему выбору.

Дрю: Я полагаю, что даже Netlify использует AWS Lambda для серверных функций, поэтому Redwood позаботится о развертывании, и на самом деле вы можете развернуть его в Lambda самостоятельно. Публикация вашего внешнего интерфейса — это просто файлы, не так ли, все остальное основано на CDN? Таким образом, здесь довольно много гибкости, не слишком привязанной.

Энтони: Да, на самом деле есть термин, о котором Том говорит как об основной философской идее Redwood: мы хотим получить универсальную машину развертывания. Это своего рода идея в том, что вы можете просто развертывать вещи, и вам вообще не нужно об этом думать. Он говорил об этой идее годами, годами и годами, и это то, о чем говорил Джекилл в свое время. Когда вы слышите это сейчас, вы думаете: «О, вы имеете в виду как Netlify?» Это в основном то, чем Netlify является для большинства людей, которые работают на интерфейсе. Они уже даже не думают о развертывании, это даже не мысль.

Дрю: Вот мое приложение в репозитории Git, этот каталог — внешний интерфейс, этот каталог — серверная часть, вот моя база данных, и это примерно столько конфигурации, сколько вам, возможно, потребуется для того, чтобы какая-либо служба взяла ее и построила. и разместить его.

Энтони: Да, и еще одну вещь, которую я должен отметить, мы совсем недавно настроили развертывание Vercel Redwood по умолчанию, поэтому, когда вы развертываете приложение на стороне сервера, вы можете сказать: «О, у меня есть приложение Gatsby» и он точно знает, как создать приложение Gatsby по сравнению с NextApp. Теперь у нас есть это для Vercel. Итак, есть действительно очень хорошие варианты без Netlify, если вам это больше нравится.

Дрю: Итак, если я хочу начать работу, создать приложение и запустить его в производство на этой неделе, готова ли Редвуд к этому? Это зрело?

Энтони: Да, у нас есть около полудюжины приложений, которые сейчас находятся в разработке. Первый назывался Predict COVID, он вышел еще в марте и представляет собой приложение для визуализации данных в реальном времени. Затем у нас есть Repeater.dev, сделанный Робом, это похоже на работу cron для Jamstack. Затем есть Tape.sh, Duoflag, я думаю, еще один. Так что есть, по крайней мере, горстка. Если вы зайдете в крутой репозиторий Redwood, вы сможете увидеть их список. Если вы зайдете на форумы сообщества, вы также можете найти записи об этом, потому что люди запустили их в производство и как бы рассказали, как все прошло. До сих пор все они были успешными, и никто не сказал: «Я никогда не буду использовать это снова».

Дрю: Но это очень ново. Думаю, от этого никуда не деться, но с точки зрения зрелости Redwood довольно нов, у него много поклонников.

Энтони: Ну, это забавно, это так и это не так. Об этом было объявлено в марте. На тот момент Том и Питер работали над ним около года. So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

Дрю: Конечно.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. Например. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. У тебя есть напутствие?

Энтони: Просто если вы заинтересованы в чем-то из этого, не стесняйтесь обращаться. Мои DM всегда открыты. Сообщество в целом очень открытое. Я буду рад объяснить или пошаговое руководство или настроить все, что вам нужно знать, чтобы начать работу.