What are some of the challenges that Apollo is facing now? Right now the biggest challenge is scoping down our goals to a sustainable level. GraphQL is such an exciting new opportunity that it's easy to get distracted and build a ton of stuff, but we need to stick to only what we can reliably maintain in the long term. Of course as we grow our organization we'll be able to tackle more cool ideas! What's next in the pipeline? Given the above, right now we are focusing on creating a great set of open source GraphQL clients that let you integrate your GraphQL data into any of your new or existing apps. This includes, primarily: React + React Native Angular iOS Android It will include some cool bells and whistles to make GraphQL fun for example possible subscription support, but the main goal is to build something straightforward that people can start using right away. On the other side of the house, we are working on some great production tools to help people learn about, build, and scale GraphQL in their organization. More news coming soon about these products -- I'm working more on the open source side, so I don't have as much info on the services aspect.

Hi David, This is something we've always been interested in, but would probable be best driven by a community contributor planning on using it in production. Apollo Client interacts with Redux in exactly three places: It passes in a special Apollo reducer, which should just work with ngrx out of the box It uses dispatch to fire some actions, which should just work out of the box It uses a middleware to catch store updates and broadcast them to the observable queries: https://github.com/apollostack/apollo-client/blob/f76ad1bc7a5f2fb1e31f75a02332a398e022423e/src/index.ts#L268 (3) is the only part that wouldn't just work with ngrx, since it doesn't have the same middleware API as Redux, but it seems like it would be trivial to just observe the store in some different way, and might just require a change in that one function and some basic tests to check that it works. I'd be happy to work with you on a pull request to Apollo Client to integrate with ngrx if you're interested!

I use Atom for general editing, and Visual Studio Code for TypeScript! I'm a big fan of static typing and nice IDEs, and I'm excited that VS Code + TS gives me a similar experience for JavaScript development. Mostly over GitHub - we reply to pull requests and have discussions on issues. We also have a community slack channel that you can join to talk about GraphQL/Apollo stuff, were we also talk to contributors in more depth. When it comes to complex discussions we try to do video calls, since sometimes comments just aren't enough. Honestly I'm terrible at productivity. My only hack is trying to clear out huge chunks of time to do coding without being interrupted by meetings. Perhaps one more useful thing is splitting all tasks into the smallest chunks possible, so that a huge task doesn't get interrupted in the middle. The worst thing is having a long-running branch that can't be merged because of tons of conflicts.

