> On top of these, we built new tools and workflows for GraphQL developers. The new Apollo VS Code plugin puts valuable information about your schema — like the average latency of a specific field — right at your fingertips at development time.

That's kind of a stretch for Netflix. A few teams recently started an evaluation pilot, and even that is only for internal tools (i.e. not Netflix.com). There are no current plans to use GraphQL for anything customer facing at Netflix. Nothing against Apollo, but I'd hate for people to get the wrong idea.

Meteor has been a bit of an afterthought at MDG the past 2 years because of apollo. Currently only developed by 1 member of MDG. However it has opened more towards the community and aligned with the rest of the JS ecosystem. The awesome work of Benjamn has made it the best dev experience around IMO, but it seems to have lost a bit of momentum. I hope they could put some focus back on it with the money that Apollo brings, but that's probably naive. They have to answer to their investors...

Despite that, I wish more time were invested in the OSS native apollo libraries (iOS, Android). There still isn't a way to do cache invalidations, and both libraries (perhaps understandably so) are well behind apollo-js in features. I would build something myself as a PR (and perhaps this is a problem with most GitHub projects), but non-trivial PRs seem to be left sitting for months or never touched at all by maintainers.

I bet the Apollo folks are just focusing their efforts where interest lies, but there really isn't a great, fully-featured OSS graphql client for mobile right now. React Native + apollo-js does not count to me: I have never used a React Native app I've felt acceptable on Android, and have only found marginally acceptable iOS apps in the wild.

This looks really interesting. (And in case anyone from the Apollo team is reading - just want to say I'm a huge fan of the product in general. Keep up the great work!)

The one thing that seems like a bit of a tough sell with this announcement is it looks like a lot of these integrations are pretty deeply intertwined with different parts of the framework and might not be easy to set up if you're using just the Apollo client and not the server. Just browsing quickly I see that some of the components require some workarounds and proxies and such with other backends. The post talks about making it easy to incrementally add graphql to existing apps, but for any apps built in languages other than NodeJS I'd worry that it might not be a first-class experience to use the entire platform.

I'll definitely have to look through the docs more thoroughly though, there's a lot here.

This is awesome. I wonder how much the Enterprise Graphql Gateway is, our app is under a million queries a month, but right now I instantiate multiple apollo clients which point to different Graphql endpoints because we do not have a gateway. I would love this but I am not sure if it makes sense for our case from a cost perspective.