Gatsby: Construindo aplicativos com gatsby.js: Quais são as desvantagens?

Criado em 28 set. 2017  ·  37Comentários  ·  Fonte: gatsbyjs/gatsby

Oi,

Estou pensando em usar gatsby.js para criar aplicativos da web e, em seguida, atendê-los por meio do AWS S3 e do CloudFront.

Há algum problema que eu provavelmente enfrentaria em comparação com a criação de um aplicativo node.js.

Usar gatsby.js parece muito mais simples e, dessa forma, posso integrar facilmente meu site de conteúdo com meus aplicativos.

Cumprimentos,
Daniel

question or discussion

Comentários muito úteis

Woah woah woah @barbush Eu realmente não quero que você policie perguntas como essa. Se for uma pergunta terrível (o que não é), então é melhor ignorá-la do que repreendê-la. Por favor, não responda a perguntas como esta novamente.

@bolus para sua pergunta. Gatsby é projetado para ser bastante semelhante para criar app react e outras configurações webpack / react. Portanto, é perfeitamente capaz de ser usado para construir aplicativos da web. Se você olhar no diretório de exemplos, há um exemplo redux. As pessoas têm usado com o Apollo com bastante sucesso. Não é possível usar o relay atm com gatsby, pois nosso uso do graphql entra em conflito com o deles, mas tenho certeza de que isso será fácil de resolver no futuro.

A principal desvantagem que eu conheço é que ele assume que você está construindo "páginas", então se você está construindo um aplicativo mais direto sem páginas, isso não dá muito e também limitaria um pouco a sua liberdade. Nesse caso, seria melhor usar uma configuração mais simples como o CRA.

Mas se você estiver criando "páginas", o gatsby é ótimo, pois você obtém divisão automática de código e SSR estático para inicialização rápida do aplicativo.

Eu adoraria escrever um documento de compensação mais formal em algum momento, mas fico feliz em responder perguntas aqui enquanto isso.

Todos 37 comentários

Obrigado pelo seu feedback, @barbush. Eu não sabia que 68 palavras seriam demais.

O título basicamente diz tudo: Quais são as desvantagens quando crio um aplicativo com gatsby.js?

Eu sei que é possível construir um aplicativo. Minha pergunta é - como gatsby.js é otimizado para geração de sites estáticos - que desvantagens existem? Existe alguma coisa que vai me morder na bunda mais tarde?
Parece muito específico para mim.

Woah woah woah @barbush Eu realmente não quero que você policie perguntas como essa. Se for uma pergunta terrível (o que não é), então é melhor ignorá-la do que repreendê-la. Por favor, não responda a perguntas como esta novamente.

@bolus para sua pergunta. Gatsby é projetado para ser bastante semelhante para criar app react e outras configurações webpack / react. Portanto, é perfeitamente capaz de ser usado para construir aplicativos da web. Se você olhar no diretório de exemplos, há um exemplo redux. As pessoas têm usado com o Apollo com bastante sucesso. Não é possível usar o relay atm com gatsby, pois nosso uso do graphql entra em conflito com o deles, mas tenho certeza de que isso será fácil de resolver no futuro.

A principal desvantagem que eu conheço é que ele assume que você está construindo "páginas", então se você está construindo um aplicativo mais direto sem páginas, isso não dá muito e também limitaria um pouco a sua liberdade. Nesse caso, seria melhor usar uma configuração mais simples como o CRA.

Mas se você estiver criando "páginas", o gatsby é ótimo, pois você obtém divisão automática de código e SSR estático para inicialização rápida do aplicativo.

Eu adoraria escrever um documento de compensação mais formal em algum momento, mas fico feliz em responder perguntas aqui enquanto isso.

@KyleAMathews : Obrigado, isso é exatamente o que eu estava procurando.

Estou planejando criar um site baseado em conteúdo (um blog, páginas de vendas, documentação, etc.) e, para simplificar, gostaria de hospedar alguns pequenos aplicativos de uma única página no mesmo domínio.

Parece que Gatsby é ideal para isso.

também limitaria um pouco a sua liberdade

Provavelmente não é problema para meu caso de uso, mas você pode me dizer quais limitações posso esperar e como seria difícil contorná-las?

Obrigado por criar Gatsby, aliás, Gatsby parece realmente incrível! :)

mas você pode me dizer quais limitações posso esperar e como seria difícil contorná-las?

Gatsby tenta ser o mais simples e despretensioso possível, então você provavelmente não deve se deparar com limitações, especialmente quando está criando sites de conteúdo / página, que é exatamente para o que Gatsby foi projetado.

