With COVID-19 still preventing in-person conferences in most parts of the world, API the Docs started the third season of their virtual events series. As usual, I’m attending these events to learn more about APIs and developer experience and gain insights into the problems and solutions from different companies in the space. Here’s my subjective summary of the latest installment.

First of all, I find it impressive that they did an event with an all-women speaker lineup, rare for technical talks. I enjoy this arrangement because it normalizes women in tech while avoiding direct comparisons between speakers that are (subconsciously) based on gender, which is a risk of token representation.

Yantian You, the first speaker of the night, shared the journey of SAS as they moved from code-first to design-first when it comes to creating APIs. Yantian also showed where the design process starts: with post-its on whiteboards, not API design tools. Those come next, of course, and SAS has built a pretty impressive internal toolchain in their continuous integration (CI) pipeline. It even includes server code generation to assist backend developers after API changes. There’s also a custom tooling package with features such as linting and contract testing that works locally and in CI.

Next in line, Anna Tsolakou from Amadeus made her case for building a developer relations (DevRel) team. She said that DevRel is a diverse team with different roles representing the customers internally and, on the other hand, the API outside of the company. According to Anna, there are three rough areas of activities. The first is developer experience, which includes SDKs and documentation. What I found impressive is the massive impact of SDKs on developer productivity, even for senior developers. However, I’m wondering how reproducible these tests are for different API designs and tech stacks. For documentation, Anna quoted that they got 300% more visits to their blog after increasing the ratio of educational content (now at 80%) over promotional content. In combination with video content and open source sample apps, it is totally in line with my take on the relevance of developer content. The second area is community-building. Events like hackathons are excellent for feedback. Amadeus uses Discord as an online forum, and engaging with OSS communities and collecting feedback outside standard channels are essential activities. That is the third critical area. The DevRel team collects feedback through various channels and aggregates it for internal use.

The last speaker of the day, Mihaela Ghidersa, gave a critical perspective on the backend-for-frontend (BFF) design pattern and suggested GraphQL as an alternative. She spoke about the changing responsibilities and shifting complexities of backend and frontend, which may lead to a “war” between developers in each area who blame the others for problems. Those usually start when the frontend needs additional data and developers need to negotiate the balance between fat payloads and chattiness. The BFF design pattern allows frontend developers to build a custom backend as middleware in front of the backend API. A BFF is typically more complex than an API gateway, but the key differentiator is ownership by a single client team. With GraphQL, there is just one backend API. Frontend developers can formulate queries to get the data that they need for their clients. It’s no silver bullet, though, and developers should take a full-stack perspective and choose which architecture works best for them while having empathy for different teams and perspectives.

The following virtual API the Docs event takes place on the 5th May, and tickets are available for free.