Let’s indulge a bit in nostalgia this weekend. I just remembered one of the websites that I used to frequent a lot around 15-20 years ago. The site was called klamm.de, and it was a German paid portal site. Or should I say, it is because if you follow the link, you might see that the site still exists. It almost looks like and has the features that were developed in its early years after the inauguration in 1999.

At the time, “getting paid for looking at ads” was the latest fad with paid email promotions, reviews, and even “surf bars” which would continuously show rotating banner ads next to your browser. All with sophisticated multi-level affiliate programs to make sure you’d invite your friends. And late teenage me was much more curious about the ideas and making some money (though I never made anything substantial) rather than being critical about advertising and the privacy-invading technology behind it as I am today.

Anyway, klamm.de was less about the earnings, but more about the community - the so-called “klammunity” and I spent quite a bit of my time on the forums of the site. Also, I assume that the site was responsible for my interest in APIs that drives my work today. How so?

At one time, klamm.de introduced “Lose” (lottery tickets) as its virtual currency, which users could bet to win prizes. At the same time, they could be traded between users. And, to drive this process, site owner Lukas Klamm (with whom I coincidentally share the first name) created an API called ExportForce. And I remember the first thing I did. I took a Javascript-based roulette game that I created as part of my high school computer science class. Then, I hooked it up to the API so that you could win “klamm Lose” playing roulette.

Of course, it was a stupid idea, because the game ran on the client and would report results to the server, so you could easily cheat. Still, it kicked off other hobby developers in the klammunity to build things around the API. And I learned a lot from it, too.

It’s interesting to see some of the “paid4” sites still around, even though earnings are minuscule, and we’re already annoyed by the advertisements we don’t get also paid for. I deleted my klamm.de account after not using it for a few years, but I’d love to log in again and take a trip back in time.

Last week, I’ve published a release of phpMAE and published an announcement post and tutorial on the CloudObjects blog. This week, as a follow-up, I have written a little about the background of the breaking changes in my open-source PHP-based sandbox for serverless/Function-as-a-Service (FaaS) development.

I finally managed to push a new release for phpMAE, my open-source PHP-based sandbox for serverless/Function-as-a-Service (FaaS) development, and (experimental) hosted service, which is a part of CloudObjects. For this release, I’ve updated the Getting Started tutorial and published it on the CloudObjects Blog just now. I’d be happy if you give it a try!

This is my first blog post in 2020, so first of all: Happy New Year! 🎇

The beginning of a new number on the calendar is a good time for some self-reflection. Among other things, I have thought about my relationship with social media again. Just as many others who spend a great deal of time on the Internet, it’s a sort of love-hate relationship. On the one hand, I enjoy the power of social media to connect people. On the other hand, it’s kind of addictive and can lead to mindless scrolling, which can be a huge timesink and makes you feel unhappy.

For Facebook, I’ve reenabled the Disable Facebook News Feed Firefox extension, which I used before but disabled at some point.

For Twitter, I’ve taken a little inspiration from Glitch CEO and blogger Anil Dash, who wrote about cleaning up his Twitter feed for the beginning of the new year. The post is from 2018, but he set off a tweet indicating he did the same thing this year.

I couldn’t convince myself to be as radical as Anil, so I used Tokimeki Unfollow instead. The application is inspired by Marie Kondo and works by showing you each of your followings with their latest tweets one by one and asks whether their latest tweets “still spark joy”. You can then choose to either unfollow or keep them. The process is also comparable to swiping through Tinder and similar apps.

I unfollowed inactive accounts, those whose tweet frequency is too high and those where I can’t remember why I started following them. I kept friends and people I’ve met in person or interacted with lately. It wasn’t a vast purge, but at least I got down from 492 to 302. My Twitter feed feels different and less overwhelming now.

For other networks, I haven’t made any changes.

