For people who are familiar with both, can you share your experiences?
I’ve been using Meteor for ~5 years now, and I’m very comfortable with meteor pub/sub and methods in blaze. I’ve also about 1 year ago built a new application using React/Redux/REST APIs which just uses Meteor as a build tool. I’m now building a new application and looking at what architecture to use.
The main reason I’m considering GraphQL is to enable reactivity. While probably 75% of my data is static and can be served with REST API or meteor methods, ~25% will be reactive. There will be very little writing of data from the clientside. Almost all of the data will be written into the DB by backend processes, and the client side is mainly a view layer. That said, the data can change rapidly (as often as several hundred inserts / updates a second) and there may be thousands of clients connected at a time.
Meteor pub/sub makes this very easy, but it ties you to MongoDB (I’d prefer using PostgreSQL if possible, although I’m very familiar with Mongo and could use it if necessary), and also to Meteor, making it very difficult to replace Meteor parts in the future if necessary.
On the flip side, I’ve read a bunch about GraphQL including Apollo, Postgraphile, Prisma, Hasura, etc. and it seems like it’s a very heavyweight solution to providing what Meteor does out of the box. I realize that it gives you the power to present a client-side schema that is entirely independent of the actual schema on the server-side DB, but does anyone actually use it this way? That is, Apollo and GraphQL seem like overkill if 90% of your client-side schema is basically your backend DB schema anyway (and the other 10% could be solved with views created in the DB). Solutions like Postgraphile and Hasura basically make this assumption, but then I’m not sure what I’m gaining with all this additional backend stuff I have to maintain vs Meteor publications.
Maybe I just don’t grok the power or reasons behind GraphQL, so I’m interested in people’s experiences using it, particularly if you can compare to using Meteor’s publications. This is the way I see it:
GraphQL Pros: can use Postgresql or any other backend; seems to be an emerging standard so won’t be locked into one platform.
GraphQL Cons: enormous amount of additional boilerplate / backend servers / etc which seems overengineered for the 90% use case of simply presenting the backend DB schema to the frontend with user and access control
Meteor publications Pros: very easy to get started with (especially since I’m already familiar with it)
Meteor publications Cons: locks you into Meteor data access, meteor server, and MongoDB. Possibly performance issues at scale (although helped with solutions like redis-oplog).
Or, for my use case, I could just ditch reactivity, and use frequent polling of a REST API to simulate reactivity. But this seems less elegant and ultimately end up in a lot of duplicated data being sent to each client.