Gatsby foi projetado para combinar ideias de aplicativos da web e sites para criar o que está em nossas mentes a ferramenta ideal de desenvolvimento e produção para construir sites realmente rápidos da forma mais fácil possível.

Você só terá problemas quando quiser usar o React de maneiras que fogem do modelo de "página" - por exemplo, aplicativos de forma mais livre. Mas mesmo lá, Gatsby tem uma saída de emergência que permite incorporar aplicativos facilmente em um site maior https://www.gatsbyjs.org/docs/creating-and-modifying-pages/#creating -client-only-routes

Parece perfeito, obrigado novamente!

oi @KyleAMathews e @bolus

comentando aqui bc do contexto em vez de abrir um novo problema heheh

o que acontece se dentro da minha /app (que é uma rota apenas para cliente), eu quiser criar um SPA (login / logout / painel), suponho que preciso criar um novo roteador dentro dela, correto?

o que você recomenda neste caso de uso @KyleAMathews , é possível? ou seria melhor usar uma _abordagem mais vanilla_ como você declarou?

obrigado

@fernandes checkout https://www.gatsbyjs.org/docs/creating-and-modifying-pages/#creating -client-only-routes - avise-nos se tiver mais perguntas!

oi, @KyleAMathews obrigado pela resposta rápida

Joguei com o Gatsby o sábado todo, verifiquei este exemplo e reduxei um ... Desculpe por não ter ficado tão brilhante, poderia ter dado mais informações sobre isso

O que estou tentando fazer, pegue meu: https://github.com/fernandes/react-boilerplate e coloque-o dentro de /app como um caminho somente para cliente

este clichê é composto por:
react / redux (com recarregamento a quente) / react router redux

Não tenho tanta experiência com JS; talvez seja apenas um detalhe que estou perdendo .. obrigado novamente!

Você não pode colocar Gatsby dentro de algo como um padrão de reação. Gatsby quer cuidar da construção e do funcionamento do site. Em vez disso, coloque as partes do "aplicativo" dentro do Gatsby.

sim, foi isso que eu quis dizer ... gatsby lida com todo o meu site e suas páginas, e react-boilerplate vai dentro do gatsby sob /app como uma rota exclusiva para o cliente ... isso é possível (considerando sua pilha, especialmente o react-router-redux)?

Gatsby lida com toda a configuração do webpack / Babel / outras configurações, então o projeto de bootstrap não é necessário.

@KyleAMathews Eu descobri como fazer meu aplicativo somente cliente com o cliente redux + apollo funcionar .. Muito obrigado pelas respostas 😉 👍

@KyleAMathews Estou enfrentando um pequeno problema aqui, estou usando o cliente apollo do graphql dentro das minhas páginas do cliente, mas elas são apenas para o lado do cliente (uma vez que você precisa estar logado), mas Gatsby tenta gerar o arquivo de índice na construção; o que, é claro, dá um erro

alguma sugestão sobre como pular esta HTML criação?

atualizar:
Estou usando https://www.gatsbyjs.org/packages/gatsby-plugin-create-client-paths/

Eu criei um plugin que deletePage baseado em page.path , está funcionando perfeitamente ... não tenho certeza se é a melhor maneira, mas está funcionando para o meu caso de uso 😄 (sim, agora eu preciso criar uma regra de redirecionamento no nginx para sempre enviar para meu app/index.html , mas foi exatamente o que fiz com meu aplicativo anterior ...

Estou me acostumando cada vez mais com o gatsby, e preciso confessar que estou mais feliz a cada progresso que faço ... trabalho incrível @KyleAMathews !! 👏

@KyleAMathews Lamento incomodá-lo aqui, mas parece um bom lugar para perguntar sobre o roteamento do lado do cliente, já que não consegui entender.

Portanto, para meu caso de uso, estou lendo dados do firebase, mas esses dados não estão TODOS disponíveis no momento da compilação, pois os usuários podem modificá-los.

Então, em uma página de Gatsby (ex: / podcasts), posso consultar facilmente os dados do firebase em cDM. Mas então eu gostaria de ir para a página de detalhes (ex: / podcast /: id) e é aí que me perco um pouco. Devo tentar delegar essa rota ao roteamento do lado do cliente?

Pelo que entendi, a ideia da escotilha de /app é ter um lugar onde você possa simplesmente ter um SPA, mas parece um exagero para o que estou tentando fazer.

Obrigado pelo seu trabalho em gatsby, tem sido uma ótima experiência para todos :)

