Meteor, combined with Grapher and RedisOplog remain my go-to framework and data fetching layers for building realtime apps really fast. Currently, I am considering between Apollo and Prisma.io for my next app and would want to know what the community thinks, and how everyone is using and integrating GraphQL tech into their teams and workflows. We already know who backs Apollo and the MDG, and Prisma.io just raised $4.5M led by Kleiner Perkins to build the GraphQL data layer for all databases. Your opinion will be highly appreciated.
we are building with Vue + Apollo + Prisma (no Meteor). For a larger app, we may go with a pure graphql server in order to have more control, but for this current app, Prisma has been a very good experience–although they need to improve data importing data. Any specific questions?
I have taken more than a month to look at prisma and decide if I should switch from Meteor to prisma.
The short answer is no, here are my thoughts.
- You have to deal with accounts system on your own ( the best solution for prisma is oauth0 in my opinion )
- They do not support mongo yet, which can not be a problem when starting from scratch, but was in my case.
- Also importing datas was not working really well, so migrating to s SQL database was more than difficult.
- The most important part was that prisma is written in Scala, and I do not want to incorporate something that I cannot hack quickly if needed.
- By looking at the forum daily, questions were pretty much the same ( token problems, local docker ), so I conclude that it was not as stable as described.
I still think that prisma is a good idea, and will use it in MVP or small projects.
1 Like
@martineboh just want to make sure that you are aware that both redis-oplog AND grapher can be used with Apollo 
1 Like
Haven’t used Prisma, but have heavily researched it for consideration in our product. We use Meteor, Apollo and GraphQL heavily in our product. In my opinion, it all depends on your use case. In our product, we have a specific portion that requires connection to multiple data sources. We actually can’t use Prisma in our case because data sources are added dynamically and Prisma doesn’t support this, which is unfortunate. But it would be useful if we used many data sources internally. Apollo and GraphQL work sufficiently in this respect.
With some time working with these tools under my belt, I believe you shouldn’t use any of these tools unless you really need to. If you’re already using Meteor, Meteor pub/sub is much easier for most things. I often feel I’m reinventing the wheel when using Apollo. That’s why when it comes to things like user management, we don’t use Apollo. Everything we can do with Meteor reasonably, we do with Meteor. Of course, you’re limited to MongoDB if you do this, but you can always incrementally adopt Apollo when you need to connect to different data sources. And if Prisma helps you do your work faster, then use it. In my opinion (I’m full of them), many people try to find the “one” tool to do everything, but the fact is every tool serves a different purpose. Choose your tool wisely, and don’t be afraid to use different ones.
4 Likes
@diaconutheodor We’re considering all the options tending towards Meteor and Apollo, including our continued use of Grapher and RedisOplog. As rightly said by @michaelcbrook - many people try to find the “one” tool to do everything, including myself. For us, Meteor remains our main platform. After researching about it and from your comments and suggestions, Prisma is still really in its infancy compared to the great community around Meteor and GraphQL. GraphQL has support for all databases, so also is Grapher, which is a plus for future plans; unlike Prisma. For now, we have decided to continue using Meteor+Grapher+RedisOplog+Mutation…we actually love the new Mutation pattern introduced by @diaconutheodor … though very opinionated. Maybe in the future, we’ll add Apollo to the mix. Thanks everyone!
Your choice is solid, one reason for choosing Apollo is that you have built-in API that you could use in your Mobile/ReactNative apps.
So even if it’s more comfortable the MGRM stack (closer to Meteor’s way of doing things), we need to move our thinking a bit away from the old and start embracing the new.
My advice for you would be to rethink your decision, Apollo is really easy to be honest, give it another chance 
1 Like
Solid points you have made here. Apollo is easy and at the same time future-proof. RN is another thing to consider, but meteor already has third-party support for RN via the npm package react-native-meteor. The only thing I see Apollo truly bringing to the mix is developer happiness through all the convenience it brings during development. Grapher already can be used with external data sources. @diaconutheodor Your packages GraphQL Bridge and Meteor Apollo are under consideration. Thanks again!