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 few blog posts to use Graphcool as a backend for the airport data. (more…)
One of the longstanding criticisms of Core Data is how much code it takes to setup the infamous Core Data stack in your iOS or macOS app just so that you can create some instances of entities and save them to a persistent store. The frustration has spawned a number of blog posts outlining the latest, greatest way to setup your stack. Not long after the blog posts came the open source projects aimed at reducing the amount of boilerplate you’ve got to write and helping you avoid common mistakes.
With the release of iOS 10 and macOS 10.12 in many cases you can now forget about the blog posts and third party dependencies thanks to NSPersistentContainer. This one is a no-brainer and it would have been nice if Apple had included it back in the days of iOS 3.0 when they introduced Core Data.
In iOS 9 and macOS 10.11 Apple introduced the libcompression APIs to provide a more standard way of compressing and decompressing data in your apps while offering a selection of algorithms with tradeoffs between compression efficiency, time, and energy requirements. In the past I’ve used third party APIs to compress or decompress ZIP archives given the popularity of the format, but hadn’t considered using other algorithms to either benefit from better compression or energy efficiency. Given that, I decided to take a look at the algorithms offered by libcompression and see how they compare.