Galera, vi que meu site em react está sendo indexado normal pelo google, acham uma boa não usar SSR?

[wilsongomes-swe]

Fala galera, estou me aprofundando mais em Next.js (e vendo um pouco de jekyll também).

Porém um site em react que fiz há dois meses, percebi que já está rankeando e bem, o google indexou os textos das páginas, as urls e tudo assim como fez com outros sites meus em php e tal.

Vendo o google indexando meus sites, e pensando que vou servir meu site direto de um provedor de storage, não pretendo usar um servidor rodando algum tecnologia como node, queremos soltar ele apenas com os arquivos estáticos e em um storage...

Acham que usar react puro é uma boa?

Nossa api está extremamente rápida após alguns "ajustes de contrato" com o provedor, então não ligamos em perder performance de renderização server side, que pelo que vi é uma das vantagens do next juntamente com a questão de indexação por motores de buscas... Mas se nenhuma destas me importa muito, e não quero ter de rodar meu site em cima de um node, o que acham do react "cru"?

Gostaria de opiniões, muito obrigado!

[fdaciuk]

Oi @wilsonneto-dev! Se você não precisa que o seu conteúdo seja compartilhado em redes sociais (que também fazem crawling), não precisa de SSR :)

Agora, se o seu conteúdo precisa ser compartilhado corretamente, e você quer tudo estático, eu iria de Gatsby :)

[portothree]

Acho legal ter SSR pros 'microbrowsers' e compartilhamento.

[wilsongomes-swe]

Então. na verdade precisaria sim rs mas pensei que assim como o google já vê o conteúdo gerado dinamicamente pelo js outros crawlers como o do face ou linkedin também veriam... Não veem? (Vou fazer alguns testes depois deployando um app de POC e compartilhando links... Mas provavelmente você já teve essa experiência né?)

O projeto que estou fazendo o levantamento vai ser praticamente "uma cópia" deste site: https://www.looke.com.br/, mesma dinâmica, igual netflix, assinatura para acesso a filmes e series que serão cadastrados diariamente, em resume seria isto, para ter uma visibilidade melhor.

Com certeza o cliente vai compartilhar e muito nas redes sociais, porque pelo que entendi é onde ele é mais forte e capta mais vendas, e onde os futuros clientes o conhecem e conhecem o catalogo de séries, filmes e novelas que ele tem.

Aqui somos acostumados com react, bastante, mas com next não, para mim não vejo problema, mas sei que nem toda a equipe está disposta a aprender tecnologias novas rs.

E também a menira como vi pelo curso que estou fazendo de como é feita a navegação com o next/link, a questão de precisar de um node rodando no servidor, confesso que isso me incomoda um pouco, o melhor dos mundos para mim seria eu conseguir usar o react exatamente como usamos (react-router-dom, sem initial props e tal) porém conseguindo conversrar com os crawlers de redes sociais tranquilos.

Confesso que estamos inclinados a tentar tudo que der no react normal, mas tenho receio de ali com um mês de desenvolvimento descobrirmos que não foi a melhor ideia kk

Será que o react "cru" não possui um mecanismo de conversar com os robôs? (face, linkedin, etc...)

Será que além do compartilhamento teremos mais desafios tentando lidar com este projeto sem o SSR?

Se fosse um projeto de vocês ou da empresa de vocês, partiriam sem pensar duas vezes para SSR com next?

[wilsongomes-swe]

Acho legal ter SSR pros 'microbrowsers' e compartilhamento.

Fala @portothree , desculpa, o que seriam os microbrowsers?
E será que o react não tem um mecanismo de conversar com os crawlers? (Vou google e pesquisar bastante também)

Além disso ve mais algum desafio que posso enfretar se não ir com SSR desde o começo?

[wilsongomes-swe]

Alguém sabe qual a stack da netflix? kk

Meu "react dev tools" fica mostrando que é feito utilizando react, mas alguém sabe se utilizam SSR, se vem tudo do server ou gerado no browser?

[wilsongomes-swe]

Oi @wilsonneto-dev! Se você não precisa que o seu conteúdo seja compartilhado em redes sociais (que também fazem crawling), não precisa de SSR :)

Agora, se o seu conteúdo precisa ser compartilhado corretamente, e você quer tudo estático, eu iria de Gatsby :)

