Next.js: Utiliser le système de fichiers comme API REST du pauvre

Créé le 10 nov. 2016 · 3Commentaires · Source: vercel/next.js

Je vois beaucoup de gens sur Slack et dans divers problèmes GitHub demander une sorte de solution backend. Bien que je puisse sympathiser avec la déclaration de @rauchg selon laquelle "La récupération des données appartient au développeur", disposer d'une solution de base qui aide rapidement les débutants à démarrer avec next.js à lui seul vaudrait de l'or. Avec une simple extension de la merveilleuse idée de "système de fichiers en tant qu'API", nous pourrions introduire un dossier api/ contenant des fichiers .json, qui seraient ensuite automatiquement exposés en tant qu'API JSON REST.

Ainsi, /api/posts.json créerait automatiquement le point de terminaison de la collection GET http://example.com/api/posts/. Selon que la collection posts.json contient un tableau ou un dictionnaire de niveau supérieur, les éléments de collection individuels seraient également exposés en tant que points de terminaison GET de la forme http://example.com/api/posts/123/ ou http:// example.com/api/posts/abc/.

Selon l'appétit pour la complexité du côté de l'implémenteur (c'est-à-dire @nkzawa et le reste de l'équipe zeit), cette API REST de base pourrait être soit en lecture seule, soit également accessible en écriture, servant dans le dernier cas de base de données pour les pauvres. Celui-ci souffrirait probablement d'horribles limitations (problèmes de simultanéité ?), mais serait néanmoins utilisable pour de petits sites à faible volume et précieux pour les débutants.

Cela permettrait à next.js de devenir une solution de développement Web complète à guichet unique pour les débutants et d'éliminer la surcharge cognitive d'avoir à choisir et à apprendre à utiliser l'un des micro, express, koa/koa2, hapi ou plumesJS pour créer un API vous-même (en supposant que nous souhaitions utiliser node.js pour le backend), ou choisir et apprendre à utiliser certains Backend-as-a-Service tels que RethinkDB + Horizon, Firebase, Parse, Graph.cool ou une autre base de données exposant un API JSON REST ou API GraphQL. Certaines de ces approches seront bien sûr de bien meilleurs choix pour les déploiements de production, mais une fois que les utilisateurs auront commencé à utiliser l'API JSON REST intégrée basée sur des fichiers, ils pourront facilement migrer vers une véritable API tierce partie auto-construite.

Peut-être que cela pourrait être coordonné avec la proposition de @rauchg pour l'API de composant, détaillée ici : #149.

Source

olifante

👎3 ❤1

Commentaire le plus utile

J'ai une assez bonne expérience avec Meteor. Les frameworks full stack ne fonctionneront pas à long terme. Nous l'apprenons à la dure.

Ce sera une très bonne solution pour l'étape de prototypage, mais j'espère que ce n'est pas ce que nous allons faire avec ce projet.
Le backend/les données est un travail assez complexe. C'est toujours mieux de laisser autre chose faire ça.

Je pense que notre objectif devrait être celui-ci, comme cela a été mentionné dans la description de Next.

Un cadre minimaliste pour les applications React rendues par le serveur

arunoda le 11 nov. 2016

👍14 ❤3

Tous les 3 commentaires

J'ai une assez bonne expérience avec Meteor. Les frameworks full stack ne fonctionneront pas à long terme. Nous l'apprenons à la dure.

Je pense que notre objectif devrait être celui-ci, comme cela a été mentionné dans la description de Next.

Un cadre minimaliste pour les applications React rendues par le serveur

arunoda le 11 nov. 2016

👍14 ❤3

Je comprends l'objection, mais il n'en demeure pas moins que la surcharge cognitive est une réalité, et beaucoup de gens sont paralysés par choix. Les nouveaux venus sur node.js sont déconcertés par la pléthore d'options pour créer une API JSON REST. Avoir quelque chose de minimal dans next.js permettrait à de nombreux débutants de commencer immédiatement à utiliser next.js comme l'un d'une nouvelle génération de fullstack (dans le sens où il prend en charge à la fois le backend et le frontend, pas dans le sens maximaliste) des outils Webdev universels React qui adopter pleinement ECMAScript 6.

N'oublions pas que micro est bien micro : environ 100 lignes de code. Il serait trivial de fusionner ou d'incorporer micro dans next.js afin de prendre en charge la création d'une API REST minimale.

Ceci est particulièrement attrayant si l'on considère que next.js a très clairement touché un nerf que micro n'a pas. Les chiffres ne mentent pas : en un peu plus de 2 semaines depuis sa sortie, next.js a généré 241 problèmes et pull request sur GitHub. Comparez ces chiffres aux micros : 73 problèmes et demandes de tirage (et aucun actuellement ouvert), pour un projet dont le premier commit a été créé il y a près de deux ans.

Il y a actuellement un vide énorme dans le monde des frameworks Web node.js minimaux. Aucun d'Express, Koa, Koa2, Hapi, FeathersJS n'embrasse ES6, React, le rendu universel et le routage intuitif comme le fait next.js. Sans parler du fait que le développement Express semble être mort, et Koa est embourbé dans la transition vers Koa 2 et ne semble pas générer beaucoup d'énergie pour les développeurs, en regardant ses graphiques de validation. FeathersJS est lié à Express, et même le passage à Koa ne fera qu'hériter des problèmes de Koa. Cela laisse Hapi, qui semble actuellement cibler davantage d'applications Web d'entreprise, et pour autant que je sache, n'a toujours pas adopté ES6, et encore moins pris en charge React universel ou même React simple.

Il y a une fenêtre d'opportunité pour que le projet next.js devienne vraiment grand. Je le vois déjà donner à la propre application de création-réaction de Facebook une course pour son argent en termes d'attrait pour les développeurs.

Comme dernier point, considérons ce qui s'est passé dans le monde Python lorsqu'Armin Ronacher a publié Flask, son framework Web minimal comme un poisson d'avril. Dans son esprit, ce n'était guère plus qu'un sucre syntaxique mariant son serveur Werkzeug avec son langage de modélisation Jinja2. Heureusement, il était assez agile pour reconnaître dans la popularité immédiate de Flask qu'il était sur quelque chose. Le résultat est que, sorti (apparemment) de nulle part, Flask est rapidement devenu un excellent deuxième choix pour Django pour le développement Web dans le monde Python (et un premier choix pour ceux qui évitent les mastodontes intégrés monolithiques tels que Django).

Écoutez les utilisateurs. De nombreuses personnes réclament des fonctionnalités côté serveur, une idée qui pourrait facilement être étendue pour inclure la prise en charge intégrée d'une API JSON REST basée sur des fichiers épousant la même philosophie conviviale de sa brillante réappropriation de la meilleure idée de PHP : le système de fichiers en tant que API.

olifante le 11 nov. 2016

👍6

Je suis tout à fait d'accord avec @arunoda. La plus grande _caractéristique_ de Next.js est qu'il ne s'agit _pas d'un backend_. C'est plus proche de ce que @getify appelle un _middle-end_. Une interface de rendu universelle.

La meilleure architecture associée à cela est que les services de données Next.js _queries_ dans getInitialProps . Les micro-services REST, les API et GraphQL sont d'excellents compléments à cette architecture.

Cela dit, veuillez regarder #25 car il devrait vous permettre d'accomplir cela en mode utilisateur. Vous pouvez enregistrer automatiquement des routes et les coupler au serveur personnalisé que vous initialisez.