Today I came across an article by Erik Dietrich called “Learning in a World Where Programming Skills Aren’t That Important”. I haven’t found the time to read Erik’s book Developer Hegemony yet, but I’ve read and enjoyed a lot of the writing on his blog.

Early in the article, he recounts his definition of an efficiencer. The difference between an efficiencer and a programmer is this: the programmer writes code while the efficiencer solves a problem.

A while ago, I wrote a post about a contract I did in which I built API-driven automation on top of Airtable, instead of continuing the custom-built CRM that the previous developer had started to create. While writing that post, I also described that I believe a developer’s job shouldn’t be writing code but solving problems. Erik’s writing partly inspired my reasoning, but at the time, I didn’t have a fancy term for it. Now, however, I believe that the project I mentioned is an excellent example for an efficiencer’s work.

I enjoy coding, and I love writing code that does something smart. I even tend to grow attached to the lines I wrote. But the value I can provide doesn’t necessarily lie in that code but in understanding requirements and solving them in the best way.

I’m happy to announce that I have launched a new profile website for my freelance consulting business. The site centers on developer content production, which I have strategically decided to focus on, although it mentions other services as well. It describes the importance of content for API providers and developer-focused companies and how I intend to help them creating and documenting sample applications for their API in eight steps.

Unlike my blog, which is in English only (some thoughts on this in my last post), the new profile website is available in two languages.

You can find the German version at lukasrosenstock.de and the English version at lukasrosenstock.de/en. Any feedback on the site is always appreciated 😊

Last night I listened to the latest @monday episode in which @macgenie interviewed @ton. It was quite inspirational; I especially liked the idea of his “Birthday Unconference”.

Something else that got me thinking was their discussion at the beginning of the episode about blogging in different languages. Ton primarily writes in English but also sometimes posts in Dutch or German. He used to dabble with separating the languages into different blogs but ultimately decided to put everything in the same feed and tag or categorize the content.

For me, I never liked this idea of having multi-lingual content on the same blog, even when it’s tagged or categorized (inconsistently, I do post in multiple languages on Facebook, though). At the same time, I probably don’t put out enough content to justify multiple websites. I used to have multiple Twitter accounts, but even that was a little cumbersome to manage.

My blog and also my tweets are mainly about the tech industry, especially the narrow API and DevRel niche. My business targets international clients, and I share a lot of external content, which mostly is in English as well. Therefore, I think it makes sense for me to focus all my writing on English language content. On top of that, as I mentioned in my recent post about motivations to blog more, I want to improve my written English. Another important aspect is that the focus on one language avoids the mental load of making the decision which language the next post should have.

On a side note: I do have one German 🇩🇪 social media presence, though, and that is my Innovators Gießen Twitter account, where I share mostly tech content with local relevance to the region where I live.

Right now, I’m sitting on a train en route to Hamburg. A friend and I have tickets for the performance by Ludovico Einaudi in the Elbphilharmonie tonight 🎹. It’s my first time in this new and iconic concert hall, so naturally, I’m excited!

I’m resuming my work next week, so if you’re trying to get in touch, please bear with me, and I will get back to you on Monday.

Recently I’ve encountered the term full-stack freelancer through an article by Tiago Forte on his Praxis blog. I had heard of full-stack developers, but I never heard that term before, so I was intrigued. Tiago defines such a person as someone who has a broad portfolio of different projects and receives multiple income streams that come through varied activities. It’s the opposite of a freelance expert who specializes in a single offering in a specific niche.

I don’t want to go in-depth at the moment regarding the entire concept, but I’d like to highlight one of his thoughts that was a proverbial lightbulb moment for me. After thinking about it, I realized it’s obvious, though I can’t remember someone explicitly stating this thought.

The idea is that certain activities are impossible to focus on as a full-time position or have greatly diminishing returns, but doing them in moderation can be extremely beneficial.