We all work at the same company - Apollo is a new project brought to you by the same people that developed Meteor, but focusing specifically on data management. Apollo actually started out many months ago as a plan to upgrade Meteor's data layer, especially to support multiple backend sources like SQL and microservices. As we talked to more people we figured out that this technology would be very useful for the application development community as a whole, so we decided to make it a separate project that can be used both inside and outside Meteor. In Meteor 1.5, we're going to start making the integration with Apollo much more straightforward, so that people who like the other aspects of Meteor (integrated build system, accounts, mobile app compilation, etc) can also take advantage of all of the data loading benefits of Apollo. Since Apollo addresses so many of the concerns people have had historically with Meteor's data system, including the ability to use different data sources, turning off reactivity, native mobile app support, and more, we are spending most of our time working on Apollo which we think will bring huge benefits both to Meteor developers and the wider application development community. However, we're committed to continued development of the Meteor framework, both by implementing stuff ourselves and moving to a much more community driven development process (something that the Meteor community has wanted for a long time, and what we're doing with Apollo from the start). Just yesterday, we shipped Meteor 1.4, a huge release which includes a ton of core improvements and upgrades to Node 4 and MongoDB 3.2.

We're actually really happy with our setup on the Apollo Client repository, and we even blogged about it . Here is a summary of what has been particularly helpful: TypeScript to get static typing and great editor integration with VS Code. This saves us from a huge potential set of refactoring errors, and is especially useful since we have to often deal with quite complex data structures. We also looked at Flow, but the simpler setup of TypeScript was a big win for getting contributors going quickly. Unit tests on CI, with test coverage reports on Coveralls. These really help us ensure that our tests are passing, and that all significant logic in the package is well-tested. With these tools set up, we are pretty confident that if our CI builds pass the final build will work for people, although no setup is perfect of course.

Hi Jan! Now that we have a lot of the basic features working in Apollo Client, we're starting to look at performance as well. Since we are using it in production, this is a big deal for us as well. We did two things in particular recently to improve performance based on what we saw in our production app: Aligned poll intervals so that multiple polling queries from different components are sent in one request Did data comparisons in observable results to avoid unnecessary UI rerenders These resulted in some great improvements already, and we're always looking for ideas about performance wins. Read all about it in our blog post here: Snappier UIs with Apollo Client and GraphQL This isn't mobile-specific, but any performance improvements about reducing CPU usage will help a lot there. One thing that I will say is that Apollo Client internal logic about normalization has never showed up in our CPU profiles at all, so I don't think it's a big problem right now. In fact, it already saves you a lot of work because you don't have to write manual shouldComponentUpdate functions in your UI components after the new features.

Apollo is still relatively new, but we've been testing it in production in our own apps and with contributors from the very beginning. Right now the main apps that I know of are: Meteor Galaxy - unfortunately the app itself is behind a paywall, but you can watch this talk on YouTube about how we did it: https://www.youtube.com/watch?v=xwz1aXkJLLA NewSpring Church giving app , see a video about it here: https://www.youtube.com/watch?v=RGfn8GfC_uE The preview of Apollo Optics, a production GraphQL insights service we're working on, is also built with Apollo from the start. We need to do a good job of collecting a concrete set of apps built on it - I'm sure I've missed several out there. Hopefully soon we'll get a good list of production apps up on our website, I think that will help people decide if they should use it or not.

There's another question about production apps, so I'll focus on open source examples here. The main example app we have, which covers a relatively large range of features, is GitHunt: https://github.com/apollostack/GitHunt This app includes examples of queries and mutations, and how those might work with routing, UI components, etc. There are directions for how to run the app in the repository. You can also look at the home page of our docs for more community-contributed code samples: http://docs.apollostack.com/#Example-apps

Thanks for the question, Sergio! First, I think there is room for many great GraphQL clients in the ecosystem. Here on the Apollo team, we think GraphQL will be the next big way to load data after REST, so we think the ecosystem is just getting started and eventually there will be tons of options for servers, clients, tools, and more. So it's not about superior - it's about looking at the different options out there and seeing which one meets your needs the best. But we're committed to making it a long-term project -- we're already using it in production in two of our apps, and will be continuously developing it over the coming years. Our goal is to build a sophisticated GraphQL client that can be a more flexible and hackable alternative to Relay. Relay is, at the time of writing, quite opinionated about a variety of development decisions, in large part because it is focused primarily on Facebook's application development needs. It only works with React, it requires specific schema features on the server around pagination, mutations, and refetching individual nodes, it is coupled to specific concepts about routes, fragments, and containers, and only supports several specific ways of using mutation results that don't always match the situation. If you like this approach, then Relay is awesome - it does a lot of work for you. I'd encourage you to keep using Relay if you love it. We found that not all of these opinions worked for us, and we needed something that we could hack on to build new features, and easily debug by inspecting store state. So while in the overall architecture Apollo Client is extremely similar to Relay, with a normalized cache of GraphQL data, we decided to go with a few different decisions: Apollo Client is split from the start into a core implementation that is completely independent, and view layer integrations for React and Angular 2. This means it's easy for other people to build integrations for whatever view layer they need, like Ember, Vue, or more, without needing to reimplement any core logic. Apollo Client doesn't rely on a specific schema from the server. The current features about mutations work with any GraphQL mutation you can think of on the server, and the design for pagination we are currently working on will work with all kinds of pagination formats - page numbers, pages with cursors, and relay connections as well. Apollo Client doesn't require any specific build plugins. As long as you can install the NPM package, you can start using it without needing to add anything to your build setup. This is because none of the functionality depends on having schema information at runtime. You can still use static analysis tools like eslint-plugin-graphql to validate your queries at build time, but it's not required. Apollo Client is based on Redux, which gives us great insight into how the store is changing over time and makes it easy to integrate with existing client-side data in Redux. It can also be expanded to work with other state-machine based solutions like ngrx. But if you don't want to use Redux in your app, you don't have to - Apollo Client will make its own internal store that you don't have to think about. I could keep going on about the differences, but you can see the trend - we're going for a more configuration over convention approach, so that you can take advantage of Apollo Client regardless of your client architecture, schema, etc. Lastly, once Apollo Client becomes production-ready (we have an issue open now to track necessary changes before a 1.0 version), we can use it as a platform for us and the GraphQL community to experiment with new GraphQL features and approaches, including subscriptions, live queries, offline support, and more. Because it's build from the ground up to be flexible, we envision these features will be relatively simple to add once there is a need for them. If this kind of transparent, hackable, and flexible GraphQL client sounds like a good idea to you, I'd invite you to contribute to the repository ! There are already 29 contributors, and we are looking for more great ideas, discussions, and improvements.