If you’re an API design reviewer and, like the Who, you got a feeling inside that you can’t explain during an API design review, maybe you’re falling in love with the API designer… or more probably: you’re on the verge of giving an opinion. And that is a problem. What is the role of an API design reviewer? Distort API designs to their liking or objectively analyze them based on facts?

Fifth and last post about my first ever (recorded) live coding session given at the Manning API Conference. Thanks to all the work done, I had a good setup, great visual style, titles over VS Code, speaker’s notes and was able to code at light speed. But I was hesitant and not fast enough when presenting, I needed to train myself and fine tune, optimize or remove content to make things smooth and keep in given time frame. And once again VS Code went to the rescue.

This is the fourth post about my first ever (recorded) live coding session given at the Manning API conference. In this series second post, I listed some problems I encountered and started to solve them in previous post. But there are other problems to solve, one of them was that I was not coding and using VS Code fast enough. In this post, I’ll show you how I solved that using a few VS Code tricks, the most important one being: the absolutely rad custom code snippet feature.

Third post about my first ever (recorded) live coding session given at the Manning API conference. In previous post, I encountered various problems. Two of them were related to not delivering the session like one of my regular slide deck presentation. I wanted to add titles and have speaker’s notes. In this post, I’ll show you how I solved those two problems with OBS, VS Code and a little bit of magic.

Second post about my first ever (recorded) live coding session. So, here I was in my previous post: ready to record myself coding and talking without any slides… But I didn’t told the whole story, I actually struggled a lot before actually being able to record myself coding and talking. In the beginning, I had planned to do far more stuff and differently than what people had seen. In this post, I’ll talk about how I prepared content and realized that it was not working well.

I did my first ever (recorded) live coding session at the Manning API conference. During 30 minutes I talked and coded … without any slides; that was totally new to me. While it started well, preparing and recording this session turned out to be quite complicated. At some moment, I was totally desperate and I thought I wasn’t going to make it. But I did it and learned a lot of stuff that deserves to be shared. In this first post, I’ll talk about how “it started well”: setting up OBS, mic, cam and VS Code to record myself speaking and coding.

An API gateway is a proxy that sits between API providers and their consumers. Its main role is to ensure that only authorized consumers consume some APIs. But API gateways usually come also with features such as request/response transformation and some of them even allow to code complex orchestration. Such transformation features can be very useful if used wisely. But they also can give terrible ideas with terrible consequences.

How many times people realized that an API was not so secured despite being exposed on an API gateway? Too many times. While being a must have to securely expose APIs, an API gateway will not do all the security work for you. Security in general, and API security in particular, is a matter for everyone. Let’s see what is the job of an API gateway and what you still have to do to actually securely expose APIs.

When reviewing API designs, I often encounter operations such as GET /resources?queryParameter=value where the query parameter is required. Consumers won’t be able to make that request without providing this parameter and a correct value; that’s usually a problem. Indeed, at best it will ruin developer experience and at worst it is a sign of design smell. Let’s see why.

Nobody expects the API inquisition! Literally. When creating public or private APIs, an organization must work hard on creating the best possible developer experience or DX. That requires to ensure that API designers “do their job well”: creating APIs that fulfill actual needs and are easy to understand and use. This is the aim of governance which may help creating the best APIs or may slowly killing the organization, depending on the designer experience, the other DX, it provides.