Hora de um upgrade em meu ecommerce... Node + React ou PHP + HTML??

[wilsongomes-swe]

Fala galera,
há um tempo atrás na faculdade eu desenvolvi um protótipo que virou serviço rs

O site http://zedoingresso.com.br/, que até roda uma operação legal... Nele utilizeo PHP puro e HTML apenas...

Agora pretendo fazer a versão 2.0 para fazer a brincadeira ficar séria e realmente tentar transformar em uma operação que valha a pena investir.

Ouço falar muito em gatsby e jekyll, mas meu site será dinâmico, sempre estará entrando novos eventos, vou ter apis que vão conversar com os apps, mas não sei se no front do site vou usar APIs, pois quanto a SEO o site atual superou de longe todas as minhas expectativas, sendo indexado muito rápido e rankeando muito bem... Tenho medo de usar react ou algum destes geradores e cair a questão de SEO....

O que recomendam?
Deixo react apenas para os paineis de administração mesmo? Ou mando bala com react no front do site também?

Ou mando bala com PHP puro novamente, que vai renderizar um site totalmente SEO frendly e é muito rápido.

O que acham?

Abraços!

[felipefialho]

Iria de Next.js

[wilsongomes-swe]

Entendi @felipefialho , é que ainda não entendi bem como vou lidar com server side rendering e vindo das apis as informações...
Mas vou pegar um tempo para estudar mais a fundo.

Então neste cenário acha melhor eu fazer com reactjs + next.js consumindo apis do que pelo PHP + Html por exemplo?

Em sua opinião, quais as vantagens de eu seguir pelo next.js e não pelo PHP (ou um node com EJS)?

[nei]

Dê uma olhada https://www.reactioncommerce.com/

[Juuhz]

Fala @wilsonneto-dev, beleza?

Como o @felipefialho sugeriu, eu também iria de Next.js

Eu tenho uma StartUp ( @cardesivo ), fiz um e-commerce inteiro, do zero, linha a linha, em Next.Js, olha a performance do site:

http://cardesivo.com.br/

Eu fiz infra da seguinte forma:

• Desenvolvi a parte do front em React ( Next.js ).
• Utilizo a aplicação em modo estático ( sem utilizar SSR ), e armazeno tudo em um S3 com um Cloudfront trabalhando o Cache.
• Tenho algumas Lambdas que fiz na arquitetura serverless ( com o Framework serverless ), que se encarregam de salvar os dados ( compras ) e gerar os dados ( dos produtos ) estáticos em Json.
• Com os dados em json, eu só importo no React e o carregamento é praticamente em Real Time.

---

Referente ao SEO, o Next.Js é "isomorphic", então o HTML é renderizado no lado do servidor, logo, o Google consegue indexar de boa, só vai caber a você, parametrizar tudo certo ( Tags, imagens, etc... ).

[wilsongomes-swe]

Fala @Juuhz , cara que massa seu e-commerce, e que rápido, caramba!

Estava inclinado para o PHP mas agora acho que vou de Next mesmo heim rs

Teve muitas informações ai que não manjo ainda, poderia me ajudar mais um pouco com algumas perguntas?:

• Quando diz que usou modo estático, sem SSR, qua a diferença?
• Usar Next.js em relação a usar React "puro", quais as principais vantagens?
• Se código então não acessa uma api externa, mas sim importa um json? Sua lambda salva no diretório do projeto o json, ou tem como incluir ele direto de um S3, como fez esse processo?

Desculpe tantas perguntas, mas vou fazer e to levantando tudo, muitas dúvidas, mas quero sanar todas para quando pegar para fazer já estar tudo alinhado e ai só a parte boa, codar.

Muito obrigado a todos, abraço!

[Juuhz]

Fala @wilsonneto-dev,

O fórum é para disseminar conhecimento, pode ficar a vontade para perguntar oque quiser, no que eu puder te ajudar, ajudarei.

Seguem às respostas:

Quando diz que usou modo estático, sem SSR, qual a diferença?

Quando você constrói uma aplicação SSR, você obrigatoriamente precisa de um servidor, que até certo ponto é bacana e positivo, porém quando falamos em quantidade de acessos simultâneos, segurança, uptime 100%, escalabilidade, etc... essa aplicação SSR acaba ficando complexa e CARA $$$.

O NextJS tem uma feature bacana, você consegue desenvolver toda a sua aplicação, e na hora de "buildar", você diz para o Next que você quer usar tudo estático rodando o comando:

npm run export

Ele irá iniciar um processo de compilação, e no final ele cria uma pasta out dentro do seu projeto com todos os arquivos compliados, mais ou menos nessa estrutura:

out
│   ├── .next                # Arquivos javascripts ( o core da sua aplicação )
│   ├── static                # Arquivos estáticos como imagens, etc...
├── index.html                  # Arquivo principal
└── ...

Depois, basta arrastar o conteúdo da pasta out para um S3 e vualá, você tem um site hospedado dentro da amazon sem utilizar servidor.

O bacana do S3 é que a Amazon garante uptime de 99,999999999% e o custo é muito baixo, veja:

Você utilizando até 50TB por mês, você paga -> 0,023 USD por GB

Se você utilizasse um EC2 ( servidor amazon ), pagaria algo em torno de 0,0255 USD por hora.

Ai você começa a ver a vantagem...

Usar Next.js em relação a usar React "puro", quais as principais vantagens?

A home deles já fala por sí só haha:
https://nextjs.org/

Se código então não acessa uma api externa, mas sim importa um json? Sua lambda salva no diretório do projeto o json, ou tem como incluir ele direto de um S3, como fez esse processo?

Isso, a LAMBDA pega os dados do banco, compila e joga para o S3 onde está armazenado o site, depois no React é só importar normalmente, igual você importa um CSS, por exemplo.

---

Espero ter ajudado, qualquer coisa, só falar.

[pedroribeirodev]

@Juuhz deixa eu te perguntar, e como você faz para fazer alterações em produtos? Gostei muito do seu projeto.

E segundo, uma vez criei um site usando o NextJS porém quando fui exportar para estático foi um caos, pq eu tinha um _document.js com algumas configurações globais e ele não foi junto :(.

Tenho uma loja de camisetas, e quero usar o nextjs nela

[wkrueger]

Existe uma concepção errada de que o next.js é "só pra SSR". Ledo engano. A performance do next.js é absurda, ainda mais com otimizações (ex: plugin lodash). Aplicações inteiras carregando com 300KB iniciais...

MESMO que você não use server-side rendering (ou seja, que não faça requisições dentro do getInitialProps) o next ainda fará a otimização de gerar um HTML estático, por isso o primeiro load dele é tão rápido (aliás, ele também pode gerar sites estáticos). A estrutura sugerida de "file-system-router" trás uma forma simples de conseguir um bom code-splitting e lazy-load com zero configuração (em troca de um padrão estabelecido).

Problemas do next:

• Todo o CSS é global a não ser que você use CSS modules
• Algumas bibliotecas não são pensadas com SSR em mente, elas vão dar pau e tem que fazer uns workarounds; Coisas que funcionam de cara no CRA podem precisar de algum ajuste no next porque o webpack do CRA é um tanto absurdo, só falta fazer café pra você...
• SSR com redux? Um porre, esquece. Faz o basicão.
• Tem que se adaptar padrão do roteador dele. Pode ser que nao encaixe com sua app, mas geralmente não tem problema.

Mete bala, o next é espetacular.