Mas as limitações do Meteor são um teto de vidro. Tive projetos bem-sucedidos com o Meteor e o Vulcan, mas nunca consegui enviar essas estruturas para clientes maiores. Muitos problemas de escalabilidade, falta de tração, ferramentas de teste ruins, o nome dele.
De volta à estaca zero, eu precisava encontrar uma estrutura com a qual pudesse me casar.
Próximo vs Meteor?
Isso é comparar maçãs e laranjas!
Quando descobri o Next pela primeira vez em 2017, era uma estrutura promissora apenas para front-end. Somente front-end. Usei-o para criar o site da minha empresa e esqueci.
E então, as pessoas ao meu redor começaram a agir de forma estranha. De repente, eles conversaram sobre duas estruturas sem nada em comum, Meteor e Next, como se fossem trocáveis. Você trocou o Meteor por Next? Por que não substituir o Express por Create React App enquanto você faz isso?
Até onde eu lembro, O Comércio de Reações foi uma das primeiras estruturas não triviais a fazer a troca.
Eu não estava convencido. E, de fato, eles ainda precisavam implementar uma API GraphQL no topo do aplicativo Meteor para se comunicar com o próximo front end. Negociar uma estrutura para 2 não é o melhor negócio, por isso mantivemos o Vulcan uma estrutura baseada em Meteor.
Se você acha que comparar Meteor com Next é comparar maçãs e laranjas, você não está errado. Até hoje, o slogan da Next ainda é “A estrutura React”. Não é “A estrutura do nó”.
E, no entanto, comecei a mudar de idéia há alguns meses.
Do front-end à pilha completa com rotas de API
As rotas da API foram introduzidas oficialmente em julho de 2019 com o liberação v9.
Foi isso que me levou ao próximo movimento novamente. As rotas de API significam que o Next.js agora é uma estrutura de pilha completa minimalista, mas perfeitamente viável.
O Vulcan é construído em torno do GraphQL. E o GraphQL é uma ótima opção para rotas de API. A API é veiculada por meio de um terminal exclusivo / dinâmico / graphQL. No próximo, isso se traduz criando uma rota da API graphql.js. Mole-mole.
Atualmente, o Next cobre todo o espectro de estática a pilha cheia
A seguir, é cada vez mais chamado de “estrutura híbrida”. Isso faz sentido, pois sua versatilidade é extrema.
- Você pode desenvolver um aplicativo de pilha completa com um back-end no estilo sem servidor.
- Você pode desenvolver um aplicativo SaaS com renderização dinâmica do lado do servidor.
- Você não quer manter um servidor? Você pode seguir a filosofia do JAMstack e exportar um aplicativo estático com renderização do servidor em tempo de compilação.
- Se você é alérgico ao JS do lado do cliente, pode remover o JavaScript do pacote e manter apenas o código HTML.
Mas não pense que o Next é um valete de todos os negócios. É um sério candidato a Gatsby em sua forma estática. É uma alternativa promissora ao Meteor em sua forma de pilha cheia. A Vercel (ex Zeit) tem feito um trabalho tremendo em manter alta qualidade e muito leve, qualquer que seja o caso de uso.
Não solte Meteor ainda
Eu quero deixar algo claro. Substituir Meteor por Next como nossa estrutura principal em Vulcan não significa que pensamos que o Meteor deva ser completamente descartado.
Há uma coisa importante que aprendemos com nossos experimentos com Apollo e Meteor em Vulcan: se você planeja usar o Meteor, apenas adote o modo como ele funciona. Esqueça o GraphQL. Esqueça o Webpack. Embora criados pelas mesmas pessoas, Apollo e Meteor entram em conflito muito. Parece estranho para os desenvolvedores do GraphQL, estranho para os puristas do Meteor.
Use DDP, métodos, pub / sub, aprenda como dimensionar seu aplicativo, participe do fórum, compre canecas de café com o logotipo do Meteor. Agora que Tiny reviveu o Meteor, é uma aposta segura para os próximos anos.
Com o Vulcan + Next, nós simplesmente nos esforçamos para fornecer uma alternativa GraphQL ao Meteor. Não é pior ou melhor, é a mesma filosofia com uma implementação diferente.
Uma estrutura é como um instrumento musical. Não escolha o que está na moda, escolha aquele que combina com você. Se o seu instrumento for Meteor, vá em frente.
Apresentando o Vulcan Next Starter, um aplicativo Next de última geração
Usar o Next fora da caixa é perfeitamente adequado. Você obtém um sistema de compilação, uma solução de estilo, uma estrutura de pastas racional.
Mas se você deseja criar um aplicativo para a próxima startup de bilhões de dólares, provavelmente precisará de mais algumas ferramentas. Lembre-se, estamos buscando uma alternativa de produtividade ao Meteor.
Uma configuração legal pode ser esta:
- Cypress e Jest para testes de unidade e e2e
- Livro de histórias para testes visuais e documentação de design
- Internacionalização, pseudônimo i18n (especialmente se você é da França como eu :))
- TypeScript, para expressar seu modelo de domínio por meio de tipos estáticos
- UI de material para obter um conjunto sólido de componentes principais personalizáveis
- Cliente Apollo para se comunicar com APIs do GraphQL
- Opcionalmente, o Apollo Server para configurar um ponto de entrada do GraphQL, com o Playground e o Voyager para exploração da API
Em seguida fornece alguns exemplos em seu repositório principal. Mas isso não é suficiente no contexto da vida real. Essas ferramentas podem interagir completamente de maneira inesperada.
Digitar apenas componentes do lado do cliente, como Leaflet ou Plotly, pode ser difícil. O mesmo vale para unificar o sistema de compilação Next, Jest e Storybook, ou evitar más interações entre Apollo e Material UI durante a renderização no servidor. Redirecionar com SSR significa lidar com cenários de servidor e cliente em conjunto. O I18n é especialmente difícil de configurar sozinho. E a lista continua.
Confie em mim, você não quer resolver esses problemas sozinho. E adivinha? Passamos pelo aborrecimento para você!
Todas essas ferramentas estão instaladas em nosso novo, brilhante, Vulcan Next Starter.
Ainda temos um longo caminho pela frente, mas temos orgulho em dizer que é seguro usá-lo na produção.
Próximos passos
Nosso clichê cumpre apenas metade da nossa promessa. Você obtém uma configuração interessante de front-end, mas ainda falta um banco de dados e diretrizes para implementar o back-end. Isso não é realmente comparável ao Meteor neste momento. Um punhado de lambdas não é uma estrutura. Nem está assinando soluções hospedadas na nuvem.
É aí que entra o Vulcan. Ao longo dos anos, criamos um poderoso gerador de API do GraphQL, com o Mongo como banco de dados e vários utilitários de front-end. Naturalmente, o próximo passo para nós é combinar o Vulcan e o Next para criar uma verdadeira estrutura de pilha completa.
Você pode acompanhar nosso progresso juntando-se a nós em Folga de Vulcano.
Next e Meteor serão cidadãos de primeira classe de Vulcan, mas qualquer tipo de tecnologia front-end ou back-end do JS poderia se beneficiar. Seja Gatsby ou um microsserviço personalizado do Node. Na Vulcan, vendemos maçãs e laranjas, desde que elas o tornem um desenvolvedor eficiente.
Agora, é hora de voltarmos ao trabalho, temos muito o que fazer. Espero vê-lo em Vulcan!
Um iniciante das trincheiras
Agradecimentos especiais a Aplines, que confiou na minha empresa (LBKE) no uso das mais recentes tecnologias para seus produtos. Graças a eles, testamos todos os recursos incluídos no Vulcan Next Starter em um aplicativo profissional da vida real.
Eles estão procurando desenvolvedores; portanto, se você quiser saber mais sobre o uso do Next e do GraphQL em escala, esse é o lugar para você: [email protected]