That’s useful for the schema documentation, but not required. Notice the use of Description peppered in there. First we pull the user ID from the args, then we use our own code to get the user model from the DB and return it. Now for the hard part - Resolve: connecting the schema queries to your data store. In this case, just 1, which is the id of the user. Next we’ll look at Args that is to say the fields that this query can receive from the client. Let’s break this down starting with Type: There’s a lot of boilerplate there to ultimately say that a user response will have and id, name, and email and for each of those fields we define the type of data (string, int, etc.) Even if you’ve never used graphql, this query will look familiar: With graphql, the client can use a familiar looking syntax to describe that entire query in 1 request and receive all the data back in the response. But at this point it’s clear that REST is broken (at least for the example given). One solution is to create a specific endpoint for the view that this request comes from. Which endpoints do we need to call for this? What if the user likes thousands of songs, do we call the API for each song to get the artist? What if the stats are not included on the artist? Do we make more calls, or do we modify the artist response at a performance expense? Pagination might help, but it certainly wont solve the issue. To gather the data needed for a mobile view called “Favorite Songs” we need: the user profile, the songs the user likes, the artist for each song, and some stats for the artist. With REST we’d define around 12 endpoints to create, update, etc. Not to mention that for mobile clients, it’s important to maximize the power of each request, since you never know when your users’ train is going to enter that tunnel. This tried and true method works, but it falls short when needs exceed the standard CRUD (create, read, update, delete) routine. I’ve been using REST and RESTful principles to develop mobile clients and their APIs for almost a decade. It’s auto-documenting, it enables clients to query only the data they need in a generic way, and it has a consistent predictable JSON response. When I first heard about it, I thought graphql was too good to be true. This is a post about building a graphql API in Go (#golang)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |