Smashing Podcast Episódio 25 Com Anthony Campolo: O que é RedwoodJS?

Estamos falando de RedwoodJS. O que exatamente significa ser um framework Jamstack full-stack? Falei com o campeão comunitário Anthony Campolo para descobrir.

Mostrar notas

• RedwoodJS
• Antônio no Twitter
• Série de artigos de Anthony A First Look at RedwoodJS

Atualização semanal

• “Uma introdução à execução do Lighthouse programaticamente”
  escrito por Katy Bowman
• “Animando componentes React com GreenSock”
  escrito por Blessing Krofegha
• “Projetando para Atenção”
  escrito por Victor Yocco
• “Uso avançado do GraphQL em sites Gatsby”
  escrito por Aleem Isiaka
• “Comparando métodos de estilo no Next.js”
  escrito por Adebiyi Adedotun

Transcrição

Drew McLellan: Ele é um estudante da Lambda School, estudando desenvolvimento web full stack, além de ser um colaborador do RedwoodJS. Uma espécie de campeão da comunidade, ele recentemente escreveu uma série de artigos de 12 partes chamada A First Look at RedwoodJS que ajuda a explicar as origens e motivações do Redwood, juntamente com muitos dos diferentes conceitos que o framework apresenta. Então, sabemos que ele é um especialista em RedwoodJS, mas você sabia que ele nunca viu um cachorro? Meus amigos esmagadores, por favor, dêem as boas-vindas a Anthony Campolo.

Drew: Oi, Antônio. Como você está?

Antonio Campolo: Olá. Estou arrasando, muito obrigado por me receber.

Drew: Eu queria falar com você hoje, e provavelmente é óbvio desde a introdução, sobre RedwoodJS. Para quem nunca ouviu falar do RedwoodJS antes, em alto nível, o que é?

Anthony: Acho que há algumas maneiras de descrevê-lo dependendo de onde as pessoas vêm, mas a definição canônica é que é um framework sem servidor de pilha completa para o Jamstack. Então, ele combina desenvolvimento web full stack com coisas do tipo AWS Lambda sem servidor e o Jamstack, que é uma grande coisa nos dias de hoje.

Drew: Então, é uma estrutura de pilha completa que tenta reunir muitas ideias em torno de um ecossistema de desenvolvimento Jamstack? Isso está certo?

Anthony: Sim, está ultrapassando os limites do que um aplicativo Jamstack pode ser, então, ao chamá-lo de pilha completa, Jamstack, trata-se de como vamos além do front-end para ter o mesmo tipo de paradigma de implantação de apenas ser empurrado, obter todo o seu código implantado. Como conseguimos isso, mas também com nosso back-end, e temos tudo conectado?

Drew: Agora, antes de nos aprofundarmos nisso, acho muito interessante ouvir que é de uma equipe bastante experiente, não é? As pessoas por trás de Redwood não são galinhas da primavera. Para não dizer que eles são antigos, mas eles já estão no quarteirão, não é, em termos de desenvolvimento web?

Anthony: Eles são experientes. Sim, na verdade dediquei um bom tempo escrevendo sobre a história do framework e as ideias que levaram a ele, e Tom Preston-Werner é o criador, então ele também é conhecido como o criador do Jekyll, que é um gerador de site estático realmente influente. Ele também fez TOML, a linguagem do arquivo de configuração. E ele era o CEO do GitHub originalmente. Então, seu trabalho com as páginas do Jekyll e do GitHub e esse tipo de coisa que eu acho que realmente levou ao que agora chamamos de Jamstack. Muitas pessoas diriam: “Ah, o Jamstack é novo. Eles fazem isso desde sempre.” É assim que falamos sobre como é uma extensão dessas ideias mais antigas, as gerações de sites estáticos, mas com GraphQL e serverless e essas ideias de como usar código de cola e APIs para fazer seu aplicativo funcionar.

Drew: Então, isso é definitivamente de pessoas que estão muito inseridas nessa comunidade? Quero dizer, o CEO do GitHub, você realmente não fica mais inserido no tipo de comunidade de código aberto do que isso. Então, Redwood é uma estrutura de pilha completa e acho que isso significa que você tem o código Redwood rodando no front-end e no back-end. Isso está certo?

