Next.js is not what you may think it is
Understanding next.js when coming from the meteor paradigm.
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.
In other words next.js’s scope is to UI-rendering, while abstracting away the client/server distinction. If you need “proper” backend logic, such as a database or an accounts server, you should keep that in a separate server application.
If you come from meteor-land like I do, splitting concerns into different applications might feel strange. But this is where Arunoda Susiripala’s already year-old criticism of universal applications applies. As he comments in the same thread:
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.
I think our focus should be this as it mentioned on the description of Next.
A minimalistic framework for server-rendered React applications
I’m currently in the process of evaluating technologies to move my application away from meteor. It’s an awesome project, but I believe relying solely on npm libraries is going to be less risky in the long run. Follow me if you want to hear more news about this effort.
Update: I created a node.js (next.js) starter library that features a full accounts system, called Staart. Check it out live here!