Jonas Helfer gave a talk about this: https://www.youtube.com/watch?v=coU6OmISOBM
572 karma · joined December 24, 2013
And even a system that generates your whole schema: https://github.com/postgraphql/postgraphql
Plus, the Graphcool framework allows you to bring your own DB: https://github.com/graphcool/framework
If you aren't yet familiar with GraphQL and the problems it solves, it might be better to watch the talk on YouTube, since it includes much more of an introduction from the start, plus more color and detail: https://www.youtube.com/watch?v=ykp6Za9rM58
The blog post summary glosses over the introduction and focuses on what a GraphQL-familiar audience will find new, so it's all in the context of the current GraphQL community.
You can also catch up on some of the tools and benefits, and see some case studies from people using GraphQL in production, on our Explore GraphQL site: https://www.graphql.com/
That's the best part - with GraphQL you _do_ know, since people have to ask for every single field they want.
Thanks for the notes!
> And immediately after that the article spends two pages of text explaining how insanely complex the "becomes easy with GraphQL" really is, and offers no actual details on the "easy" part.
Hi, thanks for this piece of feedback! I could have done a better job here, since I was summarizing a 38 min talk into a few paragraphs.
These parts are actually talking about different concepts:
The first is about ensuring that a single fetch from the UI knows about all the data it needs, so you can easily avoid multiple roundtrips to the database. This is something you can do with a basic in-process caching tool called DataLoader: https://github.com/facebook/dataloader
The second is about caching _across_ requests, something that people usually have special infrastructure for in REST, such as Varnish. This talk was elaborating on how a GraphQL-specific piece of caching infrastructure might work, and sit in exactly the same place as REST caching.
> Oh, your client has to be cache aware.
I think the intention was to say that it _could_ be cache aware. It doesn't need to be, but you end up with a really nice situation.
> I would love to see an explanation how GraphQL makes caching for this easy.
My intention here was to say that GraphQL's ability to understand what fields are being asked for makes it easy to return specific cache controls, rather than having to put one on the whole query. So your server basically generates the control for you (this is something that exists today)
> It's called REST APIs and we've known how to do them since 2001.
I don't think REST has a way to automatically combine multiple REST services, and then query them all in one HTTP request without multiple roundtrips to the client, which was the goal here.
Happy to talk more, and thank you for bringing up some of the places where I can communicate more clearly in the future! The audience of the talk was a GraphQL conference, but I should definitely consider next time that people who aren't already bought into the idea of GraphQL will be taking a look as well.
https://www.apollographql.com/engine/
(Disclaimer: I work on Engine)
> GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network.
This was a common thought when GraphQL was first announced, but working with organizations that are adopting it we've found just the opposite: It's actually the tooling and development velocity benefits that people get the most value of.
It's kind of like if you could design your API to be super orthogonal and fine-grained, while still getting the optimized network transport of hand-coded endpoints for each view.
> The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right.
The post goes over a new architecture specifically for server-side caching. Caching on the client is definitely not sufficient! And Relay isn't the way most people are doing GraphQL today. Also, clients are about to start supporting cache control and TTLs, making life a lot easier. I'm curious what the comparison here is, since people using technologies like Redux with REST APIs are also usually caching responses forever.
This is really useful feedback for those of us that think GraphQL is going to be a super important technology going forward, and I hope you give it another shot in a year or two! It's still pretty fresh, especially compared to REST, but I think it will improve quickly :]
I think there are 2 differences:
1. It's very very easy to write a GraphQL query, since GraphQL comes with auto-completing tools to do so. Even non-technical staff at our company often use it to get information about customers, etc. 2. The query is written inside the client codebase, which means you don't need to redeploy the server in response to a change in client data requirements. This reduces a significant amount of the friction caused by frontend features needing to wait on backend deploys.
Other than that, you've got it 100%: GraphQL is a technology to make the Backend For Frontend pattern much easier and more flexible.
With GraphQL, you can think of each field as a tiny endpoint, and you do access control on that in the same way as before.
It turns out that while GraphQL allows the frontend developers to select the data they need, that doesn't result in an unlimited set of queries. You often get a number of queries which is similar to what you would get if you hand-coded specific endpoints for different UI views, which turns out to be a common pattern outside of GraphQL.
> What happens if the user doesn't have access to part of the requested data
In this case, the gateway just falls back to the underlying server implementation, and it's a cache miss.
I'm glad you've been having a great time using Apollo. I hope we've been up front with the idea that we have commercial products since the start, and I think monitoring and analytics are reasonable places to do that since pretty much all of these services are paid. We also provide paid support to large companies trying to move to GraphQL and Apollo.
On the other hand, I'm excited that having a business model will continue enabling us to build great tools, and open source as much as possible. We've been very careful to make sure that all of our tools are decoupled and flexible, and don't lock you into using any other part of the stack. For example, the monitoring in Engine is based on an open source specification called Apollo Tracing: https://github.com/apollographql/apollo-tracing
In fact you could turn on tracing in your GraphQL server and pipe that data into any service you want, so it's pretty straightforward to avoid using Engine if you don't feel it's a good value for you!
Happy to answer any other questions, we're going to keep working on our stuff! Sashko
Thank you for building the ember integration, I’ve met a couple people at GraphQL summit that are really excited about it!
There are articles from GitHub, Shopify, Artsy, Walmart, Coursera, New York Times, and more! And these are just companies that have bothered to write an entire article about their experience.
I'm a big fan of GraphQL and tried to write up a more low-level comparison here: https://dev-blog.apollodata.com/graphql-vs-rest-5d425123e34b
The intention of this library isn't to change a lot about how GraphQL servers are written, it's just a stable, community focused library to bind your GraphQL server to a schema.
My interpretation is that they are now using a GraphQL API but fetching from it with regular HTTP fetches and managing data with Redux on the frontend.
You can also see a lot of examples of GraphQL server code for JS here: https://github.com/apollographql/launchpad
It includes connecting to DBs, APIs, etc.
Please add your own if you build something cool!
1. Learn Apollo, build a simple Pokedex app: https://www.learnapollo.com/
2. Freecom, an intercom clone: https://www.graph.cool/freecom/
Getting started only takes a few minutes, and you can get a taste of the awesome experience you can get as a frontend developer building on GraphQL.