Next.js: Utilice el sistema de archivos como la API REST del pobre

Creado en 10 nov. 2016 · 3Comentarios · Fuente: vercel/next.js

Veo a muchas personas en Slack y en varios problemas de GitHub pidiendo algún tipo de solución de backend. Si bien puedo simpatizar con la declaración de @rauchg de que "la

Por lo tanto, /api/posts.json crearía automáticamente el punto final de la colección GET http://example.com/api/posts/. Dependiendo de si la colección posts.json contiene una matriz o diccionario de nivel superior, los elementos individuales de la colección también se expondrían como puntos finales GET con el formato http://example.com/api/posts/123/ o http: // example.com/api/posts/abc/.

Dependiendo del apetito por la complejidad del lado del implementador (es decir, @nkzawa y el resto del equipo de zeit), esta API REST básica podría ser de solo lectura o también de escritura, sirviendo en el último caso como una base de datos de pobres. Esto probablemente sufriría limitaciones horribles (¿problemas de concurrencia?), Pero sin embargo sería útil para sitios pequeños de bajo volumen y valioso para principiantes.

Esto permitiría que next.js se convierta en una solución integral de desarrollo web de pila completa para principiantes, y eliminaría la sobrecarga cognitiva de tener que elegir y aprender a usar uno de micro, express, koa / koa2, hapi o feathersJS para crear un API usted mismo (asumiendo que queremos usar node.js para el backend), o eligiendo y aprendiendo cómo usar algún Backend-as-a-Service como RethinkDB + Horizon, Firebase, Parse, Graph.cool o alguna otra base de datos que exponga un API JSON REST o API GraphQL. Por supuesto, algunos de estos enfoques serán opciones mucho mejores para las implementaciones de producción, pero una vez que los usuarios comiencen con la API REST JSON integrada basada en archivos, podrán migrar fácilmente a un tercero real de API autoconstruida.

Quizás esto podría coordinarse con la propuesta de @rauchg para el componente API, que se detalla aquí: # 149.

Fuente

olifante

👎3 ❤1

Comentario más útil

Tengo muy buena experiencia con Meteor. Los marcos de pila completa no funcionarán a largo plazo. Lo aprendemos por las malas.

Será una solución bastante buena para la etapa de creación de prototipos, pero espero que no sea eso lo que vamos con este proyecto.
Backend / data es un trabajo bastante complejo. Siempre es mejor dejar que otra persona haga eso.

Creo que nuestro enfoque debería ser este como se menciona en la descripción de Next.

Un marco minimalista para aplicaciones React renderizadas por servidor

arunoda en 11 nov. 2016

👍14 ❤3

Todos 3 comentarios

Tengo muy buena experiencia con Meteor. Los marcos de pila completa no funcionarán a largo plazo. Lo aprendemos por las malas.

Creo que nuestro enfoque debería ser este como se menciona en la descripción de Next.

Un marco minimalista para aplicaciones React renderizadas por servidor

arunoda en 11 nov. 2016

👍14 ❤3

Entiendo la objeción, pero el hecho es que la sobrecarga cognitiva es una realidad y muchas personas están paralizadas por la elección. Los recién llegados a node.js están desconcertados por la gran cantidad de opciones para crear una API REST JSON. Tener algo mínimo en next.js permitiría a muchos principiantes comenzar a usar next.js inmediatamente como uno de una nueva generación de fullstack (en el sentido de que admite tanto backend como frontend, no en el sentido maximalista) herramientas universales de React webdev que adoptar completamente ECMAScript 6.

No olvidemos que micro es realmente micro: alrededor de 100 líneas de código. Sería trivial fusionar o incorporar micro en next.js para admitir la creación de una API REST mínima.

Esto es especialmente atractivo si se tiene en cuenta que next.js claramente ha tocado un nervio que micro no ha alcanzado. Los números no mienten: en poco más de 2 semanas desde su lanzamiento, next.js ha generado 241 problemas y solicitudes de extracción en GitHub. Compare esos números con los de micro: 73 problemas y solicitudes de extracción (y ninguna actualmente abierta), para un proyecto cuya primera confirmación se creó hace casi dos años.

Actualmente existe un gran vacío en el mundo de los marcos web mínimos de node.js. Ninguno de Express, Koa, Koa2, Hapi, FeathersJS adopta ES6, React, la representación universal y el enrutamiento intuitivo como lo hace next.js. Por no hablar del hecho de que el desarrollo Express parece estar muerto, y Koa está atascado en la transición a Koa 2 y no parece generar mucha energía de desarrollador, mirando sus gráficos de compromiso. FeathersJS está vinculado a Express, e incluso el cambio a Koa solo conducirá a heredar los propios problemas de Koa. Eso deja a Hapi, que actualmente parece estar apuntando a aplicaciones web más empresariales, y por lo que pude ver, todavía no ha adoptado ES6, y mucho menos es compatible con React universal o incluso React simple.

Existe una ventana de oportunidad para que el proyecto next.js sea realmente grande. Ya veo que le está dando a la propia aplicación create-react-app de Facebook una carrera por su dinero en términos de atractivo para los desarrolladores.

Como último punto, considere lo que sucedió en el mundo de Python cuando Armin Ronacher lanzó Flask, su marco web mínimo como una broma tonta de abril. En su mente, era poco más que un azúcar sintáctico casándose con su servidor Werkzeug con su lenguaje de plantillas Jinja2. Afortunadamente, fue lo suficientemente ágil como para reconocer en la popularidad inmediata de Flask que estaba en algo. El resultado es que, aparentemente de la nada, Flask se convirtió rápidamente en una sólida segunda opción para Django para el desarrollo web en el mundo de Python (y una primera opción para muchos que evitan los gigantes monolíticos integrados como Django).

Escuche a los usuarios. Hay muchas personas que claman por la funcionalidad del lado del servidor, una idea que podría extenderse fácilmente para incluir soporte incorporado para una API REST JSON basada en archivos que adopte el mismo espíritu amigable para el usuario de su brillante reapropiación de la mejor idea de PHP: el sistema de archivos como un API.

olifante en 11 nov. 2016

👍6

Estoy completamente de acuerdo con @arunoda. La característica principal de Next.js es que no es un backend. Está más cerca de lo que @getify llama _middle-end_. Una interfaz de renderizado universal.

La mejor arquitectura que se combina con esto es que Next.js _queries_ servicios de datos en getInitialProps . Los microservicios REST, las API y GraphQL son excelentes complementos para esta arquitectura.

Dicho esto, mire el n. ° 25, ya que debería permitirle lograr esto en el área de usuario. Puede registrar rutas automáticamente y acoplarlas al servidor personalizado que inicialice.