Anthony: Sim, esta é a primeira coisa que gosto de explicar para as pessoas quando estou mostrando um projeto Redwood, é que é um monorepo. Então, você tem seu front-end e seu back-end no mesmo repositório e, em seguida, cada um deles vive em suas próprias pastas. Você tem uma pasta da web, que é seu front-end, e é bastante semelhante ao que você obteria de um aplicativo Create React. Então, você tem a pasta API, que é seu back-end, e é aí que todas as suas funções são essencialmente empurradas para um grande manipulador GraphQL que é implantado no AWS Lambda por meio do Netlify.

Drew: Ok, então começando na frente, como você mencionou, é baseado em React. Isso é React mais um monte de código Redwood, ou é apenas React simples? Qual é o saldo aí?

Anthony: É um monte de coisas. É definitivamente apenas React no sentido de que você não está trazendo muitas bibliotecas de gerenciamento de estado, você nem está trazendo um roteador na verdade. Eles têm seu próprio roteador que eles escreveram e usam muitas coisas do GraphQL. Então, quando as pessoas falam sobre React e GraphQL e amigos, isso é um pouco do que está acontecendo aqui, é que ele oferece muitas integrações padrão para fazer o React falar com seu GraphQL. Porque temos muitas convenções agora sobre como usar o React, mas a busca de dados ainda é um grande aborrecimento.

Drew: Então, é o React configurado com um monte de outras ferramentas que funcionam bem com o React para te dar um ecossistema funcional para fazer esse estilo particular de tarefa. É uma descrição justa?

Anthony: Sim, não, sim, essa é uma ótima maneira de colocar isso. A maneira como Tom colocou é que existem todas essas soluções de ponta que existem, e ferramentas e tecnologia realmente sofisticadas que podemos usar, mas é muito difícil realmente aproveitá-las porque você tem um custo inicial tão grande e precisa aprendê-las , tendo que descobrir como integrá-los. Então, eles colocaram o slogan como: “Nós fazemos a configuração do seu webpack para você”.

Drew: Acho que é um ponto de dor comum que você ouve de muitas pessoas quando estão tentando começar na estrutura de desenvolvimento moderna com aplicativos JavaScript do lado do cliente e configurando o pacote da web, configurando todas as coisas diferentes, os processos de compilação, o construir etapas. Pode ser um grande campo minado, não é, fazer tudo ficar conectado e funcionando? E ainda falta muito para chegar ao “Hello, World!”. Então, Redwood está nos dando tudo isso pré-configurado?

Anthony: Sim, é muito mais uma convenção sobre a ideia de tipo de configuração, porque você tem… Tom era, como se ele tivesse construído o GitHub com Ruby on Rails e Rob, um dos outros contribuidores principais, ele é um desenvolvedor Rails desde sempre. Eles têm muitas ideias com as quais filosoficamente se alinham em termos de Rails, mas eles querem levar essas convenções sobre as ideias de configuração, as ideias de framework full stack, e implementar isso com toda a tecnologia moderna que temos agora.

Drew: Então, você mencionou que Redwood lhe dá um roteador ou um roteador, como dizemos neste lado da lagoa, ele vem com coisas como componentes padrão e qualquer tipo de coisa no React, ou você está implementar tudo isso sozinho?

Anthony: Sim, o roteador é muito sofisticado. Ele faz a maioria das coisas que você obteria apenas do roteador React, ele tem apenas ideias diferentes em termos de como eles devem ser implementados, porque Next eles também têm seu próprio roteador, e ainda não é totalmente descoberto como nós deseja que nosso roteamento de aplicativo de página única funcione. Por causa do Suspense, você tem muitas dessas perguntas sobre onde as coisas assíncronas vão entrar? Nós temos com Redwood, essa ideia de uma célula, e isso é o que realmente faz seus dados buscarem para você.

Drew: Então, talvez possamos entrar um pouco nisso? O que é uma célula em termos de Redwood?

