For the past couple of weeks, we’ve been working on a React app from scratch. Additionally, we’ve added pipelines in Azure as an attempt to achieve MAXIMUM EFFICIENCY when it comes to deployment and integration. So there we are. It’s a lovely morning. The sun is shining, the coffee is warm, and we’re ready to drop some lines of code! 😎

Last week we built and deployed a version of our React app that had a slightly faulty CSS attribute that made the header of the app take up the whole screen. Thus our first and foremost task was to fix it so that it only takes up a small area at the top of the screen. We used the Inspection feature in Firefox Developer Edition to pinpoint the faulty CSS and determine the issue, which we managed to do. The next step was to apply that fix in our code to see what would happen. The fix worked locally by running the React app using yarn start as well as deploying a Docker image. Great, the fix is ready to be deployed using our Azure pipelines!

Cypress is a framework for testing web applications, primarily used for end-to-end testing. In an end-to-end test you test your application as a whole just as a real user would, by interacting with GUI components, without any mocked components. The goal of this post is to convince you to add a single simple cypress test to your CI/CD pipeline.

In end-to-end tests with cypress you can test a lot of aspects of your application with very little test code. Below is basically the simplest test you can write with cypress.

When working on a project that uses git, it is essential to checkout the correct branch. You don’t want to realize after a few hours of work that you worked on the wrong branch and have a few messy merges and rebases in front of you. Of course, the easiest way to show the current branch is to run git status but that requires an action from you, Instead, I recommend you to include the git branch as part of your prompt string. The prompt string is the string that marks your command line and is set by the shell variable PS1.

Workflow-timer is a Github action that measures the duration of the workflow and compares it to historical runs.

The purpose of this action is to make the developer aware of when feedbacks loops get longer. Let’s say that you are running unit tests as part of your current workflow. If merging your changes (your PR) would increase the time it takes to run the unit tests by 50%, your changes probably have unwanted side effects. It’s about creating awareness for the developer.

In a project I work with we use Azure App Service for hosting an ASP.NET application. All external configuration used by the application is stored in an Azure App Configuration store. I recently updated how the application authenticates toward the App Configuration store and think it worked out pretty well.

Prior to the change we used connection strings (i.e. a string containing endpoint, username and password) for authentication. The main drawback with this is that we have to manage the credentials ourselves. We must provide the connection string to the application in some way (e.g. set it in a CI/CD pipeline after deploying our application). If our connection string is compromised, we must regenerate it and make sure that the application is provided with the new one.

As a backend developer, there is especially one thing that I’m jealous of when it comes to frontend development. The short feedback loop, namely, the time and effort it takes to get feedback for your changes. Enable hot or live reloading while developing, and the results of your changes will be in front of you instantly, which is super nice. This is how it should be, even when you are developing the backend, infrastructure, CI/CD, or whatever. A long feedback loop can have a lot of hidden consequences, and it makes you ineffective. You and your team should spend time making sure that your feedback loop is short, and kept short.

Frontman is a very light-weight NGINX reverse proxy that is deployed using Docker. Its purpose is to act as the entry point to your server. It will redirect incoming traffic to one out of many Docker-based applications running on the same server, based on the hostname in the incoming request.

The rationale behind this is that it enables you to host as many services as you want on the same server, while still only keeping ports 80 and 443 open to the outside world.

Lately I’ve been looking for a good way of hosting some personal projects. I wanted something relatively cheap which I could use to host multiple services. A colleague of mine have for a long time used a single virtual server (more specifically, an EC2 instance in AWS) where he runs multiple services inside docker containers. To enable access to each individual service, there’s a NGINX reverse proxy that forwards traffic to services. I decided to try the same approach.

AWS recently (last year) released their new server-less database focused purely on time series data, Amazon Timestream. On their product page, AWS describes the database like:

“Amazon Timestream is a fast, scalable, and serverless time series database service for IoT and operational applications that makes it easy to store and analyze trillions of events per day up to 1,000 times faster and at as little as 1/10th the cost of relational databases.”

If you have ever run Java inside a lambda function on AWS, you will have noticed the quite significant cold start times that comes with spinning up the JVM environment. In this post, I will discuss some different tricks you can use to minimize these cold start times.

The problem with cold starts arises when there are no “warm” lambda available to handle an incoming request, which usually happens whenever an endpoint experiences a large and sudden spike in traffic. The most commonly occurring scenario when this happens is probably when an endpoint goes from no traffic at all in a while (and thus having no warm lambdas ready) to suddenly having one or more incoming requests to serve.