Next.js: Use filesystem as poor man's REST API

[olifante]

I see many people on Slack and in various GitHub Issues asking for some kind of backend solution. While I can sympathise with @rauchg's declaration that "Data fetching is up to the developer", having a basic solution that quickly helps beginners get started with next.js alone would be worth gold. With a simple extension of the wonderful idea of "filesystem as API", we could introduce an api/ folder containing .json files, which would then be automatically exposed as a JSON REST API.

Thus /api/posts.json would automatically create the GET collection endpoint http://example.com/api/posts/. Depending on whether the posts.json collection contains a top-level array or dictionary, the individual collection items would also be exposed as GET endpoints of the form http://example.com/api/posts/123/ or http://example.com/api/posts/abc/.

Depending on the appetite for complexity on the implementer's side (i.e. @nkzawa and the rest of the zeit team), this basic REST API could be either read-only or also writeable, serving in the last case as a poor man's database. This probably would suffer from horrible limitations (concurrency problems?), but would nevertheless be usable for small low-volume sites and precious for beginners.

This would allow next.js to become a one-stop full-stack webdev solution for beginners, and eliminate the cognitive overload of having to choose and learn how to use one of micro, express, koa/koa2, hapi or feathersJS to create an API yourself (assuming we want to use node.js for the backend), or choosing and learning how to use some Backend-as-a-Service such as RethinkDB+Horizon, Firebase, Parse, Graph.cool or some other database exposing a JSON REST API or GraphQL API. Some of these approaches will of course be much better choices for production deployments, but once users get started with the built-in file-based JSON REST API, they would easily be able to migrate to a real 3rd party of self-built API.

Maybe this could be coordinated with @rauchg's proposal for component API, detailed here: #149.

[arunoda]

I've pretty good experience with Meteor. Full stack frameworks are not going to work in the long run. We learn it by the hard way.

It will be a pretty good solution for the prototyping stage, but I hope that's not what we are going with this project.
Backend/data is a pretty complex job. It's always better to let something else do that.

I think our focus should be this as it mentioned on the description of Next.

A minimalistic framework for server-rendered React applications

[olifante]

I understand the objection, but the fact remains that cognitive overload is a reality, and many people are paralysed by choice. Newcomers to node.js are bewildered by the plethora of options for building a JSON REST API. Having something minimal in next.js would allow lots of beginners to immediately start using next.js as one of a new breed of fullstack (in the sense that it supports both backend and frontend, not in the maximalist sense) universal React webdev tools that fully embrace ECMAScript 6.

Let's not forget that micro is indeed micro: around 100 lines of code. It would be trivial to merge or incorporate micro into next.js in order to support creating a minimal REST API.

This especially appealing when you consider that next.js very clearly has hit a nerve that micro hasn't. The numbers don't lie: in little over 2 weeks since its release, next.js has generated 241 issues and pull requests on GitHub. Compare those numbers to micro's: 73 issues and pull requests (and none currently open), for a project whose first commit was created almost two years ago.

There is currently a huge vacuum in the world of minimal node.js web frameworks. None of Express, Koa, Koa2, Hapi, FeathersJS embrace ES6, React, universal rendering and intuitive routing the way next.js does it. To say nothing of the fact that Express development seems to be dead, and Koa is mired in the transition to Koa 2 and doesn't seem to generate much developer energy, looking at its commit graphs. FeathersJS is tied to Express, and even the move to Koa will only lead to inheriting Koa's own problems. That leaves Hapi, which currently seems to be targetting more enterprisey web apps, and as far as I could see still hasn't embraced ES6, let alone support universal React or even plain React.

There is a window of opportunity for the next.js project to become really big. I already see it giving Facebook's very own create-react-app a run for its money in terms of developer appeal.

As a last point, consider what happened in the Python world when Armin Ronacher released Flask, his minimal web framework as an April's fool joke. In his mind, it was little more than some syntactic sugar marrying his Werkzeug server with his templating language Jinja2. Fortunately, he was agile enough to recognize in Flask's immediate popularity that he was on to something. The result is that coming (seemingly) out of nowhere, Flask quickly became a strong second choice to Django for web dev in the Python world (and a first choice for many who eschew monolithic integrated behemoths such as Django).

Listen to the users. There are many people clamoring for serverside functionality, an idea which could easily be extended to include built-in support for a file-based JSON REST API espousing the same user-friendly ethos of its brilliant reappropriation of PHPs best idea: the filesystem as an API.

[rauchg]

I agree completely with @arunoda. The biggest _feature_ of Next.js is that it's _not a backend_. It's closer to what @getify calls a _middle-end_. A universal rendering frontend.

The best architecture that's coupled with this is that Next.js _queries_ data services in getInitialProps. REST micro-services, APIs and GraphQL are great complements to this architecture.

This said, please watch #25 as it should allow you to accomplish this in userland. You can automatically register routes and couple them to the custom server you initialize.