Anthony: Sim, então uma célula é uma maneira padrão de escrever uma consulta GraphQL e, em seguida, fazer com que sua página diga basicamente se você está recebendo os dados de volta, se está recebendo um erro, se está em um estado de carregamento, ou se... Tem mais um estado, eu esqueço. Mas sim, então dá a você os diferentes estados em que basicamente você pode estar com base no fato de estar obtendo seus dados ou não. Está configurado com o Apollo debaixo das cobertas. Portanto, se você estiver usando Redwood, estará usando o Apollo como seu cliente GraphQL, mas não precisará pensar nisso. Você nunca precisa escrever nenhum Apollo ou sequer pensar sobre isso, está tudo pronto. Ele permite que você escreva consultas GraphQL, que era realmente o sonho de por que as pessoas queriam o GraphQL, é que era essa linguagem de consulta realmente simples que os desenvolvedores de front-end poderia usar. Mas então, você teve que descobrir como configurar um servidor GraphQL, você teve que descobrir todas essas outras coisas, e como você consegue tudo isso. Então, ele faz toda a integração do GraphQL para você, então você pode simplesmente escrever o GraphQL, você não precisa pensar em como eu implemento o GraphQL.

Drew: Então, eu acho que um dos trabalhos clássicos de um framework é pegar todo o código de placa de caldeira que você poderia escrever e implementá-lo para você, e arrumar o caminho nos bastidores para que você nunca precise olhar para essa placa de caldeira nunca mais, e você pode simplesmente escrever o código que é exclusivo para sua circunstância. Eu acho que é isso que está acontecendo com um celular, não é? Não há nada de revolucionário aqui, é algo que você pode configurar um componente React para ter todos esses estados diferentes e você pode conectar o Apollo e fazer tudo isso sozinho, mas na verdade é muito trabalho e é um padrão comum. Então, Redwood se organizou em um padrão agradável e reutilizável que você pode começar a usar sem ter que pensar nisso. Essa é uma boa descrição?

Anthony: Sim, eles criaram o nome, mas eles definitivamente reconhecem que essa era uma prática que eles viam com frequência e que viam muitas pessoas apenas codificando-o, e decidiram que queriam uma maneira declarativa de buscar seus dados. Então, é por isso que você tem essa configuração, porque ela permite que você tenha seus estados diferentes e você não precisa fazer lógica se/então para descobrir, precisa fazer isso se isso acontecer. Portanto, trata-se de ter uma única maneira de declarar todos os diferentes estados em que seus dados podem estar enquanto você os carrega.

Drew: É uma das características do React, não é, que o React não tenta te dar uma arquitetura para o seu projeto, ele te deixa decidir como você vai estruturar as coisas. Isso, claro, tem prós e contras. Mas, parece que Redwood está impondo parte dessa estrutura para você para que você não precise pensar sobre isso e para que ele possa colocar o encanamento para você e meio que continuar de onde o React parou em termos de fornecer a você esse tipo de estrutura.

Anthony: Sim, e acho muito interessante que tenhamos visto várias tentativas diferentes de solução para esse problema, porque quero dizer que você tem pessoas que sempre dizem: “Por que não existe um Rails para JavaScript ou Rails para React?” Há uma ótima entrevista na Full Stack Radio entre Michael Chan e Adam Wathan chamada React is Not a Rails concorrente. Este é um dos diferentes frameworks.

Anthony: Os outros são o BlitzJS, que recebeu uma boa quantidade de buzz, e o Bison é um novo e promissor. Todos eles têm uma pilha semelhante, mas usam peças diferentes. Você terá a consulta React em vez de Apollo, ou terá Chakra em vez de Tailwind. As pessoas que estão juntando todas essas peças em suas pilhas, todas essas pilhas estão meio que lutando, é tudo uma competição muito amigável. Na verdade, isso é uma coisa que eu realmente aprecio, é que todos nós colaboramos entre os frameworks também. Não há animosidade aí.

Drew: Então, nós mencionamos Apollo e GraphQL, Redwood usa GraphQL bastante como uma das peças principais, não é, do framework? Provavelmente podemos dedicar um episódio inteiro de podcast apenas ao GraphQL, mas para quem não está familiarizado, que peça o GraphQL está fazendo aqui, que problema está resolvendo nesse contexto?