For me, paid guest posts are one such activity. I’ve done quite a few in the past. They have provided me exposure, some money, and the ability to learn a lot, which I could then apply to other gigs, such as software development projects. I mentioned this briefly in my post yesterday about the motivation to write more. However, I could never be a full-time blogger because I would soon run out of ideas and lucrative opportunities to write. It’s valuable to do this infrequently, though.

Tiago mentions other things that he does once in a while, such as coaching and consulting, which are part of his varied portfolio.

For me, this ties into the discussion between generalists and specialists and the hybrid variant, the T-shaped skills. It also adds to the idea of a gig economy as the future of work. Different projects could allow a person to focus on the middle of the T while having occasional contracts that help with the ends of the T, with every client benefitting as a result.

My blog had been on a four-month hiatus during the summer. Since the end of September, I have stepped up the frequency of posting new content. The long break was mostly due to me being unsure about the scope of the blog. At least that’s what I’m telling myself. I’m considering this blog a professional one, an extension of my freelance business, a way to showcase my work and communicate with existing and potential clients. However, there are so many things that I feel like talking about that would be outside that definition. They are still very much part of my personal and entrepreneurial journey because they shape the way I think. So I’ve decided to ponder less about boundaries and try to post more.

The only constraint is that I want to stick to mostly short- and medium-form writing and not make this blog a place for really long-winded thoughts, essays, or tutorial-style posts. Something that I can write in one to a maximum of three Pomodoro sessions. In that way, I can actually ship posts instead of just collecting ideas or working on never-finishing drafts.

Blogging is beneficial even without an audience because writing about something helps with clarifying one’s thoughts. For a non-native speaker like myself, it also helps me to hone my written English skills.

On the other hand, I believe it’s crucial to cultivate a personal brand and define what you stand for and what makes you unique. Blogging more will certainly help me do that.

There are many good examples of people who gained new professional and personal opportunities because of what they published online. Even I have won one paid contract due to a blog post that I wrote. In this specific case, it wasn’t something that I wrote on a personal blog but a guest post. Still, it underlines the importance of putting your name out there. And since you never truly own your representation on someone else’s website, it’s essential to have a place online to call your own. Thank you for coming to this place to read this!

If you want to read more about this subject, I recommend Jamie Tanna’s article “Why I Have a Website and You Should Too”.

Good API design is important! And one of the main aspects of any good design (not just for APIs) is consistency. Developers (or other users) should be able to recognize patterns and not suddenly encounter elements that go against their expectations. The typical approach to enforce consistency between multiple people working on a product or even across teams in an organization is to write down a set of rules - an API style guide.

The problem with rulebooks of any kind, though, is that people don’t like reading them or, even if they do, they cannot remember it all and so they accidentally break the rules. That can be prevented, of course, with automatic validation and linting through tools like Spectral. However, maybe the better approach is not having too many rules to begin with?!

It was the lesson learned by Holger Reinhardt, CTO of Adello. As he wrote on the company’s tech blog, based on his experience of writing an extensive style guide for his previous employer, he tried to limit himself “to the very critical and core aspects of API design”.

The resulting Adello API Styleguide is publicly available. I like how it covers everything that I would also consider essential, provides additional reading material, and references to principles like Postel’s law. However, you can still glance over it in seconds and read the entire thing in minutes. I’m sure that this guide could be a good example that other companies could build their API style guides upon.

By the way: if you think your API design needs improvement and you could use some help, I’m available for API consulting freelance work!

When I recently saw the link to a petition for a Fossil Free Facebook, I assumed it was someone requesting Facebook to switch their datacenters to energy from renewable sources. It reminded me of another petition I wrote about last year, which asked the tech industry, in general, to switch to green power. It seems, however, Facebook has already pledged to do that, which is laudable.

The Fossil Free Facebook campaign, though, goes a step further than that. They target Facebook in their position as one of the largest advertising companies in the world and ask them to reject advertising from oil and gas companies. It’s well known by now that many of the giant energy companies, while investing in renewable energy themselves, also try to influence the public opinion and downplay the risks associated with climate change, or even fund outright denial.

