Is it worth to integrate Apollo if you don't need DB independence?

I love the concepts behind GraphQL, but I would stay far away from implementing it into a project until it gets way more mature and best practices are formed. Unless you are greatly in need of its benefits… if not, what’s the rush? If you don’t know much about it and how to implement it, I think running with it as your core data layer is a huge mistake.

4 Likes

The problem is: right now I have to rebuild large parts of our system and it would be sad if the new code would be outdated right when Meteor 1.5 comes out.

But I think in the end you are right. :frowning:

The code will still work great! We have a lot of stuff in production with Livedata and Mongo, you don’t need to rewrite anything :slight_smile:

Just to get you right: You also recommend to not use Apollo for production yet?

No, we’re also using Apollo in production. Both technologies are good for production. Depending on your needs, one or the other might be better for you.

I just found a good source to make an educated decision:

https://themeteorchef.com/snippets/an-introduction-to-the-apollo-stack-for-the-uninitiated/

What @sashko said. If all my mongo code was outdated because of Apollo, I’d probably go jump off a bridge :wink: They are two very different approaches and technologies. I’m guessing the Mongo code will still be the recommended way to build Meteor apps for quite some time longer.

There is now an “experimental” way for reactivity in Apollo. I started playing with Apollo, it’s a great project but it does not have a stable API yet and for now it is far from doing things automagically like the good old Meteor. So no rush for me.