Anthony: Sim, esta é uma ótima pergunta. Quando estou dizendo às pessoas o que elas devem saber para ter um bom começo com Redwood, eu diria que você deveria ter usado o aplicativo Create React, apenas se você criou um aplicativo Create React e o implantou no Netlify ou Vercel, isso lhe dará um bom começo. Então, conheça pelo menos um pouco do GraphQL porque ele é muito central. Portanto, o GraphQL é como seu front-end conversará com seu back-end. Eles dizem que é uma linguagem de consulta para APIs, a ideia é que ela seja uma alternativa aos métodos de API RESTful e que, em vez de fazer essa coisa RESTful, você está enviando consultas que especificam exatamente a estrutura de dados hierárquica que você deseja receber de volta o banco de dados. Portanto, é necessário um pouco mais de tempo de inicialização para que seu servidor GraphQL converse com as duas partes. Então, uma vez que você o tenha, os desenvolvedores de front-end terão a capacidade de obter dados de maneira muito mais flexível. Você não precisa de todos esses endpoints de API diferentes que seu pessoal de back-end precisa continuar fazendo.

Drew: Então, se houver mudanças nos requisitos no front-end, presumivelmente você pode apenas ajustar sua consulta GraphQL e não precisa da ajuda de alguém que trabalhe no back-end para fazer essa alteração para você?

Anthony: Quero dizer, o verdadeiro sonho é que você pode lançar um cliente móvel para ele, que seria tão flexível no final das contas que se torna, você pode ter vários clientes todos conversando com sua única API. Sua API GraphQL se torna sua fonte de verdade, é aí que toda a sua lógica é centralizada. Então, você pode construir todas essas diferentes camadas de visualização no topo.

Drew: Então, temos o GraphQL nos dando a capacidade de consultar algum tipo de back-end. Em Redwood, qual é o back-end?

Antônio: Sim. Há algumas maneiras diferentes de criar seu back-end. É assim que você sai da caixa com o tutorial, que é usar o banco de dados Postgres implantado no Heroku, super fácil, super simples. Em seguida, seu aplicativo Redwood fala com ele com o Prisma. Não sei se você conhece o Prisma, mas é como um O/RM. Eles dizem especificamente que não é um O/RM, é um construtor de consultas, que é um nível um pouco mais baixo. Mas, apenas para explicar para as pessoas, Prisma é o que permite que você converse com seu banco de dados. Ele faz suas migrações e configura suas tabelas. Ele faz todo o material SQL para que você não precise escrever SQL. Para mim, isso soa como um O/RM. Você não precisa necessariamente usar Prisma para usar Redwood.

Anthony: Na verdade, eu construí um aplicativo de prova de conceito onde usamos o FaunaDB. FaunaDB, eles têm sua própria API GraphQL, então você pode simplesmente enviar a API GraphQL diretamente para o Fauna e, em seguida, fazer suas mutações de banco de dados dessa maneira. Você perde muita funcionalidade da CLI do Prisma, mas o Prisma realmente é um fator de conveniência para trabalhar muito facilmente com seu banco de dados relacional. Mas, na verdade, qualquer coisa que você pudesse pensar, você poderia descobrir como conectá-lo com Redwood é o que eu descobri apenas porque ele é construído em torno do GraphQL e o objetivo é poder conversar com todas essas peças diferentes.

Drew: Então, Prisma é essencialmente uma espécie de camada de abstração entre seu código e qualquer armazenamento de dados que você está usando, presumivelmente que Prisma suporta, isso é... ou está fazendo coisas mais inteligentes do que isso?

Anthony: Sim, então você escreve um esquema, então você cria um arquivo schema.Prisma, e ele teria post de modelo, e então teria id e integer e incremento automático, como title sting, body string, created at date, time . Então, você cria basicamente o que você quer que seja em seu banco de dados com os tipos, e então ele faz as coisas do banco de dados para você, então você não precisa interagir com o banco de dados.

Drew: Então, você usa o Prisma para definir eu acho que tipo de banco de dados ou com que tipo de armazenamento de dados você está falando. Então, lá você apresenta seus diferentes modelos de mvc para usar essa linguagem. Então, quando seu aplicativo está conversando com os armazenamentos de dados, está usando uma instância de um cliente Prisma, não é? É isso que está acontecendo?