If you believe that companies like Facebook should take more responsibility for the ads that they host, have a look at the petition and sign it if you like.

Zoho is probably one of the most underrated companies in the tech world. They have amassed a broad portfolio of enterprise SaaS products for practically every business case out there. The tools have integrations between them, and almost all have APIs for third-party integrations. And even though they serve 50+ million users (according to their About us page), they somehow fly under the radar. That might have a lot do with the fact that they are bootstrapped without outside capital, so they have no story for tech media that loves to write about VC and funding rounds. Also, their main center of operations is in Chennai, Tamil Nadu, India, and not in a tech hub in the West.

The reason I’m writing about Zoho is that I’ve recently learned they have launched Zoho Catalyst, a serverless platform. At the time of writing, the product is in closed beta. It offers software developers BaaS (Backend-as-a-Service), FaaS (Function-as-a-Service), and even AI (artificial intelligence) APIs along with integration into the existing Zoho stack. But more important, it is, as they’ve put it nicely on the website, “powered by our life’s work”. That means that they have taken infrastructure and internal services that they have built for themselves and opened them up to the outside world.

It could be a smart move, considering that this is something Amazon has done quite successfully. They have turned a bookseller into one of the world’s most massive cloud hosting companies, all through an infamous decision by Jeff Bezos. And it’s another example of a backward vertical integration business strategy that involves moving down a layer in the “stack”. Although Zoho is much smaller, of course, they might benefit from economies of scale and their expertise. I’m looking forward to observing if and how Zoho Catalyst will succeed.

A software developer’s job is to write code. That’s the reason people hire them. I disagree. I believe a developer’s job is to solve a problem. In a world of SaaS, code libraries, APIs, and automation tools, the best way to solve the problem might be to figure out one or more existing solutions and focus on their integration, instead of reinventing the wheel.

Once, a potential client contacted me who had a specific need for marketing automation involving external APIs. Details are confidential, of course, but they don’t matter for the point I want to make. The client further mentioned he was already working on it with another developer. However, they were unhappy with the work they did and thinking of reassigning the project.

After the client shared the current state of the project with me, I realized that the developer had started implementing a specialized CRM (customer relationship management) tool from scratch. It would have taken some time to complete this CRM before even getting to the API-related work. Thus, I made a suggestion.

I proposed to scrap the whole thing, design a CRM with the required fields in Airtable, and have the client and his employees manage everything through their frontend. Managing structured data in tables is a solved problem, and Airtable is a magnificent tool. Then, I would implement a crontab-triggered service that pulls the data from Airtable via the API and then initiates the required requests on the other APIs. The API results would go back into Airtable. This way, I could focus my work on the value-add for his business, instead of writing generic frontend and data management code.

The client happily accepted, I built it, and he’s now using the system daily. Building headless (frontend-less) integrations with APIs and leveraging existing user interfaces wherever possible might not be the natural and intuitive choice. However, I am confident it can quite often be better and faster than writing your own. It can also help to keep a project with time and budget constraints.

While trying to clean out my saved content in Pocket, I came across an article by Evgeny Morozov published in the SZ (Süddeutsche Zeitung) in German with the title “Für eine radikale demokratische Transformation” (UPDATE: “The left needs to get radical on big tech – moderate solutions won’t cut it” in The Guardian seems to be the English version - thank you Sebastian Lasse!).

In the article, Morozov writes about the “techlash” as a growing feeling that a few dominant corporations have too much control over the Internet. And, as he says, there are basically three types of opposition to the status quo, which I found an interesting classification.

The first type of criticism is economism. It’s mainly focused around the idea that corporations profit off personal data and free labor from the consumers. These should be compensated, for example, through a “data dividend”.

The second type of criticism is technocracy. It identifies monopolies as the main issue and calls for antitrust regulations to break them down and establish more competition in the market.

