The acronym stands for Application Performance Monitoring (and also Application Performance Management, but we will only focus on the first one) and it refers to the monitoring of telemetry data to measure our system’s health, and availability, or even to troubleshoot problems while it is online. APM is a means to increase the observability aspect of our system, allowing us to know about its internal state by reading through its external output.

Fly.io is a cloud platform for hosting and deploying applications. Its simplicity, performance and affordable pricing make it a no-brainer choice for startups and works very well as a replacement for Heroku. In this post we will show how to deploy a Buffalo application to Fly.io. Initializing the Buffalo application Initializing a Buffalo application implies running the new command on the Buffalo cli. To make things simpler we will create a SQLite application

One of the coolest libraries in the Buffalo framework is Plush, a templating engine that provides ERB-like syntax for writing server side HTML. It is a very powerful templating engine that can be used to render HTML pages for Go applications. Plush makes it easy to iterate over collections, have conditional content, use partials and more. Even though Plush is built within the Buffalo ecosystem and I’ve been able to mostly use it in my buffalo apps, I’ve always wondered how it can be integrated with Go applications written with the standard library.

I recently tried to build a web application using Go and HTML templates. In doing so, I started to miss some cool features that Buffalo and plush have to avoid repeating the layout of your web pages. I thought this was a common enough problem that the Go team should have provided the tools in the standard library, and as usual, they did. That’s when I came across the block and define expressions for templates.

With the Go 1.16 release the Go team added a new way to embed files and folders into Go application binaries. This is a great feature as it facilitates a practice that is common in the community and much likely loved by many gophers: shipping a single binary with embedded assets. In my case it even makes me wonder if there is a need to use Docker to deliver our Go binaries, but that’s another topic.

On a previous post I wrote about Go’s time locations and how to put those in an alpine Docker container. This was achieved by copying the timezone data zip file from the docker builder image into the distributable image. Then using an environment variable to point Go to the location of that file.

Over the years, Android developers have been doing networking with the use of some APIs from the Android SDK and other tools which always involved a lot of work. The use of Retrofit became the standard when we are talking about consuming APIs. This means having an additional layer on top of Java and the logic of our app. With the introduction of Kotlin a few years ago and with their native support for asynchronous operations with Coroutines, developers were provided with tools easier to use.

We may have come across the need of having to create multiple records in a single operation. Now, this can be achieved through a single insert command of course, but the more records we require to persist the longer it’ll take for this entire operation to complete. Let’s set up a basic example to go over this topic. We will be creating a list of contacts in bulk using the database/sql library in Go.

In Go, a build tag is an indicator that is added to a piece of our code, to indicate when a package will be included in the building process. This gives us the possibility to compile different versions or parts of our application from Go, switch between them in a fast and organized way, and all from the same source code.By using the build tags we can work on integration tests in development teams, which allows us to test the updates of our code without the need to make modifications to the already tested sections of it.