Antônio: Sim. Sim, é exatamente isso. Então, na pasta da API do seu back-end, você tem uma pasta lib com um db.js, e apenas por padrão que tem seu cliente Prisma configurado. Então, isso é tudo que você tira da caixa e, como você disse, o Prisma pode trabalhar com diferentes bancos de dados. Ele pode alternar entre SQLite para desenvolvimento e Postgres para produção, esse tipo de coisa. São principalmente relacionais agora, mas o roteiro tem coisas como Mongo e Fauna nele.

Drew: Então, isso é bastante útil se você puder configurar e usar o SQLite em seu ambiente de desenvolvimento local enquanto estiver colocando as coisas em funcionamento e depois entrar em produção com algo como o MySQL.

Anthony: É exatamente assim que o tutorial é configurado, esse é o fluxo de trabalho que ele mostra.

Drew: É bem interessante, não é, ver uma abordagem muito moderna para um framework e depois recorrer a alguns desses bancos de dados mais tradicionais, como o MySQL. Estou muito familiarizado com o MySQL. Adoro-o pela sua estabilidade e adoro a forma relacional de armazenar dados. Eu acho que funciona tão bem para tantas coisas. Muitas vezes você vê o bebê jogado fora que era a água do banho quando se trata dos novos tipos de armazenamento de dados, então é bastante interessante ver o Redwood por padrão suportando esses bons e antigos bancos de dados relacionais.

Anthony: Sim, não, esse é um ponto tão bom, porque eu digo que para todas as coisas novas que Redwood combina, há algumas coisas que realmente dizem que a maneira antiga, testada e verdadeira é realmente a melhor. Então, eles são realmente grandes em bancos de dados relacionais. Isso vem da experiência de Tom usando Rails e tendo um back-end relacional. O Active Record era a camada O/RM que o Prisma pretendia aproximar.

Drew: Acho que estamos falando de uma arquitetura serverless aqui com Redwood, e conversamos com Chris Coyier, acho que dois ou três episódios atrás, tudo sobre serverless usando APIs e funções de nuvem e coisas assim. Então, dando um passo atrás, se você pensar em termos de um framework baseado em servidor, como mencionamos Ruby on Rails ou algo como Laravel no mundo PHP. Mesmo com um front-end React, sua solicitação de API estaria executando código que é código Rails ou código Laravel mais seu código de usuário e configuração. É o mesmo com Redwood? Existe um código de servidor Redwood real que é executado ou são apenas mais ferramentas, estrutura e cola que permitem que você implemente o seu próprio?

Anthony: Sim, então no back-end, há um arquivo especificamente que é uma maneira de pegar seu SDL, então você tem sua linguagem de definição de esquema, e então você tem o que é chamado de seus serviços, que são como seus métodos para conversar com seu Processo interno. Em seguida, tudo isso é reunido em um manipulador GraphQL que é implantado em uma única função do Lambda. Portanto, é otimizado especificamente para Lambda. Na verdade, recentemente, alguém fez isso com a estrutura sem servidor, e temos algumas pessoas trabalhando no Azure e no Google Cloud. Não é a função do Google Cloud, é aquela construída em cima disso. Mas sim, agora está basicamente otimizado para implantar seu back-end como uma função GraphQL em um AWS Lambda. Esta é a coisa que é toda mágica acontecendo no código que eu não entendo, mas essa é a explicação de alto nível.

Drew: Então, existem ferramentas de implantação que pegam todo o código que você escreveu, esmagam tudo em algum tipo de bola mágica de código que pode ser executada na nuvem e coloca na AWS ou você ainda tem que gerenciar esse processo sozinho?

Anthony: Sim, então tudo é feito através do Netlify se você seguir o tutorial. Você realmente não precisa mexer com nenhum tipo de função sem servidor. As coisas que conectam seu back-end para enfiá-lo no AWS Lambda, tudo isso é tratado, você não precisa tocar em nenhum desses códigos. Isso tudo é gerado fora da caixa como suas convenções sobre suas configurações, então você realmente não precisa pensar muito sobre como torná-lo sem servidor. É sem servidor por padrão. É realmente uma coisa difícil de envolver sua cabeça. Demorou um pouco para eu envolver minha cabeça em torno dele.