Vou dar uma olhada no gatsby, ta em meu roadmap kkk 1 - Next.js. 2 - Jekyll, 3 - Gatsby...
Faz tempo que trabalhamos com react e que tenho contato, mas eram mais forms e sistemas fechados, agora que a empresa ta abrindo para pegar sites e app que são públicos ai nos deparamos com SSR, estou estudando.

Pelo que estou vendo jekyll é para gerar full estático, nem sei se seria correto chamar de SSR ele, já o next gera SSR com um node por trás, o próximo passo é ver o gatsby, fim de ano vai ser full estudando isso kk Me colocaram como responsável por escolher a stack do client web, dia 8 começaremos o projeto... Mas até lá ao menos já saberei para qual lado ir, e já vou ter me afiado em SSR se este for o caminho.

[portothree]

Quando eu disse microbrowser estava a querer incrementar a resposta do fdaciuk quando ele levanta o ponto de compartilhamento, porque é tão importante quanto se preocupar com o Google bot.
De qualquer maneira, microbrowser é um user agent, que também visita seu site e faz o parse do HTML. A ideia é não ser uma experiência interativa e sim representacional (as thumbnails e hints de conteúdo quando cola a url no wpp por exemplo).

[portothree]

Alguém sabe qual a stack da netflix? kk

Meu "react dev tools" fica mostrando que é feito utilizando react, mas alguém sabe se utilizam SSR, se vem tudo do server ou gerado no browser?

Eu gosto de acompanhar o blog deles no medium: https://medium.com/netflix-techblog mas você também pode ver a stack atual e comentarios de funcionarios aqui: https://stackshare.io/netflix/netflix

[wilsongomes-swe]

Shoow @portothree , entendi, e nnão conhecia este stackshare rs Valeeu! Vou verificar

[fdaciuk]

@wilsonneto-dev eu falei sober SSR na ReactConf de 2018:
https://www.infoq.com/br/presentations/o-poder-do-ssr/

Nessa palestra talvez fique mais claro alguns pontos que você está tendo de dúvidas com relação a usar ou não :)

Mas basicamente é o seguinte: sobre essa sua dúvida:

E será que o react não tem um mecanismo de conversar com os crawlers?

O React não faz nada além de te permitir, de forma mais simples, lidar com views em qualquer aplicação web. No fundo, é somente JavaScript conversando com a API DOM. Nada além disso.

Os crawlers não costumam ler conteúdo gerado no client, via JS, pois pra isso é preciso rodar um headless browser que, além de custoso em termos de infra, não é 100% seguro e garantido que ele vai entregar o conteúdo como deveria.

Quando você faz uma pré-renderização no servidor, todo o conteúdo HTML é servido através de um simples request GET, que é o que os crawlers costuma utilizar.

No caso específico do Google, eles utilizam um headless browser para conseguir rodar o JS, e ler o conteúdo do seu site, mas todos os outros crawlers não fazem isso (Facebook, Twitter, Linkedin, Telegram, Whatsapp, etc).

Então a pergunta que fica é: quando é vantagem NÃO fazer SSR?

E a resposta é: se todas as meta informações que você precisa compartilhar podem ficar apenas na home da sua aplicação, você não precisa de SSR.

Assim, independente da página (rota) que você compartilhar, você configura as metatags na index.html principal do seu projeto, e essas informações é que serão sempre compartilhadas.

Agora, se você precisa compartilhar cada página de forma isolada (cada uma com suas próprias informações), e não quer usar um servidor, você pode usar o Gatsby.

O Gatsby vai gerar tudo estático pra você, vários arquivos .html com base nas suas rotas, permitindo assim o compartilhamento de informações por página :)

Sempre que eu preciso de SSR, a primeira opção é sempre o Gatsby.

Next é só se realmente eu precisar fazer algo dinâmico no servidor, e quase nunca isso é necessário. O Gatsby já resolve tudo o que você precisa, de uma forma bem simples :)

[lucas-barbosa]

Next é só se realmente eu precisar fazer algo dinâmico no servidor, e quase nunca isso é necessário. O Gatsby já resolve tudo o que você precisa, de uma forma bem simples :)

@fdaciuk, em um e-commerce o Gatsby resolveria bem? Tenho usado o Next, aí quando o usuário acessa sua página de perfil, o server já manda as informações referentes à ele. No caso do Gatsby, esse carregamento teria que ser dinâmico no browser, certo?

Estava pensando em migrar, pois seria menos custoso o Gatsby ao Next, eu imagino.

