I would suggest thinking carefully about this though - it’s going to take us many months to build up the same smooth experience you get when developing with Meteor today on top of GraphQL. So for many apps it might not be worth it to switch over for a long while, even though it is an exciting technology.
However, I completely agree that it brings a lot of benefits once you get it up and running!
Yeah I guess just having seen the turmoil in the Meteor community recently I think it’s important to differentiate between “there is a new thing to play with” and “you should start rewriting your app to use a new thing”. I’d rather that there is a coherent story first, and then people can migrate once, rather than building on a constantly shifting foundation.
The reason this project is taking longer than you might expect to whip up some beta-quality libraries, is that we are trying a new approach: Building production-first. We are currently investigating production apps and established companies to collaborate with closely on a set of production-ready tools. That way, when we bring it to everyone, we can be 100% sure it’s already seen some amount of real-life battle-testing.
I have different opinion on this. I understand from MDG point of view that they wanted to be close to the production shops and from marketing perspective it does makes sense. But from an objective implementation point of view, you will be missing out on the diversity of opinions, if the initial versions are only given to established companies. The issues that are priority to established companies might not be a priority to solo developers and small shops and you will be missing out on the crucial component, of the community feedback at this stage.
Rather, what MDG should do is to have a representative members of community be part a group along with established companies and work to include all ideas from the groups in to the pot and that would result more refined product. At this stage it is more important to have the stakeholders be engaged and be part of the process to contribute than work behind closed walls with few players and have this big bang product right out of the door.
MDG are wanting to do their own thing… and wanting to do their own experiments in their own production driven way. But there’s a limit to the amount of different approaches they will attempt. They may or may not come up with a fantastic way to do things.
Arunoda likes chucking stuff out there, may or may not be the best way forward,but more importantly it may inspire others. Often cool things happens when a dev plays with something and recognizes simple ways to achieve what they want. We may get a reactive GraphQL stack through the innovations people come up with. At the very least, more people will experiment with things. More ideas in the mix.
The initial release of Apollo (or really, any release) can’t be all things to all people. At the end of the day, I think the project will fail if it isn’t the absolute best option available for a specific use case. It can’t just be kind of good for a lot of different use cases, it needs to be head and shoulders above for some segment of apps. And then we start to expand that segment with more input from the community. But I think the first version has to be very focused in order to get people invested outside of just general interest.
And I think anything we are working on will be compatible with the whole GraphQL community. Which is why we are learning and blogging about GraphQL in general. You’ll be able to use Lokka as a client, you’ll be able to use Relay as a client, you can use Graphene for the server if you like, etc.
So I think this is very different from previous Meteor projects in that we want to be part of a growing community and contribute to that, instead of starting to build all parts of the stack at once and trying to replace everything existing.
What would your opinion be on a startup that’s currently just implementing the database model (but want it to be working within the next weeks) to use? Do you think it would make sense to use Kadira’s GraphQL implementation and then switch over to the official implementation once it’s out. I don’t want to have huge rewrites happening in a few months from now obviously.
So I am wondering perhaps the Kadira way works, it’s not perfect but at least we have the general GraphQL mechanics working and have an idea of the possible workflow. Once Apollo is out this might be easier to switch from Kadira GraphQL to Apollo rather than MongoDB to Apollo?
Yeah I think you’ll be totally fine if you get started on using GraphQL now. At the end of the day, GraphQL is a standard and we’re going to be compatible with that!
Yes, this is true, since most or all of your GraphQL-related code will still be usable! If you are starting a new app today and you using GraphQL seems like a good approach, then by all means go for it. I just wouldn’t recommend starting to rewrite your existing working apps with GraphQL unless you’re really sure it’s the right path for you right now, since the ecosystem is still quite small and there aren’t good solutions for everything.