Drew: Sim, porque é um ponto importante, não porque existem algumas áreas diferentes que estamos acompanhando aqui. Acho que temos três áreas diferentes. Temos nosso aplicativo React front-end, que está sendo executado no navegador, e temos uma API baseada em GraphQL, funcionando como uma função de nuvem, e que está respondendo às nossas consultas, mas interagindo com um armazenamento de dados que usa Prisma. E esse armazenamento de dados é o que e onde, porque você não pode executar um servidor MySQL no Netlify, pode?

Anthony: Sim, é aí que entra o Heroku. Então, na última parte do tutorial, você implanta seu front-end no Netlify e depois implanta seu back-end no Heroku Postgres e apenas pega suas variáveis ​​de configuração do Heroku, conecta-o em Netlify. Fazer com que o front-end do Netlify converse com o back-end do Postgres é uma coisa muito, muito simples. Eles queriam ir com a coisa que seria a mais fácil para qualquer um girar, mas ainda ter uma boa tecnologia estável e testada em batalha. No final, o que você obtém da caixa apenas seguindo as instruções é realmente incrível.

Drew: Os entusiastas do Jamstack estarão familiarizados com serviços como o FaunaDB que você mencionou que fornece um armazenamento de dados como uma API, AWS tem DynamoDB, Google tem Cloud SQL e assim por diante. Então, você mencionou que Redwood está pensando em integrar, ou eu acho que Prisma é o componente aqui que está procurando integração com esses tipos de serviços mais adiante?

Anthony: Sim, esta é uma boa pergunta. Isso é algo que estou conversando com Ryan Chenkie na Prisma sobre como ajudar, qual é o tipo de história de banco de dados para Redwood para coisas que não necessariamente funcionam com Prisma? Seria melhor descobrir uma maneira de fazer Redwood trabalhar com ele diretamente como fiz com o Fauna ou faria mais sentido implementar um driver para o Prisma? Então, há diferentes maneiras de abordá-lo. Há obviamente um milhão de bancos de dados diferentes agora que todo mundo quer usar, então é o quão motivado você está para colocar seu armazenamento de dados nele. Há muitas contribuições da comunidade acontecendo lá.

Drew: Então, como o Prisma entende seu modelo e sabe como consultá-lo, ele é capaz de gerar algum tipo de migração ou coisas assim para ajudá-lo a configurar esse banco de dados?

Anthony: Isso é exatamente o que você perde quando precisa tirar o Prisma e obter seus dados, é que você perde todas as funções de migração. Ele tem uma CLI realmente avançada que faz uma tonelada de coisas para você, então você pode passar por todo o tutorial Redwood e digitar os comandos do Prisma e não precisa ter ideia do que está fazendo, simplesmente funciona. É uma ótima ferramenta para fazer todo esse tipo de coisa do tipo banco de dados que você quer ter certeza de que está certo e quer ter certeza de que está feito corretamente.

Drew: Parece que ter uma ferramenta muito boa em torno de frameworks é uma tendência bastante moderna, não é? Para não apenas dizer: “Aqui estão todas as coisas que esse framework pode fazer, mas aqui estão algumas ferramentas CLI que farão um monte disso para você”. O Redwood tem ferramentas para coisas como geradores CLI e outras coisas para colocá-lo em funcionamento rapidamente?

Anthony: Este é provavelmente o maior recurso-chave que você obtém do Redwood, é que você obtém um conjunto completo de geradores muito sofisticados. Para quem já viu a demo original do Ruby on Rails, que o DHH deu, ele cria um blog em 15 minutos e faz tudo com Rails, e as pessoas ficam tipo, “Uau, isso é incrível”. Esse é o efeito que Redwood está usando. Eles querem que você seja capaz de fazer tudo muito rápido para que você possa gerar páginas, você pode gerar layouts, você pode gerar suas células, sobre o qual eu estava falando, e você pode fazer um comando scaffold que vai criar todo o seu Interface CRUD. Eu tenho uma seção inteira, a parte quatro da série do blog, apenas explica todo o código que o scaffold fornece a você. Dá-lhe muito código. Há um gerador desligado, há até um gerador Tailwind que configura seu vento de cauda para você.

