Runscope API Monitoring    Learn More →

This Fortnight in APIs, Release XI

By Ashley Waxman on .

This post is the eleventh in a series that collects news stories, helpful tools and useful blog posts from the previous two weeks and is curated lovingly by the Runscope Developer Relations team. The topics span APIs, microservices, developer tools, best practices, funny observations and more.

For when you’re finally able to commit this Valentine’s Day weekend:

If you operate a CI/CD process, you’re likely making multiple commits a day. But how much thought do you put into your commit message? In the article The Art of the Commit, David Demaree explains what goes into a good commit message, and how taking a little extra time to craft a good one that reads like a headline can save you headaches in the long run.

For when it’s February and you still haven’t started on your New Year’s resolutions:

For a “micro” service, it can be an awfully big undertaking to make the move. Fortunately, Matt Ryan’s blog post, Microservices—When to Start, explains how transitioning from a monolith to microservices architecture actually has a few advantages over starting microservices from scratch. If you’re scratching your head over how to get started when you’re sitting on a monolith, this post is for you.

For when a monolith is worth a thousand microservices:

Once you’re ready to start migrating from a monolith to microservices architecture, planning for scale is a critical component, since microservices allow rapid scale. In this article, Vivek Juneja provides diagrams and walk-throughs of architectural patterns and 3 dimensions of scalability, including testing, monitoring and deployment.

For when real beauty is on the outside:

With most technology, the focus tends to be on backend systems and development. In a refreshing turn, this InfoQ article looks at the needs and implications for UI design in microservices architecture. The summary of Stefan Tilkov’s microXchange talk, “Wait what? Our microservices have actual human users?” debunks several assumptions, like “backend for front-end” patterns and that channels matter. He argues that we need to include UI planning as a key part of building out microservices in any organization.    

For when there’s more to testing than meets-the-(C)I:

Testing and monitoring are often discussed in different camps, but they’re more related and intertwined than you think. Our latest blog post explains how incorporating API testing into your development process enables easier monitoring by running all the tests you built (during development) in production. We explore 3 Benefits to Including API Testing in Your Development Process (plus the chance to get a free copy of Phil Sturgeon’s book, Build APIs You Won’t Hate!)

For when you need to teach an old dog new tricks:

Refreshing legacy code and systems will make even the most accomplished developer a little nervous. Fortunately, GitHub recently released Scientist 1.0, an open source Ruby-based tool to mitigate those fears. In this article in The New Stack, TC Currie explains how Scientist works and how you can use it to bring large amounts of old code into new formats confidently.

For when you remember that you need people to build technology: 

It's easy to look at technology improvements or infrastructure change as individual components, but those changes are part of a larger shift that requires an entire team (and organization's) buy-in. Ron Miller explains how "every company is a software company" in Digital Transformation Requires Total Organizational Commitment. This article explores how many companies in the past several years have attempted digital transformation with a "labs" arm of the business, but moving progressive ideas from labs to the greater org is still a challenge requiring more than just engineers to be on board.

Notice something we missed? Put your favorite stories of the past fortnight in the comments below, or email us your feedback!

Categories: api ecosystem, this fortnight in apis, apis, community

Everything is going to be 200 OK®