Next.js: Use o sistema de arquivos como API REST do pobre

Criado em 10 nov. 2016 · 3Comentários · Fonte: vercel/next.js

Vejo muitas pessoas no Slack e em vários problemas do GitHub pedindo algum tipo de solução de back-end. Embora eu possa simpatizar com a declaração de @rauchg de que "A busca de dados depende do desenvolvedor", ter uma solução básica que ajude rapidamente os iniciantes a começar com next.js sozinho valeria ouro. Com uma simples extensão da ideia maravilhosa de "sistema de arquivos como API", poderíamos introduzir uma pasta / api contendo arquivos .json, que seriam então automaticamente expostos como uma API JSON REST.

Assim, /api/posts.json criaria automaticamente o ponto de extremidade da coleção GET http://example.com/api/posts/. Dependendo se a coleção posts.json contém uma matriz de nível superior ou dicionário, os itens individuais da coleção também seriam expostos como pontos de extremidade GET no formato http://example.com/api/posts/123/ ou http: // example.com/api/posts/abc/.

Dependendo do apetite por complexidade do lado do implementador (ou seja, @nkzawa e o resto da equipe zeit), esta API REST básica pode ser somente leitura ou também gravável, servindo no último caso como um banco de dados de pobre. Provavelmente, isso sofreria de limitações terríveis (problemas de simultaneidade?), Mas, mesmo assim, seria utilizável para sites pequenos de baixo volume e valioso para iniciantes.

Isso permitiria que next.js se tornasse uma solução webdev full-stack one-stop para iniciantes e eliminaria a sobrecarga cognitiva de ter que escolher e aprender a usar um de micro, express, koa / koa2, hapi ou featherJS para criar um API você mesmo (supondo que queremos usar node.js para o back-end), ou escolher e aprender como usar algum Backend-as-a-Service, como RethinkDB + Horizon, Firebase, Parse, Graph.cool ou algum outro banco de dados expondo um API JSON REST ou API GraphQL. Algumas dessas abordagens serão, obviamente, escolhas muito melhores para implementações de produção, mas uma vez que os usuários começassem a usar a API JSON REST baseada em arquivo integrada, eles seriam facilmente capazes de migrar para um terceiro real de API autoconstruída.

Talvez isso pudesse ser coordenado com a proposta de @rauchg para API de componente, detalhada aqui: # 149.

Fonte

olifante

👎3 ❤1

Comentários muito úteis

Tenho uma experiência muito boa com o Meteor. Frameworks full stack não funcionarão no longo prazo. Aprendemos da maneira mais difícil.

Será uma solução muito boa para a fase de prototipagem, mas espero que não seja isso que faremos com este projeto.
Back-end / dados é um trabalho bastante complexo. É sempre melhor deixar outra coisa fazer isso.

Acho que nosso foco deve ser este, conforme mencionado na descrição de Next.

Uma estrutura minimalista para aplicativos React renderizados por servidor

arunoda em 11 nov. 2016

👍14 ❤3

Todos 3 comentários

Tenho uma experiência muito boa com o Meteor. Frameworks full stack não funcionarão no longo prazo. Aprendemos da maneira mais difícil.

Acho que nosso foco deve ser este, conforme mencionado na descrição de Next.

Uma estrutura minimalista para aplicativos React renderizados por servidor

arunoda em 11 nov. 2016

👍14 ❤3

Eu entendo a objeção, mas permanece o fato de que a sobrecarga cognitiva é uma realidade, e muitas pessoas ficam paralisadas por escolha. Os recém-chegados ao node.js ficam perplexos com a infinidade de opções para construir uma API JSON REST. Ter algo mínimo em next.js permitiria que muitos iniciantes começassem imediatamente a usar next.js como parte de uma nova geração de fullstack (no sentido de que ele suporta backend e frontend, não no sentido maximalista) ferramentas webdev React universais que abraçar totalmente o ECMAScript 6.

Não esqueçamos que micro é realmente micro: cerca de 100 linhas de código. Seria trivial mesclar ou incorporar micro em next.js para dar suporte à criação de uma API REST mínima.

Isso é especialmente atraente quando você considera que next.js claramente atingiu um ponto nevrálgico que o micro não atingiu. Os números não mentem: em pouco mais de 2 semanas desde seu lançamento, next.js gerou 241 problemas e solicitações de pull no GitHub. Compare esses números com os de micro: 73 questões e solicitações de pull (e nenhuma aberta atualmente), para um projeto cujo primeiro commit foi criado há quase dois anos.

Atualmente, existe um grande vácuo no mundo das estruturas da Web mínimas de node.js. Nenhum dos Express, Koa, Koa2, Hapi, FeathersJS adota ES6, React, renderização universal e roteamento intuitivo da maneira que next.js faz. Para não falar do fato de que o desenvolvimento do Express parece estar morto, e o Koa está atolado na transição para o Koa 2 e não parece gerar muita energia para o desenvolvedor, olhando seus gráficos de commit. O FeathersJS está vinculado ao Express, e mesmo a mudança para Koa só levará à herança dos próprios problemas de Koa. Isso deixa o Hapi, que atualmente parece ter como alvo mais aplicativos web empresariais, e até onde eu pude ver ainda não adotou o ES6, muito menos o suporte universal React ou mesmo React simples.

Há uma janela de oportunidade para que o projeto next.js se torne realmente grande. Já vejo isso dando ao próprio app criar-reagir-app do Facebook uma corrida pelo seu dinheiro em termos de apelo de desenvolvedor.

Como último ponto, considere o que aconteceu no mundo Python quando Armin Ronacher lançou o Flask, seu framework web mínimo como uma piada de abril. Em sua mente, era pouco mais do que um açúcar sintático casando seu servidor Werkzeug com sua linguagem de templates Jinja2. Felizmente, ele era ágil o suficiente para reconhecer na popularidade imediata de Flask que ele estava no caminho certo. O resultado é que vindo (aparentemente) do nada, o Flask rapidamente se tornou uma forte segunda escolha para Django para web dev no mundo Python (e uma primeira escolha para muitos que evitam gigantes monolíticos integrados como Django).

Ouça os usuários. Há muitas pessoas clamando por funcionalidade do lado do servidor, uma ideia que poderia ser facilmente estendida para incluir suporte embutido para uma API JSON REST baseada em arquivo, adotando o mesmo ethos amigável de sua brilhante reapropriação da melhor ideia do PHP: o sistema de arquivos como um API.

olifante em 11 nov. 2016

👍6

Eu concordo totalmente com @arunoda. O maior _recurso_ do Next.js é que _não é um backend_. É mais próximo do que @getify chama de _middle-end_. Uma interface de renderização universal.

A melhor arquitetura associada a isso é que Next.js _queries_ data services em getInitialProps . Micro-serviços REST, APIs e GraphQL são ótimos complementos para essa arquitetura.

Dito isso, observe o nº 25, pois deve permitir que você faça isso no ambiente do usuário. Você pode registrar rotas automaticamente e acoplá-las ao servidor personalizado inicializado.