Drew: Isso é incrível. Lembro-me de ver a demonstração do Rails do DHH. Quero dizer, foi provavelmente, o que, 15 anos atrás, quando ele fez aquele andaime pela primeira vez e mostrou a você, e você obtém um painel de controle bastante rudimentar, mas funcional, essencialmente para permitir que você crie novos itens, edite-os, exclua-os, etc. . Isso pode ser inestimável em um projeto, especialmente trabalhando em um tipo de ambiente dinâmico onde, tudo bem, talvez você implemente ferramentas melhores no futuro para editar esse conteúdo, mas significa ser capaz de criar algo rapidamente, você pode obter teste os dados, ou você pode até mesmo entregar isso para uma equipe de conteúdo que pode começar a trabalhar enquanto você está trabalhando no front-end, então isso é realmente útil.

Drew: Se você quisesse apenas implantar isso e tê-lo em produção, presumivelmente você poderia implantá-lo junto com seu código de front-end, mas você precisaria de alguma maneira de proteger esse aspecto, essas raízes em seu aplicativo.

Anthony: Sim, há algumas opções diferentes para autenticação. Você pode usar a identidade Netlify. Esse é o padrão se você entrar no tutorial, e então você também pode usar Auth0, e então um que eu não estou familiarizado chamado Magic.Link, e provavelmente haverá alguns extras adicionados no futuro. Mas sim, então já existem algumas soluções incorporadas, e essa é a última coisa que você faz, então essa é a última parte de toda a minha série de 12 partes do blog é o Auth. Acho que nunca tinha descoberto o Auth antes de usar Redwood. É difícil e eles definitivamente fizeram um bom trabalho com isso.

Drew: Isso se integra em um nível de rota ou em um nível de rota, desculpe, como você protege as coisas?

Anthony: Sim, então parte de como eles têm seu próprio roteador, eles também têm… Você pode fazer rotas privadas, então eles têm um componente de rota privada. Então, seu formulário de login real, é o que você obtém da identidade Netlify, para que você não precise criar um formulário e fazer seu gerenciamento de estado com isso, é aí que muitos problemas entram em jogo. Retirando as partes realmente importantes e, em seguida, você pode simplesmente implementar o acesso baseado em função. Temos um complemento de controle de acesso baseado em função que foi feito nas últimas duas semanas por David T. Então, há muito trabalho acontecendo para criar outras maneiras de fazer isso, mas o que eles têm agora já é… funciona, é' Vai te deixar funcional.

Drew: As pessoas sempre dizem sobre criptografia de hashing de algoritmo de segurança, que você nunca deve escrever a sua própria porque nunca será tão bom quanto as coisas que estão por aí. Cada vez mais, acho que isso também se aplica à autenticação em um nível superior; que a autenticação é uma área tão complexa nos dias de hoje que as pessoas querem não apenas fazer login no seu site com credenciais exclusivas, mas podem querer autenticar usando o Google, ou podem querer autenticar usando um dispositivo Apple, ou podem querer autenticação de dois fatores , ou eles podem querer integrá-lo a um serviço de logon único que estão usando em uma empresa. Todas essas coisas são uma dor de cabeça se você tentar implementá-lo sozinho e tantas oportunidades para errar e expor falhas de segurança em seu aplicativo, que usar um serviço de autenticação parece quase um acéfalo neste momento para mim. Portanto, apenas ser capaz de inserir algo com essencialmente algumas linhas de código e estar funcionando parece uma maneira realmente produtiva de trabalhar e manter as coisas seguras.

Drew: Parece que a implantação dos aspectos front-end e do servidor, as coisas da função sem servidor, é naturalmente adequada para implantação no Netlify. Você está ligado a isso com Redwood? Quero dizer, mencionamos que Tom Preston-Werner é um dos principais proponentes dessa estrutura, ele também está no conselho da Netlify. Você acha que há potencial para um acoplamento muito apertado se você escolher Redwood como base para um projeto?

Anthony: Sim, isso é algo que Tom está definitivamente consciente. Ele investiu em muitas empresas que flutuam por aí. Investiu na Prisma e na Fauna. Ele quer apenas fazer as ferramentas que ele quer usar. Não se trata de querermos prendê-lo nessa coisa tanto quanto o que a Netlify construiu, ele acha que é a melhor opção, então é por isso que eles construíram em torno disso. Mas eles não querem que ele fique preso a qualquer destino de implantação, e é por isso que estamos trabalhando em coisas como a estrutura sem servidor e algumas pessoas falaram sobre o Begin. Queremos ser pragmáticos, queremos que funcione para qualquer caso de uso de alguém. Então, temos 90% do caminho e você só precisa conectar as últimas duas coisas para que funcione com qualquer que seja o servidor de sua escolha.

Drew: Acho que até o Netlify está usando o AWS Lambda para as funções dos servidores, então é realmente a parte de implantação que é cuidada pelo Redwood e, na verdade, você mesmo pode implantar isso no Lambda. Postar seu front-end são apenas arquivos, não é, é baseado em CDN o resto? Portanto, há bastante flexibilidade sem estar muito preso.

Anthony: Sim, na verdade há um termo que Tom fala como a ideia filosófica central por trás de Redwood, que é que queremos chegar a uma máquina de implantação universal. Essa é uma ideia meio que, é que você pode simplesmente implantar as coisas e não precisa pensar sobre isso. Ele vem falando sobre essa ideia há anos e anos e anos, e era sobre isso que Jekyll falava naquela época. Quando você ouve isso agora, você fica tipo, “Oh, você quer dizer como Netlify?” Isso é basicamente o que Netlify é para a maioria das pessoas que estão trabalhando no front-end. Eles nem pensam mais em implantar, não é nem um pensamento.

Drew: Aqui está meu aplicativo em um Git Repo, este diretório é o front-end, este diretório é o back-end, aqui está meu banco de dados, e isso é quase a configuração que você precisaria para qualquer serviço para levá-lo e construí-lo e hospedá-lo.

Anthony: Sim, e uma coisa que eu também devo salientar, nós acabamos de configurar a implantação padrão do Vercel Redwood, então quando você estiver implantando em um aplicativo do lado do servidor, você pode dizer: "Ah, eu tenho o aplicativo Gatsby" e ele sabe exatamente como construir um aplicativo Gatsby versus um NextApp. Temos isso para a Vercel agora. Então, existem opções realmente boas que não são da Netlify também, se você estiver mais interessado nisso.

Drew: Então, se eu quisesse começar e construir um aplicativo e colocá-lo em produção esta semana, Redwood está pronto para isso? É maduro?

Anthony: Sim, temos cerca de meia dúzia de aplicativos em produção no momento. O primeiro foi chamado Predict COVID, lançado em março, e é como um aplicativo de visualização de dados em tempo real. Então, temos repeater.dev é feito por Rob, é como um cron job como coisa para Jamstack. Então, há Tape.sh, Duoflag eu acho que é outro. Então, há pelo menos um punhado. Se você for um repositório incrível de Redwood, poderá ver uma lista de todos eles. Se você for aos fóruns da comunidade, também poderá encontrar artigos sobre isso, porque as pessoas os colocaram em produção e meio que disseram como foi. Até agora, todos eles foram bem-sucedidos e ninguém disse: “Nunca mais vou usar isso”.

Drew: Mas, é muito novo. Eu acho que não há como escapar disso, mas em termos de maturidade, Redwood é muito novo, está recebendo bons seguidores.

Anthony: Bem, é engraçado, é e não é. Foi anunciado em março. Nesse ponto, havia sido trabalhado por cerca de um ano por Tom e Peter. 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-

Draw: Claro.

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. Por exemplo. 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. Você tem alguma palavra de despedida?

Anthony: Apenas se você estiver interessado em alguma dessas coisas, sinta-se à vontade para entrar em contato. Minhas DMs estão sempre abertas. A comunidade é muito aberta em geral. Ficarei feliz em explicar ou passo a passo ou configurar tudo o que você precisa saber para começar.