It’s considered a best practice to build your application in an immutable way. No matter the environment you are running your app in, you are running the same artifact. It ensures consistency over your different environments and test stages. You then inject an environment-specific configuration to make sure the app has the correct settings based on the environment like an API endpoint that will be different between production and development.

In my previous post, I was loading the fixtures data on every request. While this allow to always use the most up to date data, this is has no value in our context as the data does not change. How can we make sure we always reuse the same fixtures data for all requests? Let’s go over an implementation of the singleton pattern in Golang. First, let modify our action to only use the data to generate our users.

Based on the Previous post, I am now using SQLite to store my fixtures data for the attributes. While generating a simple User entity with a Firstname and a Lastname is fast (<5ms), creating a million records is taking forever - approximately one minute - and killing my IOPS. A quick ab test on 100 entities show that I’m saturating my laptop resources at around 8 requests per second. That’s good but it can definitely be better!

This second day is a quick one. After reviewing the different options to bootstrap an API in Golang, I’ve decided to go with Buffalo as a framework. While you can definitely get a project like randomdata.dev running out of the standard libs, I needed some guidance on file organization and best practices around go. Buffalo also includes the following useful features: Dev mode ORM with pop/soda Middlewares and Actions As I wanted to be able to have the data layer (base attributes values used to fake an entity), available everywhere and fast, I’ve decided to setup a test Docker CockroachDB cluster.

Time to start reporting on the #100DaysOfCode initiative. Even if I can’t do these 100 days in a row, I’ll try to stay on track as much as possible. The project In order to make things a little more realistic, it is always better to have a practical use-case. The goal of the next 100 days will be to have a fully working release of a tool called randomdata.dev.