I’ve just gone through some of the reasons that I don’t like the Relay API requirements for GraphQL, so lets have a go at designing an API that I do like.
| Home | Archives |
I’ve just gone through some of the reasons that I don’t like the Relay API requirements for GraphQL, so lets have a go at designing an API that I do like.
I’ve started playing with GraphQL again recently, having been looking into various other specifications for HTTP based APIs, and I’ve come to a conclusion. I really like GraphQL, but I don’t like Relay.
Now, don’t get me wrong, there are bits of Relay that I think are really good ideas. But there are also bits that I just think are either a waste of time, or worse actually make the API harder to use.
Having just had a very brief overview of GraphQL, the next thing that might be of interest is Relay. Relay in this sense means one of two things. Either it means the Relay Javascript Framework that is used in your frontend layer to communicate with a GraphQL Server, or - and this is what’s more interesting to myself right now - it means the set of concepts that your GraphQL Server needs to adhere to in order for it to be Relay Compatible.
You may or may not have already come across GraphQL by now. GraphQL is a new concept coming out of the software people at Facebook, and like their other ideas recently - React and Flux mainly - it looks like it could really change the way we think about our HTTP based API design.
So, what is it exactly? And why is it a big deal?