DEV Community

Discussion on: Meteor vs Next? A brutally honest answer

Collapse
macrozone profile image
Marco Wettstein • Edited on

Of course you could use a tool like ApolloJS, but that means that you need to create another API application for its server and you need to install its client into the next project, provide it with all the boilerplate and create mechanisms to provide serverside rendering.

you can add the apollo server directly into nextjs using its api route. Its very simple: github.com/vercel/next.js/tree/can...

About breaking changes in react: I feel quite the opposite: despite the changes in how to build components (createComponent -> es classes -> functional components with HOCs and now functional components with hooks), there were never big breaking changes. deprecated features were marked early as such and where exported in their own packages and communication was always very good. So even today you can use react like in the early days (altough i would not recommend it). Also its ecosystem is very alive and many important packages have been updated to work with latest version of react.

Collapse
thespider profile image
The Spider Author • Edited on

I agree with everything you say. Both Next and other framework ecosystems are growing with fantastic tools. Like I said I'm a huge fan Next and Nuxt. But these tools are the apples. You will have to pick them yourselves.

However since React and Next on themselves have a small API service and therefore require many 3th party tools to work. This leads to problems and one of these problems was React Router's switch from 3 to 4. Another big one is the movement away from class based components into functional components which forced an entire community to switch to the functional paradigm. Many devs I know had major issues when switching and now need to refactor or even rebuild entire modules, because they were build during this transition phase. To give an impression. React went from:

  • Classes + Redux
  • Classes with HOC's
  • Functions with render props
  • Functions with hooks

Admitted the Apollo Server with API routes is very powerful, but it does still not solve managing domain state on the UI, realtime capabilities, synchronizing with a database and optimistic UI. These are all things that you will need to do yourself and its quite complex to do so

Collapse
macrozone profile image
Marco Wettstein

why should apollo not solve managing domain state on the ui? (i agree with realtime capabilities though). apollo client is management of the domain state. Also it supports optimistic ui, altough not that magically like meteor's pub/sub

Also I think forcing the database to the client is an anti-pattern (altough convenient in simple case). I like the additional layer that graphql provides so that client and server can agree on a common contract (= the graphql schema).

minimongo was very cool, like magic, but t has its limits and stretching it beyond its limits is not a good idea.

Thread Thread
thespider profile image
The Spider Author

why should apollo not solve managing domain state on the ui?

It does and it should. It's just not without having to build boilerplate or 3th party packages. Again I love Apollo, but it's still not on a level that is as intuitive as Meteor has

Also I think forcing the database to the client is an anti-pattern

It's a pattern that is considered defacto on native apps. Android has SQLite, Apollo essentially is a "database-ish" implementation. RxDB is a clientside database. Redux could be a domain database too, but it does not have the tooling to properly query and manage it.

In fact all implementations that have some form of collection or list that comes from the server is kind-off a subset of the original dataset and thus it would be logical to be able to query this subset from within different components. That's why Apollo has useQuery - which is the equivalent of Minimongo's Collection.find(selector).

minimongo was very cool, like magic, but t has its limits and stretching it beyond its limits is not a good idea.

Every tool has its purpose. I agree on this point. Minimongo makes less sense for a simple blog, but so does Apollo Client and even any dynamic site given that modern static site generators provide us with much better tools.