Apollo's company blog covers its GraphQL client and server tools, with posts on queries, state management and realtime data.
HN links it for GraphQL features like subscriptions, request waterfall optimization and upcoming specs, and for Apollo job listings. One commenter criticizes inefficient queries.
I'm genuinely surprised by the number of people on HN who seem to know very little about what has been safe to call the successor to REST for quite some time.
Forgive me if this sounds hyperbolic, but unless you have unusual or strict requirements, building a new app in 2017 REST-first is most likely a terrible mistake.
Let me clear up some misconceptions I see in almost every HN comment thread on GraphQL:
1. GraphQL isn't more suited to Graph databases. Your data sources can be a mix of relational DB, NoSQL, key value, a REST API, or anything else.
2. n+1 has always been a solved problem in GraphQL thanks to DataLoader[1], a query batching utility which coalesces calls to your data sources from different parts of your app, specifically to avoid n+1.
3. It's unquestionably production-ready, battle-tested, has a real spec and official reference implementation, and it's probably the safest bet you can make at this moment in an industry as fickle as this.
With GraphQL you simply write your schema, define types and relationships, and you’re then able to request data in almost any shape you wish, with very little extra work. This is invaluable during development.
If you have a list of recent comments with author names, and later decide to show an avatar alongside the name, you don’t need to write any extra code on the server. You add an extra line to your query (or component’s fragment) on the client.
The same goes for any field, any relationship, no matter how complex…
Hi, I'm from the Apollo Client team.
We're going to write some more content in the coming days or weeks about the differences, but here are some of my main thoughts based on following along during Relay Modern development:
1. Relay uses a build process to generate code for queries. That allows some better performance optimizations and static typing out of the box. However, it prevents you from doing anything which requires arbitrary knowledge of the queries at runtime. It also means that if, for some reason, you can't use the build tooling, you can't use Relay. That's actually the original reason we started working on Apollo instead of using Relay ourselves. Apollo works with regular GraphQL ASTs at runtime, so you can use and write tools to work with those queries in any way you like. While it's not something all apps need, we've found some situations where this is desirable, especially for developers building companion libraries.
2. Relay doesn't have as many facilities for updating the store and working with mutation results. Apollo Client has a unique way to use GraphQL fragments and queries to read and write to/from the store, the most recent of which is described here: https://dev-blog.apollodata.com/apollo-clients-new-imperative-store-api-6cb69318a1e3
3. The Apollo Store is a plain JavaScript object, which means it can be easily serialized, persisted, hydrated, etc. So for example doing server-side rendering where you also hydrate the state is super simple in…
Quiver looks interesting, congrats on launching! It seems like it will be very useful for internal GraphQL APIs.
It does bring up something that I think the GraphQL community hasn't really addressed well yet though... Part of the way Quiver works is that it only allows pre-defined queries which can then be compiled ahead of time.
> Only allow certain queries from a document store.
This is becoming a common response for how to make GraphQL performant and "secure". [1]
But this solution only works for internal APIs. If you're trying to expose a public GraphQL API it isn't viable.
Not only that, but to sync these "persisted" queries from the client to the server, lots of the persisted query tools require you to hard-code GraphQL queries as `.graphql` files in your repository... effectively re-inventing hard-coded REST responses. Except with an extra build process between the client and the server for each new deploy. You no longer really have each component requesting exactly what it needs.
The more research I do into GraphQL, the more it seems like the promise of "query anything" that libraries are selling is often discarded when you get to actual implementation. And you end up with a situation that is much more similar to REST/HTTP than originally intended.
[1]: https://dev-blog.apollodata.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5
Meteor Development Group | Open Source Engineers, Back-end Engineers, Front-end Engineers | San Francisco, CA | Full-time, Onsite and Remote
Back-end Engineers: Build the foundations and APIs of our tools for GraphQL and JavaScript developers. You'll have the opportunity to learn and use the most cutting edge technologies as you help shape and deliver the components that make up our commercial cloud services, Optics and Galaxy. You will work with a team of talented engineers to build performant and scalable services in modern languages like Kotlin and Go.
Front-end Engineers: Design and owns new features for our commercial products, Optics and Galaxy, and our open source projects, Apollo and Meteor. You will be helping to develop the best practices of front-end engineering with a team that has a history of pioneering JavaScript tech.
Open Source Engineers: If you like doing the things above AND attending & speaking at conferences, writing blog posts and teaching people about the latest developer tools, you might be interested in joining our open source team.
If you're wondering what GraphQL and Apollo are all about: https://dev-blog.apollodata.com/
Our job site: https://www.meteor.io/jobs/
> - However the worst thing so far to me has been i have watched as UI developers go from writing simple rest queries, and doing a bit of work on the front-end to writing extremely inefficient and convoluted queries. Even worse is when a third party is doing it and i have no say over what they do with it.
To your last point, there are a few ways you can provide feedback on or limit the cost of your queries. I'd recommend checking out Github's article on resource limitation [0] and the section on query cost analysis in an article by the Apollo team [1].
[0] https://developer.github.com/v4/guides/resource-limitations/
[1] https://dev-blog.apollodata.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
Even though subscriptions are very much in progress from a specification point of view, the community came up with different approaches that are already employed in practice.
Here are some additional resources:
- RFC for GraphQL subscriptions: https://github.com/facebook/graphql/pull/267
- How to use Subscriptions in GraphiQL: https://dev-blog.apollodata.com/how-to-use-subscriptions-in-graphiql-1d6ab8dbd74b
- Using GraphQL Subscriptions with Apollo: https://www.youtube.com/watch?v=wo9XFmW0W2c
If you want to use GraphQL subscriptions right now, I encourage you to try out our demo over at https://demo.graph.cool/worldchat/. I work at Graphcool :)