The RESTful API has a funny place in the software development world: it’s widely regarded as the best general-purpose pattern for building web application APIs, and yet it’s also nebulous enough of a concept to cause endless disagreements within teams over exactly how to implement one.
Do I make my endpoint /company/123/ or /companies/123/? How about /companies/123/locations/ vs /locations/?company=123 ? How do I handle versioning the API? Why shouldn’t I send a POST request to trigger an action on the server? If a backend task can take many seconds to process, how do I represent that in the API?
In my last post I took a closer look at how the Apollo iOS GraphQL client executes queries and what the resulting JSON looks like. In this post I’m going to focus on how the JSON is parsed and converted to the native Swift types generated by the apollo-codegen tool and also look at how the Apollo iOS client caches results. (more…)
In my last post I took a look at using the Apollo iOS GraphQL client framework to access a GraphQL backend running on the Graphcool GraphQL mBaaS. Shortly afterwards Brandur Leach, an API engineer at Stripe posted "Is GraphQL the Next Frontier for Web APIs?". In his post Brandur gives a good overview of the current API development space, compares GraphQL to other technologies, and ultimately puts his support behind GraphQL. The follow-on discussion on Hacker News is a bit mixed, with some comments in support of GraphQL along with a few dismissing it. Some advocate support for both REST-like and GraphQL APIs, given that with a sensibly designed backend, support for both is possible with too much additional work. Stripe has a popular REST API that is used by a lot of developers, given Brandur’s opinions, it will be interesting to see if they take this hybrid approach and start offering a GraphQL interface as well.
Regardless of whether GraphQL will gain more traction compared to other approaches or not, I wanted to dive a bit deeper into the client side of things and get a better understanding of how the Apollo iOS framework and apollo-codegen tool work. (more…)
While researching mobile backend as a service (mBaaS) offerings for a client project, I came across Graphcool which provides a GraphQL backend for mobile or web apps. I hadn’t worked with GraphQL before, but it looked interesting and wanted to see if we could put it to use in the mobile or web apps we build. To get a better feel for the tech and tools involved, I decided to update the ALAirports sample project that I’ve used in a fewblogposts to use Graphcool as a backend for the airport data. (more…)
Long ago, we briefly brushed upon the topic of what has made jQuery such a valuable part of the web developer’s toolset for such a long time – namely, a cleaner interface for interacting with the DOM, and the $.ajax abstraction over XMLHttpRequest.
These days, I would go a step farther and discuss how it has positively influenced browser APIs. jQuery offered a way to find elements using their css selectors, and this eventually gave us document.querySelector and document.querySelectorAll. More recently, browser developers have taken another page from jQuery’s playbook and introduced a new, Promise-based API for making asynchronous requests, and so much more – Fetch.