Probably like most of you, my dear readers, I have too many browser windows open, with tons of tabs for each window. But there are always apps I come back to very often, like my email (professional & personal), my calendar, my chat app, or even social media sites like Mastodon or Twitter. You can switch from window to window with CTRL/CMD-Tab, but you also have to move between tabs potentially. But for the most common webapps or websites I’m using, I wanted to have a dedicated desktop application.

We all know about HTML 5, right? Well, I knew about some of the new semantic tags, like header / nav / main / article / aside / footer, but I’m still falling down to using tons of divs and spans instead. So as I want to refresh that blog at some point, it was time I revise those semantic tags. Let’s take the little time we have during confinement to learn something!

Next in my series of videos while doing sports at home, I watched this video from my colleague Tom Greenaway! It’s about modern web game development, and was recorded last year at Google I/O.

There are big gaming platforms, like Sony’s PlayStation, Microsoft’s XBox, Nintendo Switch, as well as plenty of mobile games on Android and iOS. But the Web itself, within your browser, is also a great platform for developing and publishing games! There’s all that’s needed for good games!

You’ve certainly interacted with webhooks at some point: with a Github commit webhook, for Slack or Dialogflow chatbots, for being notified of Stripe payments, or when you receive an SMS via Twilio. The concept is fairly well known, but there are some roadblocks along the way, whether you implement a webhook handler (the URL being called) or a webhook backend (the service notifying URLs). It’s not necessarily as trivial as it may first seem. As I’ve been interested in Web APIs for a long time, I decided to look into this topic a bit more, by working on a new talk.

ServerlessConf Paris is in full swing this week, and I had the chance yesterday to participate in a workshop with my colleague Frank, to cover building apps for voice, chat, web and mobile, using Google’s serverless solutions. In particular, for voice & chat, I spoke about Dialogflow and Google Assistant / Actions on Google, using Cloud Functions for my business logic, while in the afternoon we covered Firebase un more depth.

If you want to have a quick look at the deck, here are the slides that I presented:

InfoQ recently released a video from the APIDays conference that took place in Paris last year. I talked about scaling an Open API based web API using Cloud Endpoints, on the Google Cloud platform.

I spoke about the topic a few times, as web APIs is a topic I enjoy, at Nordic APIs, at APIDays, or Devoxx. But it’s great to see the video online. So let me share the slide deck along with the video:

The most common API definition languages we spot in the wild are Swagger / OpenAPI Spec, RAML and API Blueprint. All three let you define your endpoints, your resources, your query or path parameters, your headers, status codes, security schemes, and more.

In a nutshell, these definition languages define the structure of your API, and allow you to describe many elements. As standards in the API industry evolve, however, their purpose and design are under continuous scrutiny. Specifically, the extensibility of API specifications with additional elements and feature sets comes into question.

An interesting trend is emerging in the world of Web APIs, with various engineers and companies advocating for dedicated APIs for each consumer with particular needs. Imagine a world where your system needs to expose not only one API for iOS, one API for Android, one for the website, and one for the AngularJS app front end, but also APIs for various set-top boxes and exotic mobile platforms or for third-party companies that call your API. Beyond any ideal design of your API, reality strikes back with the concrete and differing concerns of varied API consumers. You might need to optimize your API accordingly.