Takeaways from the Nordic APIs Summit
I’ve finally gathered my thoughts from attending my first Nordic APIs Summit in Stockholm. Primarily, this conference appealed to me because I wanted to know more about GraphQL and OpenID Connect. There was a smattering of the usual topics such as documentation, microservices and API strategy.
This years theme was learning to ’Scale Your API Platform’. The talks were primarily split between Technical and Business tracks. Within each they were broken into either Platforms, Strategy or Design.
OAuth / OpenID Connect
The conference opened with a talk on OAuth / OpenID Connect, which is not a surprise given the main sponsor is Curity. I’m not new to OAuth but I am new to OpenID Connect so this suited my interests. Travis Spencer kicked off early on Monday with a talk entitled API Security Soup. There are over 50+ standards (he knows, he read them all) when it comes to securing APIs and Travis provided us with a good introduction on the foundational blocks in the new security stacks.
One takeaway from me is I need to get reading up on identity. The topic was mentioned throughout the conference and in coffee discussions I was having. The other takeaway is to think about the lifecycle of tokens and how changes in these may impact evolvability. I’ve found this blog post on this topic to get me going.
GraphQL was the hipster of the conference. There were 4 talks scheduled that included the word ‘GraphQL’ in the title. I believe one talk didn’t happen due to an unfortunate illness. Tomer Elmalem from Yelp gave a very insightful talk about the realities of implementing GraphQL.
Data Loading Inefficiencies
The N+1 problem is when a request to load one item turns into N+1 requests since the item has N associated items. GraphQL works by batching up server-side calls and then dispatching them in a single request to a microservice or database. If your current APIs doesn’t support batch then this is an investment that you need to consider to solve inefficiencies in data loading.
Error Handing Challenges
One nice benefit of GraphQL is that requests can partially succeed which means that a client can get a partial response even in the event of an error. Take a look at the following example where not all funding information could be retrieved for an organisation. The response from the GraphQL server is a HTTP 200 but how do you indicate that a HTTP 404 occurred?
"alternateName": "Oxford University",
"preferredName": "Queen of APIs",
"error": "Not all funds could be retrieved",
This means that you can no longer depend on HTTP status codes therefore you need to transfer meaning in other ways. This makes error handling challenging.
Securing the API
Chris Woods talk of GraphQL: A Vision for Success in the Enterprise reminded us that just because you have a GraphQL server doesn’t mean its a free for all. Chris highlighted the need to control who is accessing the graph. One way to avoid ill behaved clients is to find your high value data, pre-compile the queries and make them available via a graph.
Yelp had some pro tips for limiting the query size of clients. They suggested limiting recursion or limiting the number of fields that can be retrieved.
I’m skeptical when it comes to jumping on the trendy bandwagon but I am willing to pivot on technology choices if its the right tool (or weapon *you had to be there*) for the job.
Shelby Switzer of Healthify talked about her experiences with large enterprises in the health sector where the mindset is typically focused on custom integrations rather than on APIs. Initiating change in order to accomplish your objectives can be made easier if you use open standards as:
- they are documented and come with guides
- they are a neutral contract between both parties
- you can lend on their authority
Sound advice for any organisation trying to pivot teams towards an API first design approach.
- API Description Versioning — something I haven’t seen before in API guidelines is specifying the use of semantic versioning for OpenAPI specifications.
- Complete API Development Guide — appended to the end of this document is a very nice A-Z guide of the API development guide. I may well take this idea back to my own organisation. I do like a checklist.
I LOVE STOCKHOLM. I really fell in love with the city. It has excellent transport links and everybody I came into contact with was super friendly. Stockholm also has an excellent choice of non-alcoholic beers available almost everywhere I went. No dusty bottles of Becks Blue to be seen.
The venue was a standard business hotel a little outside of central Stockholm. I was put off attending the pre-event drinks in Curity’s office because it seemed to an out-of-towner to be somewhat of a distance from the hotel. However, I do believe they still had a good number of people attend.
The first day for me felt a little choppy. It was difficult to move between talks in the tracks due to having to take an elevator (floors 4–11 if I remember rightly). Instead I made use of the coffee moments to catch up with acquaintances and discuss some other aspects of APIs.
On the upside, we had a sit down dinner as opposed to standing around trying to find a small table to perch and eat. The pork on the second day was very nice indeed and I may have had 2 helpings of pie and cream on both days.
I really enjoyed Nordic APIs and I think they will go from strength to strength. I definitely came back to London with some new knowledge. Achievement unlocked!