In my last post, I shared how much value the ELK stack could bring for your application in terms of the monitoring capabilities it gives you.
In this post, I will walk you through how to integrate your Go application with ELK, what are the different parts of ELK, how they work and how to create a basic configuration for them.
Let’s jump straight in, shall we?
In many companies nowadays, microservices is the de facto way of handling service architecture.
Some do it out of necessity as their application has reached a scale where the monolith is a bottleneck. Others, simply like being onboard the hype train.
Whatever the scenario, the decision is often backed by the classical case for adopting microservices, which every junior dev studies extensively before their system design interview.
What gets often neglected, however, is the problems which come with such an approach.
Each of these problems usually demands a sophisticated solution, which raises system complexity.
One such problem is how to reuse the shared infrastructure components in your microservices. Each of your services will probably have a distinct business logic, but it will also come with a big baggage of infrastructure code.
These components usually don’t change too much between your services – healthchecks, monitoring configs, logging, standard service configurations, etc.
Fortunately, there is a very elegant solution for this problem for your Go services, which utilises the Fx Framework. It helps you by automatically managing your dependencies, but it can do much more than that as I’ll show you in the upcoming sections.
In this article, I will show you how to effectively extract your components into reusable & independent modules which can easily be shared across your Go services.
When you initially start a Go project, your main function typically has a bunch of wiring code – initialising your routes, plugging in middlewares, initialising your template engines, loggers, etc.
This is one of the great things about Go – you don’t have any magic happening behind the scenes. The code is all there and you can read it and debug it.
But as your software grows, you start feeling the growing pains – your main function starts becoming more and more convoluted. You start having all sorts of small bits and pieces plugged in here and there – healthchecks, database setup code, metrics, tracers, external API connections, etc etc.
And what if your application grows into a microservice architecture? What do you do when you have five different microservices demanding the same bunch of setup code, specific to your environment?
In this article, I will introduce you to Fx. It’s a Go framework which solves both problems outlined above using dependency injection.
Let’s jump in.
All the code from this article is available in this repo.
So you want to learn Golang?
Great! Perhaps I could help you. When I learnt I’d be joining Uber, I had some time to prepare for the tech stack ahead. One of the key things I had to get onboarded to quickly was coding in Golang.
So I started searching for good courses around the web, which could help with getting me caught up with the language and its paradigms. Some were great, others were pretty bad. And the bad part is, it isn’t obvious at first glance.
Actually, some of the most promoted courses on Golang are some of the most useless ones. So learning Go can be quite frustrating due to the lack of good courses out there.
In this article, I will share what good, bad and ugly courses I’ve encountered in the bumpy ride of learning Go.