Versatile, Passionate and Involved for as long as there is coffee. I'm a Problem Solver, Conference Organiser, Tech Lead and Javascript Developer.
Organiser of Frontend Love and VueJS Amsterdam
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
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.
Versatile, Passionate and Involved for as long as there is coffee. I'm a Problem Solver, Conference Organiser, Tech Lead and Javascript Developer.
Organiser of Frontend Love and VueJS Amsterdam
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
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
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.
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
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).
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.