@gafemoyano criar uma rota para /podcast/:id totalmente faz sentido se houver podcasts criados por usuários enquanto trabalham nas coisas. Uma desvantagem disso é que torna o TTFP mais lento para as pessoas que visitam páginas de podcast diretamente, pois agora há HTML renderizado por servidor para carregar para eles. Você também poderia fazer um híbrido - renderizar estaticamente as páginas de podcast existentes na construção e, em seguida, criar mais dinamicamente no navegador conforme as pessoas as criam.

De interesse para os que estão nesta página - escrevi esta nova página de documentos sobre como criar aplicativos com Gatsby https://www.gatsbyjs.org/docs/building-apps-with-gatsby/

Ei @KyleAMathews, pois isso se tornou o "problema do lado do cliente" oficial hahah outra coisa que venho considerando sobre esse problema de podcast, considerando que temos controle sobre o front-end e o back-end dos podcasts, há alguma maneira de acionar a reconstrução apenas de uma página específica ? ou apenas armazene em cache a construção e altere apenas o que foi modificado. Não tenho certeza de como isso poderia funcionar

possível relacionado a https://github.com/gatsbyjs/gatsby/issues/3444

você comentou sobre uma API de cache de chave / valor para armazenar em https://github.com/gatsbyjs/gatsby/issues/3260#issuecomment -352856214, talvez se tivermos o layout + conteúdo da página para garantir que nada seja alterado (nos dados e visual)

@KyleAMathews Obrigado pela sua resposta! Então deixe-me ver se entendi bem. A abordagem é delegar um caminho para o código do cliente renderizar, certo? Portanto , não devo tentar definir minhas rotas estaticamente em gatsby-node.js como:

` // page.matchPath is a special key that's used for matching pages
  // only on the client.
  if (page.path.match(/^\/podcasts/:id/)) {
    page.matchPath = "/podcasts/:id";

    // Update the page.
    createPage(page);
  }

Em vez disso, use apenas o que é mostrado no exemplo:

`` `
// page.matchPath é uma chave especial usada para páginas correspondentes
// apenas no cliente.
if (page.path.match (/ ^ / app /)) {
page.matchPath = "/ app /: caminho";

// Update the page.
createPage(page);

}


And on app/index.js I would define my routes by importing from ReactRouter directly:

import {Switch, Route} de 'react-router-dom'
const AppIndex = () => (







)
`` `

O que me permitiria visitar / app / podcasts /: id e renderizar PodcastDetails, onde poderia acessar a: id parte do caminho para buscar os dados no componente?

Desculpe por incomodá-lo com um cenário tão simples, simplesmente não consegui descobrir com os exemplos existentes. Talvez devêssemos incluir um exemplo para aplicativos híbridos se for uma coisa bastante comum que as pessoas fazem com gatsby? Eu estaria disposto a ajudar com isso, se necessário.

Obrigado novamente pelo seu tempo construindo e apoiando esta biblioteca @KyleAMathews .

A parte app do caminho no exemplo é arbitrária. Você pode usar o nome que precisar, por exemplo, podcasts .

Um exemplo de site seria ótimo :-) espero que haja tempo em breve. Convide qualquer pessoa que esteja acompanhando que já tenha resolvido esse problema para compartilhar um código de exemplo!

Eu tentei e tenho alguns códigos de amostra aqui

Mas ainda tenho alguns problemas.
Um que eu descrevi aqui
Em suma, quando eu construo para produção e entro em uma rota no diretório /app/ , por exemplo, localhost:9000/app/posts/1 e atualizo o navegador, recebo uma página 404 em branco.
Quando eu atualizo a página em localhost:9000/app/ ela funciona bem.
Talvez minha configuração de prefixes para gatsby-plugin-create-client-paths esteja errada.

module.exports = {
  ...
  plugins     : [
    {
      resolve: `gatsby-plugin-create-client-paths`,
      options: {prefixes: [`/app/*`]},
    },
    ...
};

E outro problema (não tenho certeza se é um problema) não posso embrulhar meus <Route /> com <BrowserRouter> .
Quando eu construo para produção (o desenvolvimento funciona bem), recebo uma mensagem de erro dizendo "o histórico do navegador precisa de um DOM", acredito que é porque Gatsby é executado em um ambiente Node e não tem navegador, portanto não tem window etc.

Finalmente removi o envoltório <BrowserRouter> e ele funcionou bem.
Eu sou novo no React, então não tenho certeza se é a solução apropriada para o problema.

Adoraria obter ajuda :)

@danielemesh Oi Daniel. Não tive tempo de voltar a trabalhar em meu aplicativo gatsby, mas o que posso ver em seu código-fonte é que você colocou o diretório /app/* em /pages .
Não tenho certeza de onde ele deve ir, tentaria colocá-lo no diretório src/ .

Deixe-me saber se funciona!

Felicidades!

@gafemoyano tentou, não funcionou :(
Gatsby não vai reconhecer ..

Obrigado!

Eu enfrentei alguns plug-ins, então decidi escrever o meu (100% emprestado do original), para que eu pudesse, felizmente, resolver meu problema e aprender a escrever plug-ins gatsby

Extraí de um aplicativo, espero que ajude a resolver seus problemas, o problema foi enfrentado bc dentro de app tem consultas do Graphql que não devem ser tratadas no SSR, apenas no navegador

@KyleAMathews o que você quer dizer com um site de exemplo? quer adicionar em algum lugar? Eu posso trabalhar nisso ..

gatsby-config.js

plugins: [
    `app-layout`, // I set my layout
    {
      resolve: `app-client-only`, // I handle app pages
      options: { prefixes: [`/app/*`] },
    },
  ],

plugins / app-layout / gatsby-node.js

// Implement the Gatsby API “onCreatePage”. This is
// called after every page is created.
exports.onCreatePage = ({ page, boundActionCreators }) => {
  const { createPage } = boundActionCreators;

  if (page.path.match(/^\/app/)) {
    // It's assumed that `app.js` exists in the `src/layouts/` directory
    page.layout = "app";
  }

  return true;
};

plugins / app-client-only / gatsby-node.js

// Prefixes should be globs (i.e. of the form "/*" or "/foo/*")
const validatePrefixEntry = prefix => {
  if (!prefix.match(/^\//) || !prefix.match(/\/\*$/)) {
    throw Error(
      `Plugin "gatsby-plugin-client-only-paths" found invalid prefix pattern: ${
        prefix
      }`
    )
  }
}

exports.onCreatePage = ({ page, store, boundActionCreators }, { prefixes }) => {
  const { createPage, deletePage } = boundActionCreators
  const re = {}
  prefixes.forEach(validatePrefixEntry)

  return new Promise(resolve => {
    // Don't set matchPath again if it's already been set.
    if (page.matchPath || page.path.match(/dev-404-page/)) {
      resolve()
    }

    prefixes.some(prefix => {
      if (!re[prefix]) {
        // Remove the * from the prefix and memoize
        const trimmedPrefix = prefix.replace(/\*$/, ``)
        re[prefix] = new RegExp(`^${trimmedPrefix}`)
      }

      // Ensure that the path ends in a trailing slash, since it can be removed.
      const path = page.path.match(/\/$/) ? page.path : `${page.path}/`

      if (path.match(re[prefix])) {
        page.matchPath = prefix.replace(/\*$/, `:path`)
        if (path != '/app/') {
          // <<<<<<<<<<<<<<<<< here is my modification >>>>>>>>>>>>>>>>>>>>>>>
          // do not try to process on SSR, user needs to be logged to
          // consume GraphQL API and render `app` pages correctly
          deletePage(page)
          // <<<<<<<<<<<<<<<<< here is my modification >>>>>>>>>>>>>>>>>>>>>>>
        }
        // createPage(page)
        return true
      }

      return false
    })

    return resolve()
  })
}

Então, não tenho certeza se esse problema está 100% relacionado ao @KyleAMathews , mas não importa o que eu faça, meu caminho 404 somente para cliente inicialmente, ele começa a carregar (e os usuários saem antes de começar a carregar)

pages / app / index.js:

import CreateSchedule from './components/CreateSchedule'
import ViewSchedule from './components/ViewSchedule'
...
  <ApolloProvider client={client}>
        <Provider store={store}>
          <Switch>
            <Route exact path="/app" component={CreateSchedule} />
            <Route path="/app/:id" component={ViewSchedule} />
          </Switch>
        </Provider>
      </ApolloProvider>

gatsby-node.js

exports.onCreatePage = async ({ page, boundActionCreators }) => {
  const { createPage } = boundActionCreators

  // page.matchPath is a special key that's used for matching pages
  // only on the client.
  if (page.path.match(/^\/app/)) {
    page.matchPath = '/app/:path'

    // Update the page.
    createPage(page)
  }
}

Também experimentei o plugin gatsby-plugin-create-client-paths sem sorte.

Meu componente CreateSchedule funciona bem sem erro 404: https://www.appointmentscheduler.org/app

O problema está na rota / componente ViewSchedule: https://www.appointmentscheduler.org/app/1b42d8e8-66b5-4a8d-a0b5-fd4bb13bed09

Ah, e o 404 só ocorre depois de construído - o servidor de desenvolvimento não tem esse problema

Alguma ideia?

@rozenmd Você precisa de roteamento de servidor para isso. Se você usar o netlify, poderá instalar gatsby-plugin-netlify e ele irá gerar a configuração de roteamento do servidor para você automaticamente (vejo que você tem netlify-identity-widget - não tenho certeza se isso significa exatamente que você está usando isso para servir ao seu site)

Impressionante!
Obrigado @pieh!
Parece que o netlify starter que usei (https://github.com/konsumer/gatsby-starter-bootstrap-netlify) não tinha 'gatsby-plugin-netlify' em gatsby-config.js

Adicionar isso e implantar corrigiu esse problema 😄

@KyleAMathews um problema adicional com o uso de Gatsby, ao que parece, é a probabilidade de respostas 503 (negação de serviço) dos servidores onde a API está hospedada, devido à natureza do Gatsby sugar-up-the-todo-api-de-uma-vez aproximação. Atualmente, estou experimentando isso com a hospedagem GoDaddy; quando executo 'gatsby developers', parece que o limite máximo de conexões simultâneas é atingido instantaneamente. Isso está de fato acontecendo? Funciona muito bem localmente (desacoplado Drupal> Gatsby), mas não quando hospedado no GoDaddy. Quaisquer dicas muito apreciadas.

@ cf73 , você tentou apontar seu GoDaddy DNS para algo mais adequado para Gatsby como o Netlify?

@rozenmd para esclarecer, o CMS sem cabeça drupal está hospedado no GoDaddy; o site Gatsby ainda está rodando localmente. então, a menos que eu não tenha entendido você, não vejo como o Netlify poderia ajudar.

@ cf73 https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-drupal/src/gatsby-node.js provavelmente poderia usar algum tipo de fila (estamos usando better-queue em outros lugares) em vez de Promise.all para limitar a solicitação simultânea a algo mais gerenciável. Você acha que poderia implementá-lo?

@pieh sim, vi o uso de better-queue, parece uma solução decente. Infelizmente, não posso fazer isso sozinho - tropecei aqui tentando resolver o erro 503 de um grande projeto de cliente no qual estou trabalhando, para o qual adoraria usar Gatsby. os prazos são apertados, então, se não houver uma solução alternativa para isso nas próximas horas ou no máximo no dia seguinte ou depois, terei que procurar outra abordagem. Alguém pode sugerir o que eu poderia fazer instantaneamente (incluindo trocar de hospedagem, se necessário) para resolver isso? existe um fluxo de trabalho comprovado drupal + hosting + Gatsby?

@ cf73 Eu sinto você sobre os prazos - se você pudesse compartilhar a configuração do seu site drupal, então eu teria o site para testar as alterações (publicamente aqui ou em particular no discord - https://discordapp.com/invite/0ZcbPKXt5bVoxkfV com PM para eu - meu cabo aí é grajen3), eu veria se consigo fazer sozinho hoje

@pieh isso seria incrível, obrigado !!

@KyleAMathews estou enfrentando um problema desesperador enquanto trabalho em um site de cliente, o que tenho certeza de que é fácil, mas estou perdendo algo. Stack é Drupal JSON-API para graphiql de Gatsby. Ele não me permite passar argumentos para os nós (consulte o anexo). Pelo que eu posso dizer, isso ocorre porque o esquema Drupal de Gatsby não está totalmente desenvolvido? Ou estou perdendo uma etapa? Qualquer ajuda urgente e MUITO apreciada !!
unknown-arg

A consulta deve ser:

NodeArticle(id: { eq: GUID }) {
  id
  ...otherFields
}

Você também pode filtrar allNodeArticle pelo id, mas se você estiver selecionando apenas uma coisa, é mais limpo consultar NodeArticle diretamente.

@KyleAMathews muito obrigado! Você pode me indicar alguma documentação em que isso seja abordado? Eu não encontrei isso até agora ... é exclusivo para como Gatsby fala com Drupal, ou um comportamento padrão do núcleo do GraphQL que eu acabei de perder? Pode ser uma ideia promover qualquer documentação específica da fonte como esta de forma mais visível ao lado do plugin de origem?

Este é o recurso principal do gatsby (filtragem do nível de consulta raiz), não específico do drupal. Os plug-ins de origem não podem definir o esquema graphql - esta é a tarefa que o gatsby core está fazendo com base em dados "brutos" fornecidos pelos plug-ins.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

totsteps picture totsteps  ·  3Comentários

dustinhorton picture dustinhorton  ·  3Comentários

rossPatton picture rossPatton  ·  3Comentários

dustinhorton picture dustinhorton  ·  3Comentários

ghost picture ghost  ·  3Comentários