I'll second Jonas in being amazed and humbled by the GraphQL community. There is just so much great stuff going on right now. Apollo is doing great work and we use the Apollo Client for most of our examples at Graphcool.
I'm happy to answer any questions about the GraphQL ecosystem as well as how it might fit for your specific use case.
First, a huge congratulations to the Apollo team! You have more than delivered on the original promise of the Meteor group.
I am really excited about the proliferation of GraphQL APIs as they replace standard REST endpoints! When I heard that GitHub released a beta of their API with a GQL endpoint, I immediately wanted to try it out.
I learned, however, that it is extraordinarily difficult to connect to multiple GQL endpoints with a single Apollo client. I cannot even imagine how that would work. Should a single GraphQL endpoint have "clients" of its own, through which it could proxy requests to other endpoints? Should the front-end application have multiple clients, each with its own endpoint? There are a lot of easy, inelegant solutions which come to mind.
Several GitHub issues reference similar ideas, but there is no clear solution. Do you have any thoughts about how an application can conceptually replicate the simplicity of REST requests to multiple & diverse endpoints, when the endpoints are GraphQL-structured?
We at Graphcool (https://www.graph.cool) are super excited about this release as the majority of our customers are building their apps with Apollo Client.
For people just starting out with Apollo: With tools like graphql-up (https://www.graph.cool/graphql-up/) it's super easy to get a GraphQL API for your Apollo apps. We're looking forward to contribute more to Apollo and its ecosystem going forward!
I've just started working on a graphql project now and from the frontend perspective its phenomenally better than a rest api. The backend side of things is also pretty simple so I'm really enjoying it.
With Rest APIs there's always the problem (with numerous solutions) of how you select the particular fields and how you nest and or do not nest the resources in the api. With GraphQL this is more or less a non-issue - the client just requests want he wants and gets it back if he's allowed access to it.
I know GraphQL has been around for a while but this has been my first full go with it and I could easily forsee it doing to REST what REST did to SOAP - at least for the use case of building frontend clients that consume some api.
I'm kind of hoping that nesting resources becomes a non-issue in the future once HTTP/2 is widespread. Ideally you don't ever nest resources. With HTTP/2 the overhead of additional requests can be significantly lower, and you get the benefit of using client cache.
This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (up-to-date) copy of.
Nesting resources is a bit of an anti-pattern imho, and the solution looks bad because it's a poor fit in the protocol.
Of course, all of this is a bit of a moot point if you don't believe in addressable/linkable resources as a good solution. If you're not doing/believing in hypermedia in REST, you're much better off with something like GraphQL because it provides a very complete solution. You just need a ton of domain knowledge to be successful at proper REST.
But you're still going to make lots of requests which result in inefficient data access on the server unless you batch them up. So you just end up moving batching from the client where it is easy, to the server where it is hard.
It's hard but solvable. If the data comes mainly from one database (although you can do some cools stuff with FDW in Postgres) then each graphql query can be translated to a single SQL query and it works quite efficiently, only one trip to the db (https://subzero.cloud/)
HTTP/2 doesn't fix the problem of loading data dependencies over a connection with a noticeable round trip latency. Even with server push, you need some way of defining what is to be pushed.
As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.
Of course, there are ways of defining inclusion that are closer to restful than graphql is.
Falcor sort of solves this by allowing you to communicate "references" in the graph. For example, it might inform you that users.52.friends.1 is actually users.45, so the client will cache it at that location instead.
This is less complicated than GraphQL's solution of using the Relay Node interface.
That solves the problem of data normalization, not of determining what to fetch. Falcor solves the second problem with paths, but that's still a custom abstraction that the API has to understand.
GraphQL has a lot more to offer than just batching requests. I think that's one of the less important features actually. A common way to declare exactly what objects and attributes you want is more important, you can invent something like that for REST but you'd be reinventing the wheel for every endpoint.
Exactly. For the first time you have a common language to talk to your RDBS, NoSQL db, cache system and API, or a mix of all of them transparently, from anywhere in your architecture, including remote microservices and the browser.
sure it will. client requests a resource, server sends back the response with some links to further requests. it can also send the results of those requests with zero intervention from the client. when the client requests them, they're already en route or cached locally
this assumes you have high confidence the client will actually request those links (or you can afford to send them even with low confidence) but you can use media types or query parameters to mitigate that
Let's look at an analogy: Amazon Prime delivers in a day by now. With the customer info, Amazon can also send stuff directly/monthly. That's HTTP2.
The user chooses several products in one order. When you add the product in the basket, Amazon suggests some products that are often ordered at the same time, like extra supply or accessories. That's GraphQL.
GraphQL assumes shipping something cost money, and forces the client to declare what it wants explicitely and in detail. Like SQL without SELECT *.
Hope that helps!
I just started diving into using Apollo client the an Elixir backend (using Absinthe). It's an amazing combo! I look forward to more releases from the Apollo team.
Interesting I'll need to look into how well the Apollo Client plays with Redux and Redux Saga since I'm using them in my stack. I had assumed that it was more "apollo-focused" and thus wouldn't play nice.
I'm such a fan of the apollo development community and how it is lead by some awesome individuals. Not good enough to contribute myself, but just watching the github conversations and the development phase is really cool.
Hey, Sashko from the Apollo team here - we're excited to keep improving Apollo Client and build more awesome tools for GraphQL development! If you're excited about this space and want to work on open source and also commercial products for GraphQL, we're actively hiring for a variety of positions: http://jobs.meteor.com/
Hi Sashko.
I have been working a few years ago on a visual query builder for SPARQL. (Cf datao.net)
May be you can find some inspiration for visual tools on top of graph query languages.
Mutations are much simpler. Cache updating is flexible and easily customised. They have subscriptions and polling. Fetch More for pagination. Generally clear and flexible to work with
We've been working a lot with Graph.cool recently in conjunction with Apollo. It's a powerful combination and each day we are learning of powerful ways of working with our data. Our data is going to be heavily dependent on the relationships we build between each model. All very exciting. Easier now to build apps on both web and native that share their data.
I've been using Apollo now for the last month or so, in production and I have to say that it's been a fantastic tool to work with. The community and the team behind it are also second to none out there; hugely friendly and incredibly helpful. Check out their Slack channel if you run into any issues!
I am wondering the same thing. I believe they wanted to appeal to the broader JS community first, then build in reactivity to Meteor. That is the only reason why I haven't picked it up yet.
Using apollo with react native has been a great experience. works well with react navigation and graph.cool as well. Only thing I would improve is the subscription features. Feels kind like theres a lot missing in subscription to customize depending on application. Like applyMiddleware and other hooks .
I love graphQL and Apollo's React work flow that mimics Redux's HOCs. The addition of it probably increased the maintanablity of my apps 5x.
Added bonus, I found a backend as a service that that works perfectly with Apollo.
Graphcool has increased the maintainability of my app ten fold. I no longer mess with writing my own reducers for the backend. The Graphcool community is also great; they are very helpful on slack and put out a ton of content on top of there great docs.
Watch this video; if you already use graphQL you'll be hooked on Graphcool:
I tried integrating Apollo with my Redux app a few weeks ago but found it very confusing, so I just made my Redux app work with my GraphQL Rails backend without Apollo.
Relay has some nicer ergonomics when it comes to composing queries from fragments for different components, and the mutation behaviour is a bit more "magic", but both of these benefits come with some serious restrictions on what you can do. The next version of Relay looks like it'll do away with this approach, bringing it closer in line with how Apollo does things right now.
I'm a heavy user of Relay (been using it since it was first open-sourced around 18 months ago), but given that it's going to be changing quite a bit in the near future, I think newcomers to GraphQL are going to be better off with Apollo for now.
Thanks. Yes I too am using soon-to-be classic Relay. I've enjoyed transitioning to Relay.GraphQLMutation and can't say I miss the fat query. So Relay "modern" will be like Apollo... interesting.
I've been using GraphQL with Apollo and Absinthe/Phoenix for a civic data gerrymandering project. Fantastic combo and everything plays well together. Certainly looking forward to using this stack on something big and bad in the near future.
Not GP, but I've been using it for the last several months and overall its been incredibly pleasant to work with. Bruce Williams and Ben Wilson have done a fantastic job with the API, and they are incredibly helpful on the slack channel. Its basically replaced Phoenix for most of my needs, which isn't a design goal of theirs—it just works out that way.
There's a few areas the guides are a little sparse, but the API docs are pretty solid. That will improve over a little more time. There are some areas like returning errors to the client that are sort of roll-your-own in the graphql community at large, but those kinds of things for me have come down to just finding a practice that works for me and going with it. I haven't had a chance yet to upgrade to the latest version, which supports middleware and subscriptions, along with stuff I _think_ was already supported like transport-level batching.
My advice if you're thinking about using it is to build out a basic set of features with it and expand your usage—you'll find out pretty quick if you like that modality, and apollo makes a great combo with it if you do.
I'm about to start re-writing an api as GraphQL, I'm looking at the comments of support for Apollo, and looking at their webpage, but I'm failing to see what the real benefit is.
What is the problem with GraphQL that they are addressing?
Thanks Jives, but that still doesn't really help, does it? GraphQL from a client side are just json requests/responses, right? Am I missing something else?
My favorites are the collection of functions offered by the graphql-tools package. Like composing your schema from strings instead of the verbose JSON definition. The mocking is also neat.
Apollo is really just a tool-box of a lot neat little things that you can put together or omit. Check out their other packages beside apollo-client.
From what I can tell, Relay and Apollo serve as an implementation of functions you'd need to write to organize the fetching of your data on the client side. It turns things like "oh, in componentDidMount I need to fetch a route and update that data inside the store I'm using" into "Hey Relay this component needs this data before it loads".
Relay I think is a more opinionated and heavier weight option, with the benefit provided being that it intelligently aggregates queries based off fragments and allegedly handles caching (minus invalidation, so you could argue that it doesn't really handle it ;) )
Fwiw in the project I'm working on now we judged that the extra complexity of a data fetching layer like Relay or Apollo wasn't worth it for us. We may have come to a different conclusion with a different project. Ymmv
GraphQL and Apollo literally saved our app. Before we made the switch, we were plagued with issues from other providers such as technology stack compatibility issues, queries making issues and more.
We actually made the decision to switch to GraphQL 1.5 weeks prior to deadline and was able to get configuration and queries going in almost no time at all. I know I sound like a commercial right now but it seriously was very easy to setup and the querying learning curve was minimal.
The console is easy to use and the combination of the Playground with Mutation Callbacks helped me to setup and test my first AWS Lambda function of which I was able to do within 2 days and the AWS learning curve is not so easy to absorb.
Aside from all of this, the Graphcool team was very helpful and right there when we needed them whether on chat in the console or on Slack.
This is not a knock on Apollo in particular, but I am wholly underwhelmed by what gets hyped up in this industry. There isn't anything novel here. A new generation of programmers rediscovers Remote Procedure Call (they call them mutations), schemas (NoSQL was so last year), and various older concepts and rehashes it while putting down a strawman they claim is Representational State Transfer (which if they read the thesis, they would realize that their concerns are nitty gritty details which are only tangentially related to the architecture described).
Also the community-focused angle is disingenuous. It's backed by venture capital of the Meteor Development Group and based upon a single vendor specification, GraphQL by Facebook.
Many great open source products have huge commercial backers--the important thing is that there is a community, which is in fact very true with Apollo.
I get what you're saying and I'm sure there is lots of truth to it--that doesn't make what's going on now the best to ever do it (i.e. the fastest way to produce the most meaningful user experiences). If it wasn't the case, we'd be doing remote procedure calls in C or whatever.
Bottom line: ur point is one that should be heard, but there's a way more value could be added in how you present it.
I have been working on a project using Apollo and React for both web and native and it has been a real pleasure. Apollo + graphql has made so many things that would have been a huge mess with redux and a rest api so much easier and cleaner.
Anyone use graphql with fire base? I'm curious on the use cases.
I did a test project in react native with fire base and it felt like early days of Meteor. Apollo's architecture may or may not conflict with firebase in an app. Anyone have some insights?
80 comments
[ 3.2 ms ] story [ 145 ms ] threadI'm happy to answer any questions about the GraphQL ecosystem as well as how it might fit for your specific use case.
I am really excited about the proliferation of GraphQL APIs as they replace standard REST endpoints! When I heard that GitHub released a beta of their API with a GQL endpoint, I immediately wanted to try it out.
I learned, however, that it is extraordinarily difficult to connect to multiple GQL endpoints with a single Apollo client. I cannot even imagine how that would work. Should a single GraphQL endpoint have "clients" of its own, through which it could proxy requests to other endpoints? Should the front-end application have multiple clients, each with its own endpoint? There are a lot of easy, inelegant solutions which come to mind.
Several GitHub issues reference similar ideas, but there is no clear solution. Do you have any thoughts about how an application can conceptually replicate the simplicity of REST requests to multiple & diverse endpoints, when the endpoints are GraphQL-structured?
We at Graphcool (https://www.graph.cool) are super excited about this release as the majority of our customers are building their apps with Apollo Client.
A few months back we launched Learn Apollo (https://www.learnapollo.com/) here on Hackernews which so far has helped thousands of developers to get started with Apollo. (HN Link: https://news.ycombinator.com/item?id=13187431)
For people just starting out with Apollo: With tools like graphql-up (https://www.graph.cool/graphql-up/) it's super easy to get a GraphQL API for your Apollo apps. We're looking forward to contribute more to Apollo and its ecosystem going forward!
With Rest APIs there's always the problem (with numerous solutions) of how you select the particular fields and how you nest and or do not nest the resources in the api. With GraphQL this is more or less a non-issue - the client just requests want he wants and gets it back if he's allowed access to it.
I know GraphQL has been around for a while but this has been my first full go with it and I could easily forsee it doing to REST what REST did to SOAP - at least for the use case of building frontend clients that consume some api.
This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (up-to-date) copy of.
Nesting resources is a bit of an anti-pattern imho, and the solution looks bad because it's a poor fit in the protocol.
Of course, all of this is a bit of a moot point if you don't believe in addressable/linkable resources as a good solution. If you're not doing/believing in hypermedia in REST, you're much better off with something like GraphQL because it provides a very complete solution. You just need a ton of domain knowledge to be successful at proper REST.
As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.
Of course, there are ways of defining inclusion that are closer to restful than graphql is.
This is less complicated than GraphQL's solution of using the Relay Node interface.
this assumes you have high confidence the client will actually request those links (or you can afford to send them even with low confidence) but you can use media types or query parameters to mitigate that
The user chooses several products in one order. When you add the product in the basket, Amazon suggests some products that are often ordered at the same time, like extra supply or accessories. That's GraphQL.
GraphQL assumes shipping something cost money, and forces the client to declare what it wants explicitely and in detail. Like SQL without SELECT *. Hope that helps!
Cheers...
I also found it fairly straightforward to set up Server Side Rendering (SSR). My example is at https://github.com/rattrayalex/isomorphic-react-relay-router... if it helps anyone, though it's a year out of date.
EDIT: A more up-to-date example at https://github.com/rattrayalex/django-graphql-react-ssr/blob... – meant to open-source it as a simple SSR lib.
Watch this video; if you already use graphQL you'll be hooked on Graphcool:
https://m.youtube.com/watch?v=5uxq8Om-AZQ
Here's the code:
https://github.com/graphcool-examples/react-apollo-auth0-exa...
I'm a heavy user of Relay (been using it since it was first open-sourced around 18 months ago), but given that it's going to be changing quite a bit in the near future, I think newcomers to GraphQL are going to be better off with Apollo for now.
There's a few areas the guides are a little sparse, but the API docs are pretty solid. That will improve over a little more time. There are some areas like returning errors to the client that are sort of roll-your-own in the graphql community at large, but those kinds of things for me have come down to just finding a practice that works for me and going with it. I haven't had a chance yet to upgrade to the latest version, which supports middleware and subscriptions, along with stuff I _think_ was already supported like transport-level batching.
My advice if you're thinking about using it is to build out a basic set of features with it and expand your usage—you'll find out pretty quick if you like that modality, and apollo makes a great combo with it if you do.
What is the problem with GraphQL that they are addressing?
Apollo is really just a tool-box of a lot neat little things that you can put together or omit. Check out their other packages beside apollo-client.
Relay I think is a more opinionated and heavier weight option, with the benefit provided being that it intelligently aggregates queries based off fragments and allegedly handles caching (minus invalidation, so you could argue that it doesn't really handle it ;) )
Fwiw in the project I'm working on now we judged that the extra complexity of a data fetching layer like Relay or Apollo wasn't worth it for us. We may have come to a different conclusion with a different project. Ymmv
We actually made the decision to switch to GraphQL 1.5 weeks prior to deadline and was able to get configuration and queries going in almost no time at all. I know I sound like a commercial right now but it seriously was very easy to setup and the querying learning curve was minimal.
The console is easy to use and the combination of the Playground with Mutation Callbacks helped me to setup and test my first AWS Lambda function of which I was able to do within 2 days and the AWS learning curve is not so easy to absorb.
Aside from all of this, the Graphcool team was very helpful and right there when we needed them whether on chat in the console or on Slack.
Also the community-focused angle is disingenuous. It's backed by venture capital of the Meteor Development Group and based upon a single vendor specification, GraphQL by Facebook.
I get what you're saying and I'm sure there is lots of truth to it--that doesn't make what's going on now the best to ever do it (i.e. the fastest way to produce the most meaningful user experiences). If it wasn't the case, we'd be doing remote procedure calls in C or whatever.
Bottom line: ur point is one that should be heard, but there's a way more value could be added in how you present it.
Shameless plug we just released our app today that would not be possible if it weren't for Apollo.
If you're interested in exploring fashion, check out Nelo on the app store:
https://itunes.apple.com/ca/app/nelo-shop-tv-fashion-and-dre...
Anyone use graphql with fire base? I'm curious on the use cases.
I did a test project in react native with fire base and it felt like early days of Meteor. Apollo's architecture may or may not conflict with firebase in an app. Anyone have some insights?