Next.js: Verwenden Sie das Dateisystem als REST-API des armen Mannes

Ich habe gute Erfahrungen mit Meteor gemacht. Full-Stack-Frameworks werden auf Dauer nicht funktionieren. Wir lernen es auf die harte Tour.

Es wird eine ziemlich gute Lösung für die Prototyping-Phase sein, aber ich hoffe, das ist nicht das, was wir mit diesem Projekt vorgehen.
Backend/Daten sind eine ziemlich komplexe Aufgabe. Es ist immer besser, etwas anderes machen zu lassen.

Ich denke, unser Fokus sollte darauf liegen, wie es in der Beschreibung von Next erwähnt wurde.

Ein minimalistisches Framework für servergerenderte React-Anwendungen

Ich verstehe den Einwand, aber Tatsache bleibt, dass kognitive Überlastung eine Realität ist und viele Menschen durch die Wahl gelähmt sind. Neueinsteiger bei node.js sind verblüfft von der Fülle an Optionen zum Erstellen einer JSON-REST-API. Etwas Minimales in next.js zu haben würde es vielen Anfängern ermöglichen, next.js sofort als eines einer neuen Art von Fullstack (in dem Sinne, dass es sowohl Backend als auch Frontend unterstützt, nicht im maximalistischen Sinne) zu verwenden, universelle React-Webdev-Tools, die Nehmen Sie ECMAScript 6 vollständig an.

Vergessen wir nicht, dass Mikro tatsächlich Mikro ist: etwa 100 Zeilen Code. Es wäre trivial, micro in next.js einzubinden oder zu integrieren, um die Erstellung einer minimalen REST-API zu unterstützen.

Das ist besonders reizvoll, wenn man bedenkt, dass next.js ganz klar einen Nerv getroffen hat, den micro nicht hat. Die Zahlen lügen nicht: In etwas mehr als 2 Wochen seit seiner Veröffentlichung hat next.js 241 Issues und Pull-Requests auf GitHub generiert. Vergleichen Sie diese Zahlen mit denen von Mikros: 73 Probleme und Pull-Requests (und derzeit keine offen) für ein Projekt, dessen erster Commit vor fast zwei Jahren erstellt wurde.

Derzeit herrscht in der Welt der minimalen node.js-Webframeworks ein riesiges Vakuum. Keines von Express, Koa, Koa2, Hapi, FeathersJS umfasst ES6, React, universelles Rendering und intuitives Routing so wie next.js es tut. Ganz zu schweigen von der Tatsache, dass die Express-Entwicklung tot zu sein scheint und Koa im Übergang zu Koa 2 steckt und nicht viel Entwicklerenergie zu erzeugen scheint, wenn man sich die Commit-Graphen ansieht. FeathersJS ist an Express gebunden, und selbst der Umzug nach Koa wird nur dazu führen, Koas eigene Probleme zu erben. Bleibt Hapi, das derzeit anscheinend auf mehr unternehmensorientierte Web-Apps abzielt und, soweit ich sehen konnte, ES6 immer noch nicht angenommen hat, geschweige denn universelles React oder sogar reines React unterstützt.

Es gibt ein Zeitfenster für das next.js-Projekt, um wirklich groß zu werden. Ich sehe bereits, dass Facebooks eigene Create-React-App in Bezug auf die Anziehungskraft der Entwickler um ihr Geld geht.

Betrachten Sie als letzten Punkt, was in der Python-Welt geschah, als Armin Ronacher Flask, sein minimales Web-Framework, als Aprilscherz veröffentlichte. In seinen Augen war es kaum mehr als ein syntaktischer Zucker, der seinen Werkzeug-Server mit seiner Templating-Sprache Jinja2 verband. Glücklicherweise war er wendig genug, um an Flasks unmittelbarer Popularität zu erkennen, dass er etwas vorhatte. Das Ergebnis ist, dass Flask (scheinbar) aus dem Nichts kam und schnell zu einer starken zweiten Wahl für Web-Entwickler in der Python-Welt nach Django wurde (und eine erste Wahl für viele, die monolithische integrierte Giganten wie Django meiden).

Hören Sie auf die Benutzer. Es gibt viele Leute, die nach serverseitiger Funktionalität schreien, eine Idee, die leicht um die integrierte Unterstützung einer dateibasierten JSON-REST-API erweitert werden könnte, die das gleiche benutzerfreundliche Ethos ihrer brillanten Wiederaneignung von PHPs bester Idee vertritt: das Dateisystem als ein API.

Ich stimme @arunoda voll und ganz zu. Das größte _Feature_ von Next.js ist, dass es _kein Backend_ ist. Es ist näher an dem, was @getify ein _middle-end_ nennt. Ein universelles Rendering-Frontend.

Die beste Architektur, die damit verbunden ist, besteht darin, dass Next.js _queries_ Datendienste in getInitialProps . REST-Microservices, APIs und GraphQL sind großartige Ergänzungen zu dieser Architektur.

Sehen Sie sich jedoch #25 an, da dies Ihnen ermöglichen sollte, dies im Userland zu erreichen. Sie können Routen automatisch registrieren und sie mit dem von Ihnen initialisierten benutzerdefinierten Server koppeln.