Morozov says that both of these schools of thought are too limited because they only look at the economy. He identifies a third group who is trying to go beyond the status quo and rethink the purpose of technology in the world and look at data as more than just an economic resource. Essentially, this group is trying to envision a utopia with different rules and new players, including non-commercial ones, and more democratic control. So far, however, this group lacks unity and visibility.

I follow a few initiatives that are part of this third group, such as the IndieWeb movement or Mastodon/ActivityPub, as an alternative approach to social networks. The platform cooperatives movement and some Blockchain-based projects also belong there. And so do tiny indie makers, such as this blog’s host micro.blog. The field is incredibly diverse, but that makes it very difficult to navigate and understand. And, in my opinion, they can’t speak with one voice. The only thing that unites them is the idea that there’s something better than the status quo, but the details vary. Therefore, if we want to limit the power of the technology giants, it might be easier to implement the more straightforward suggestions from the other two groups first. Next, the initiatives in the third group can compete or cooperate on a more level playing field.

There’s also a fourth approach that I sympathize with, for obvious reasons. USV VC Albert Wenger postulates the “right to an API key”. The idea is that companies must make their data troves available in a machine-readable format. In this way, individuals can be empowered to leverage that data in a way that benefits them instead of being limited to the algorithms offered to them.

Next week it’s API the Docs time again. The API conference is coming back to Amsterdam and is sold out! I’m a regular attendee of their events and even was a speaker last year in Paris. This time I’m not speaking, but I’m looking forward to connecting with the community. I booked my train tickets and accommodation this morning and I have some time on the days before and after the conference if anyone wants to meet!

There’s one active role I’m playing for the community, though. For the second time after London last year I’m on the jury of the Dev Portal Awards. Last week I spent some time reviewing many great submissions. I also had two calls with fellow jury members Bob Watson and Anne Gentle as well as Katalin Fogas of Pronovix who’s organizing the awards. I can say that it wasn’t always easy, but we have some winners now! They will be announced at the awards gala that’s happening next week as part of API the Docs and then published online - so stay tuned for that!

I just watched the 4-minute video clip from Greta Thunberg and George Monbiot in which they call for more support for natural climate solutions to help tackle climate change.

One of those solutions is, quite obviously, planting more trees 🌳! And although we can only solve the climate crisis with public measures implemented on a global scale, individual actions are still important. Donating to reforestation projects is one of those actions. Fellow API practitioner Phil Sturgeon has beat the drum a lot lately for a site called offset.earth. The site collects donations for Eden Reforestation Projects but adds a community and gamification aspect on top of it, which I really like:

Every member grows their own virtual forest, and they get a profile URL which displays the trees as well as the impact of the carbon offsetting. The profile can also be used to display other personal goals. Have a look at my profile page at offset.earth/lukas, for example. If you want to make a one-time donation (any amount and payable in EUR, GBP or USD), you can do that on my page to help my forest grows.

Or, if you want to donate regularly (it’s GBP 4,50 a month), you can sign up through my special referral link. Then, you will get your personal offset.earth-URL with your own forest and I will get some “sparkly trees” in mine.

After some months of silence, I’m returning to my blog. And I want to talk about one of the defining problems of our times: climate change, and how to avoid disastrous global warming.

Now, I’m interested in this topic because I believe the scientists who say that we have to act now. But I’m by no means an expert. And neither was my friend Mischa Hildebrand, a physicist and radio journalist turned software developer. However, like (hopefully) you and me, he’s a person that cares about the impact of one’s life on the planet and the people around you. Therefore he has taken the time to write a great piece about climate change.

He says that as humankind, we have to limit our use of natural resources by moving away from growth and expansion. Technological progress is significant, but it won’t save us. It’s a long read but worth your time. And, like a good scientist, the author focuses on analyzing the problem with depth and structure, citing numbers and moral principles, instead of jumping to quick conclusions and solutions.

