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.
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.
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!
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
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.
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.
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!
We're excited to keep working to push the limits of GraphQL by supporting awesome features like subscriptions, persisted queries, and much more!
If you're in SF come to meteor tonight for the GraphQL meetup and let's talk about what's coming next.
Now working with GraphQL in production, I would NOT recommend using it, especially if security is a concern. We're now implementing persisted queries, which means we call a query ID and return a predefined query/mutation. This essentially turns GraphQL into something like a Rest endpoint.
GraphQL was fun to use in the building stage and did make things easier to me as a front end developer. But as we made iterations on our schema and application, I think GraphQL added more work because there were so many more details to manage in the queries.
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?
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
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.
I just got to plug graph.cool too for people interested in GraphQL and Apollo. I've been using it for quite a while, and the platform has been working great. I've been chatting quite a lot with their support (hey Nilan if you see this ;)) and they've been very helpful both in matters concerning the platform, but also for my app and GraphQL in general. I really recommend trying it out!
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.
Edit: I guess you do something like this: https://github.com/RisingStack/graphql-server/blob/master/sr...
The ability to express your schema in GraphQL instead of JS is especially nice. The server+client Apollo experience is really nice if you give it a try, and judging by the roadmap laid out in the blog post there are a lot of benefits to come.
The combo has taken all the pain of backend development out of the picture. Awesome to see GraphQL take off.
I'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?
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?
Watch this video; if you already use graphQL you'll be hooked on Graphcool:
Here's the code:
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: