Whatever happened to PostgreSQL support?

If I’m following correctly, Apollo with GraphQL seems to be considered essentially the “answer” to why Meteor appears to have dropped any plans to support SQL databases.

I suppose part of my confusion is that Apollo doesn’t really seem like a solution in the same sense that Mongo currently seamlessly integrates with Meteor. I understand that moving to a fully SQL environment would require big changes in how Meteor stores things, but it seems like at a minimum PostgreSQL support for a JSON database would allow quick integration, even if it isn’t exactly the SQL everyone wants.

Anyway, I’ve just been out of the loop, I looked into Meteor about 3 years ago, thought it looked great, but was turned off by the Mongo requirement, so I’d love to hear if anyone thinks that Mongo is no longer the issue that it once was, particularly when it comes to scalability, or if I just missed something with regards to how Meteor is giving more options for database backends.

There are no issues working with PostgreSQL (or MySQL) in Meteor, as long as you are happy that it’s no different to any other Node application using those databases (no livedata or isomorphic client API) and that you can’t use Meteor’s account system (unless you have MongoDB in the mix just for that).

1 Like

Meteor + Apollo is the way to go. You can be moving quickly like you did/do in meteor within a week or so-- plus apollo/graphql removes so much repetitive server code. Then you can easily use PostreSQL in meteor. Although you’d still need a mongo instance for accounts probably, but that’s not really the end of the world.

1 Like

I guess maybe I don’t quite comprehend the full power of Apollo? I understand that with GraphQL the idea is that you’re essentially writing the queries client-side, so you can update your request without changing server code, but at some point that has to be translated to actual DB calls, and validation and authentication still has to be done server-side somewhere.

Does Apollo provide any way of automating the creation of efficient DB calls, or is the idea that avoiding extra server-client round trips is worth inefficiencies incurred by making extra local DB queries?

I suppose this is getting a bit off the subject of Meteor, but I really loved how easily Meteor just worked when I first tried it out, but I wanted that with a more scalable database than Mongo.

I don’t want to overhype graphql, but having used it I would prefer it over vanilla meteor or fetch/rest. Apollo client does so much caching/query/data handing on the client you forget about it when you go back to working on a fetch()/rest api app. On top of that, adding a query/mutation is super easy. Deprecating one is super easy. Changing fields in a query is easy. Again, don’t want to overhype it, but I think it’s almost always the way to go.

Also, I get INSANE re-use where I can build a meteor/apollo app, then I can paste my client-side apollo folder into a react-native app and then I can build some react-native ui and now I have a web/android/ios app suite. If you use antd-mobile, you could potentially re-use ui code on both platforms.

  • You define relationships in schemas one time in a syntax all other graphql devs will understand (spans JS world, ruby, python etc)
  • Those relationships essentially remove all that forEaching/mapping of this collection to that to get a response down to the client
  • I think apollo does some kind of uber efficient batching of calls/responses to the client
  • In terms of server to database, you can use facebook’s dataloader which will cut way down on DB calls.
  • You get queries/mutations which at the end of the day are extremely similar to using meteor methods.
  • You still need to do the same stuff you would in a meteor method… check if they’re authenticated, a member of this group, etc etc.
  • Meteor 1.7 has so much good stuff in it. But adding apollo makes it so if you ever did have to move off meteor, it wouldn’t really be that bad. My client-side code has virtually no meteor code in it. And the meteor-specific code on the server is usually reasonably limited. So leveraging apollo means you’re not as locked in as you otherwise would be. 65%+ of your core logic/work is encapsulated in the graphql code (schemas/resolvers) you can port anywhere.

Check out leveluptuts youtube videos using graphql + meteor. You’d just need to write the code for the DB connection, then you use whatever ORM in your mutations/queries as if you were using it in meteor methods.

1 Like