I can’t urge you enough to go and read Mischa’s article “Climate Change is Not Our Problem.We Are.” and share it on your blogs and social media channels.

I received an email from Holvi, who provide me with my business bank account. It was a notification that my account number will change. Now, that by itself would be merely annoying, since I soon have to edit this number in various places. However, the nature of that account number change and the reason they gave goes a little deeper, so let me share the background and my thoughts about it.

My business is based in Germany, and Holvi is a fintech company based in Finland (so a fintech in a double sense …). Therefore, my account number was an IBAN starting with FI, the country code for Finland, instead of DE, the country code for Germany. I never had any problems with this. On the contrary, I quite liked having the Finnish IBAN because I felt it was a statement for Europe and the Digital Single Market.

I’m a firm believer in the idea of the European Union, and I’m sure that to foster European innovation, we have to take a European perspective instead of a national one if we want to play a role in a world of superpowers like the US and China. The regulation does not yet make this easy, but I feel we’re getting there.

The Single Euro Payments Area (SEPA) makes it mandatory for banks and companies to offer cross-border financial transactions within SEPA countries under the same terms as domestic transactions. Moreover, Article 9(2) of the regulation bans so-called IBAN discrimination explicitly, which means companies must not require customers to have a bank account in their home country or any other specific place.

As Holvi explains in the FAQ about the change: “Even though the FI-IBAN should work anywhere within the EU, many of our German customers have experienced IBAN discrimination due to the FI prefix.” In other words, this change is giving up and caving in. Now, I don’t want to blame Holvi; this pragmatic decision probably makes sense for them and the affected customers. It would have been nice if this was an opt-in change, though, as I was not affected.

But anyway it’s a negative sign for fintech startups all over Europe because it shows that it’s challenging to offer a product in other countries as there are still companies who practice IBAN discrimination which is, I repeat, an illegal practice. It means that it’s startups and innovators who have to adapt to an “old economy”.

Still, I hope that this is a problem that will be solved over time and Europe will grow closer together (not only) in the financial market. Until then, I will weep a little over my beloved FI IBAN and change it to the DE IBAN.

I’ve talked and written a lot about the importance of good API design. Now, in my latest guest post for Stoplight, I have explored how to design APIs following the CRUD paradigm - created, read, update, delete. While this approach is not necessarily the right one for every API, it works for a lot of them, and those APIs can benefit from consistency throughout the API ecosystem by following best practices. Go ahead and find “CRUD API Design Recommendations From the Field” on the Stoplight blog , where I’m explaining the implementation of recommended URL structures and choosing the correct HTTP verbs.

Disclosure: This work was paid for by Stoplight.

On the past weekend, I attended the Founder Summit 2019 in Wiesbaden. Entrepreneur University, led by the 26-year old Söder twin brothers from the Frankfurt Rhein-Main region, organized this event for the fourth time and it was my first time going.

I enjoy going to meetups, conferences and networking events, but mostly I attend smaller and more tech-focused events. This one was a generic entrepreneurship event with over 5000 attendees, and it had an additional focus on personal development. Therefore, apart from people from the startup ecosystem like founders and investors, they also had a lot of motivational speakers from the coaching scene, who, in turn, drew a more diverse crowd. Those coaches and what they teach are not necessarily everybody’s cup of tea, but there’s no denying that they know how to entertain huge crowds. And talking about entertainment, well, that was probably my first conference where professional dancers, magicians, and musicians alternated with entrepreneurs on stage and every entrance was accompanied by professionally produced videos, music, and light shows.

Also, they put in a considerable effort to get big names to attend. For example, they had two of the four investors from Die Höhle der Löwen, which is Germany’s equivalent of the Shark Tank TV show. Both had interesting insights to share, I especially enjoyed Frank Thelen’s outlook into the future of technology and honest judgment of things like the blockchain, explaining its potential but not succumbing to the hype that surrounds it. Another great talk was by Iskender Direk of Microsoft on Artificial Intelligence (AI). Even though he omitted critical aspects like privacy, his (simplified) description of a day in the year 2029 with new technologies was vivid and well-presented.

