DEV Community

Discussion on: Meteor vs Next? A brutally honest answer

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.