[fdaciuk]

@fdaciuk, em um e-commerce o Gatsby resolveria bem? Tenho usado o Next, aí quando o usuário acessa sua página de perfil, o server já manda as informações referentes à ele. No caso do Gatsby, esse carregamento teria que ser dinâmico no browser, certo?

@lucabarbosa depende. O Gatsby não faz nada dinâmico (a nível de servidor). Tudo é estático. Se você precisa de algo dinâmico, precisa fazer do lado do client. Aí que vem o ponto do "depende": se você não precisa de SSR para essas páginas do usuário, só buscar as informações pelo client via request HTTP, então pode usar o Gatsby de boa.

Senão, o Next vai ser melhor para o seu caso :)

[wilsongomes-swe]

@fdaciuk seguindo essa linha do que o @lucabarbosa colocou e que você explicou, penso que em páginas "fechadas" e protegidas por login, posso usar react mesmo, já as páginas abertas que serão públicas e ai sim tem toda a preocução com crawlers, com compartilhamentos e etc... Seria algo muito fora do comum eu usar Next nas rotas públicas/abertas e usar react nas rotas privadas/logado? Como no exemplo do ecommerce, Next faz toda a listagem e etc, mas chegando ao painel do usuário, ao histórico de pedidos e etc. Enfim, isto é algo praticado no mercado também? Ou o pessoal costuma se usar react vai apenas com react e se usar next vai apenas com next?

(Digo por já ter passado por um projeto masi focado em EAD em que todas as rotas públicas eram com PHP + Twig bem server gerando páginas, e a partir do login era client react consumindo apis do PHP, no fim das contas o projeto ficou mais fluido até do que esperávamos e achamos uma boa opção, claro que no fim foram 3 projetos, o site público php + apis php + client/área privada).

[fdaciuk]

@wilsonneto-dev claro, pode usar essa opção sim, desde que sejam dois apps separados. Se for deixar tudo na mesma aplicação, aí faz mais sentido usar só o Next :)

[wilsongomes-swe]

@fdaciuk saquei, desculpa me aproveitar tanto kk é que estou estudando next e minha cabeça está explodindo quase rs (Uma das coisas que mias gosto no react é tirar processamento, carga, custo do meu servidor, já que ele hoje processo apenas as apis, e as apps clients estão todas em storages)

Uma última questão, no exemplo do ecommerce, qual stack você utilizaria? E pensando na aplicação de VOD (Video on Demand) que citei lá no começo?
Ambos os casos você optaria por apenas Next e de ponta a ponta no front?

Muito obrigado, forte abraço!

[fdaciuk]

Uma última questão, no exemplo do ecommerce, qual stack você utilizaria?

A stack vai depender muito do time: é só você no projeto? Tem um time por trás? O projeto é grande, a ponto de times diferentes precisarem trabalhar em partes diferentes da aplicação?

Com isso em mente, você escolhe se usa uma só ferramenta, ou "quebra", conforme já citado :)

---

E pensando na aplicação de VOD (Video on Demand) que citei lá no começo?
Ambos os casos você optaria por apenas Next e de ponta a ponta no front?

Mesmo esquema: só entender se precisa ou não de SSR, e decidir com base nas perguntas acima :)

[eliseumds]

Por experiência própria codando ProductReview.com.au, SSR é muito caro. Você pode renderizar meta dados no servidor para compartilhamento, e deixar o resto com o browser. Next, Gastby e etc só resolvem uma pequena parte do problema.

[wilsongomes-swe]

@eliseumds passou pela minha mente criar um server node que apenas faça a busca das informações para preencher as meta tags + open graph tags e responda os arquivos do react para o cliente tomar conta do resto mesmo, ou criar uma url alternativa para os shares e fazer este processo apenas nestas urls, mas fiquei com receio de isso ser uma solução muito fora do que seria correto rs Não rolaria um server side rendering mas apenas o preenchimento do cabeçalho pelo server, acha que isto poderia ser uma boa?

Como acha que seria uma solução menos custosa para isto?

Estou vendo e testando bastante o next aqui, mas vejo que vamos ter de mudar muitas coisas que usamos e estamos familiarizados no react... Um pouco confuso ainda kk

[eliseumds]

@wilsonneto-dev pra ser honesto, eu nunca implementei algo assim, mas penso que faz sentido e é viável. Você renderizaria um skeleton, um application frame, somente com o básico, por exemplo:

<head>
  <title>{pageTitle}</title>
  ...meta
  ...canonicalLink
</head>
<body>
  <div id="app-content">
    Um placeholder aqui
  </div>
  ...scripts
</body>

Pra gerar essas meta tags, você vai precisar ler a URL e carregar os dados correspondentes no servidor. Há formas diferentes de fazer isso:

• Criar endpoints na sua API que retornam somente os dados necessários para as meta tags, por exemplo: /products/:id/meta ou
• Gerar as meta tags a partir dos dados completos do produto: /products/:id. O problema aqui é você vai ter que carregar esses dados no browser também, causando trabalho duplicado. Pra evitar isso, você pode renderizar um JSON com esses dados no server e rehydratar no browser:

// server.js
<body>
  ...
  <script>window.SERVER_DATA = ${JSON.stringify(serverData)};</script>
</body>


// client.js
const serverData = window.SERVER_DATA;

ReactDOM.render(
  <AppContext initialValue={serverData}>
    <Router>
      ...
    </Router>
  </AppContext>,
  document.getElementById('app-content')
);

A implementação de AppContext vai depender do seu app, pode ser Redux, por ex.

---

Atenção: apenas renderizar serverData daquele jeito com JSON.stringify é uma má prática em relação a segurança pois o conteúdo pode incluir strings não escapadas como:

{ "product": { "description": "<script>ALGO MALICIOSO AQUI</script>" } }

É assim que fazemos onde eu trabalho: https://gist.github.com/eliseumds/6192135660267e2c64180a8a9cdb7dd1

[wilsongomes-swe]

@eliseumds quando diz caro se refere a custos de servidor mesmo? Poderia falar mais sobre? Pensei que esta camada do node renderizando o react seria algo leve, não é?

Lá na empresa levantaram Next ou fazer uma aplicação .net em backend que traga o pagina inicial com .net, esta apenas gerando uma página com as tags do head e deixando o resto com React.

@fdaciuk, @felipefialho, @eliseumds, vocês usam Next em produção?

Meu projeto será identico a este: https://www.looke.com.br/
Acreditam que next da conta do recado? Rotas, popups baseados em rotas, rotas públicas e rotas logado, redux + sagas e etc?

E será que caso o Next "dê ruim" por algum motivo seria fácil colocar tudo para rodar no react padrão?

O pessoal lá se mostrou bem inclinado ao nextjs, ainda mais vendo os cases que contam com Netflix e Hulu, duas empresas gigantes do mesmo setor... Porém confesso que como eu vou ser o responsável pelo projeto com medo de escolher next e daqui a um mês describrir que tripliquei os custos, ou pior, descobrir que algo ali não atende... Será que a netflix utiliza next em toda a aplicação?

Next pelo que vi resolveria, pois precisamos indexar bem e ter os crawlers e sharers gerarando as informações e thumbs... Eu preferiria usar o react puro, porém essa questão de indexar, crawlers e dos compartilhamentos está me deixando confiuso kkk

Deem opiniões por favor... rs

Muito obrigado, abraços!

[eliseumds]

@wilsonneto-dev digo caro em termos de complexidade. Servidor é o de menos quando você tem que pagar meio milhão de reais por ano (ou mais) por um desenvolvedor que conheça SSR de verdade. Além disso você fica travado num vendor.

A Netflix pode fazer isso porque eles têm muita grana pra pagar desenvolvedores. Não faz sentido utilizar SSR em páginas internas no caso deles, e no seu também. E pelo que vi eles utilizam uma implementação própria, e não NextJS.

Suas páginas públicas vão ser indexadas mesmo sem SSR, e em questão de performance, não haverá muita diferença pro usuário pq é o tipo de aplicação onde a pessoa permanece por horas, e JS é obrigatório. O único problema vão ser as meta tags.

[wilsongomes-swe]

Opa @wilsonneto-dev entendi, show! É que a netflix em si o catalogo mesmo fica fechado, eles tem apenas a landingo e para ver o catalogo é preciso assinar pelo menos o se cadastrar no periodo gratuiuto, e a galera ta pesando em cima de os usuários compartilharem os filmes vistos ali no catalogo...

Vou fazer uma POC aqui seguindo o seu exemplo ali em cima para apresentar a eles e também pra eu falar com mais propriedade.

Muito obrigado pela opinião, forte abraço!