To conclude, I had a great time in Wiesbaden, even though I was suffering from a minor cold over the two days, and I would probably attend this event again. Until then I’ll continue going to smaller events which might have less big names and entertainment but are, no less, products of their founder’s love.

On Saturday I attended the first SpeaKonf in Darmstadt, an unconference specifically for conference speakers and those who want to become one. I’ve given a few talks already, such as “To SDK or not do SDK?” at APItheDocs or “Specification-driven APIs vs. Technical Writers” at tcworld, but I’m always eager to learn and improve.

The unconference was a one-day event organized by the Java User Group Darmstadt and supported by cosee, who opened their offices for approximately 40 participants. After a typical BarCamp-style planning session, we filled three tracks with 15 session proposals. Here’s a quick summary of the sessions in which I participated.

The first was about using images in slides. Pictures, especially photos, can support a talk’s message on an emotional level, but they must fit and not feel forced. To be safe in terms of legal compliance, always mention your sources, ideally as a small footnote on the slides itself, and store some proof (i.e., screenshot) of the licensing agreement, in case the source disappears or changes.

The second session was the organizer’s offer to have yourself recorded and analyzed, which I gratefully accepted, though being the only brave person to do so in a group with only three people. But the feedback from the other two was helpful.

After a catered pizza lunch there was a session called “Tag Teach”. It was led by Mirjam, who was a dog trainer before she became a software developer. She explained how conditioning methods, especially positive reinforcement, applied for teaching animals could also be helpful for humans to improve their behavior, for example, their posture or way of speaking in front of an audience. We did a few practical exercises, too.

The fourth session was about self-recording your talks, either for practice or if you want to keep presentations from meetups who don’t record them, so you have reference material when submitting to CFPs.

Finally, the last session was about live coding. We talked about the advantages and risks of live coding during a presentation compared to recorded screencasts and collected some advice for optimizing an on-stage coding session, for example using automation, IDE shortcuts or storing various states of your project so you can quickly access them if necessary.

The day ended with a retrospective. There was a lot of positive feedback, but many including me thought that the diversity of attendees should be improved. Java developers and conference veterans were overrepresented whereas there was a lack of novices and people with a non-technical background and perspective.

But altogether, the trip was worth it, also because of the “hallway track” in which I got to know Ralf who runs docs-as-co.de, a website that advertises a docs-as-code workflow based on AsciiDoc. Talking to him inspired me to dive even deeper into optimizing and automating API documentation.

After explaining the difference between APIs and microservices in an article for the Stoplight API Corner, I wrote a follow-up piece talking about API design for microservices. Even though microservices APIs seem small, it’s important to design them well to build a microservices architecture that performs well. Apart from performance considerations, such as designing non-chatty interfaces, you also need to maintain loose coupling and pay attention when modeling your domain. To learn more, you can read the full post “Designing APIs for Microservices” in Stoplight’s API Corner, which they just migrated off Medium and onto their website. The new blog also has author pages, so you can find an overview of everything I’ve written for Stoplight here.

Disclosure: This work was paid for by Stoplight.

I’ve observed that sometimes people use the words “API” and “microservice” and mean the same thing, or they use the terms in other confusing ways. As the famous adage goes, “there’s only two hard problems in computer science, cache invalidation and naming things”, and it seems to be correct when it comes to terminology in the API ecosystem.

I’m exploring these terms, along with containers, in an article APIs and Microservices that now got the more click-baity editorial headline “Stop Calling your APIs Microservices” and has been published in the Stoplight API Corner on Medium. Go and check it out!

Disclosure: This work was paid for by Stoplight.

Thank you for your interest in my talk Specification-driven API with OpenAPI! I have now uploaded the slides to SlideShare.