Intro
This article is about my ongoing journey of learning microservices along with Golang. This is the first of the series of articles I'll try writing to document my journey.
The Journey Begins
Recently I was working on a chat-application backend rewrite in Go. I'd already made that app using NextJS previous year as my personal project. After that, I'd tried Go and fallen in love with it.
I started to build small programs, started reading about Go through videos, articles. I also got a book for learning more about go itself called Learning Go. Going through the book was a great decision, I started to understand the fundamentals of the language.
Very soon, I leaped into the task with very little knowledge about structuring and scaffolding the project. Very soon I went into making bad design choices and ended up with bad code.
This is a necessary step I feel. You learn more from the mistakes. So, for the next try, I tried exploring about the common project structure that's used in Go. I quickly found out about a standard structure that I found common in many open-source projects that I saw. I followed the principles and got into building the second version of the app. This time the things went smoother. The structure made me write better code and I got much further.
The mistake that I made was that even though I was trying to follow the structure, my logic was interlinked with the other parts of code(eg: Database interaction layer was also having app logic). This intertwined code caused me to accept that I need to follow the guidelines that I'd read previously.
I had also tried using a repository called go-blueprint by Melkey, a well-known creator and streamer on Youtube and Twitch.
I tried using the echo framework and a postgres db. It was a bit new for me to understand the default structure that I'd gotten from the go-blueprint. There were concepts like context, services, etc which I was not really comfortable with. I really didn't need to know these when starting building something, but I was just curious to learn. The blueprint structure to me was seeming to be taking care of the microservice architecture also. I figured this would be because Go is extensively used with microservices. This was one thing that I'd not been very comfortable with. So as always, I just jumped into the fire.
This was the point that I searched for some resources for Go and found a book called Microservices with Go.
Learning the basic structure
I'm finding the book a good one to code along. By this article I've read and coded along and made my first app with microservices.
The book started with explaining about the directory structure and uses of them. I was already having knowledge about them from my previous unsuccessful attempts.
Then we started making a simple movie app. The application was simple, there would be functionality to get information about any movie. Also we would be able to rate the movie itself.
The book focused on differentiating and separating the responsibilities first.
- Storing the movie info(metadata) would be a onetime thing. We'd generally not be modifying the data once the movie details were entered.
- Storing the ratings would be different as there would be more ratings coming in overtime and there would be a need for aggregation for the ratings.
This separation of ways that we're using and storing the data is important to consider when thinking about services.
Another thing that the book did was to focus on extensibility. Instead of storing just the movie ratings, we could store multiple types of ratings(there might be a need of actor ratings in the near future). And to implement it was just adding a rating type field while storing the ratings. Such tradeoffs are considered beneficial as they allow us to be open to future requirement changes with minor changes without going overboard.
So we considered the final structure as the following:
The metadata and rating service could be independent and could maintain different storage solutions. The movie service could just be using the metadata, rating services to get the results for any movie.
The book then dives into a code along, one service and one file at a time. While creating each file, it tells the idiomatic ways of doing things. It also leaves room for upgrading our service which we'll do in further parts(eg: currently we're using http for communicating between the services, we'll also look at integrating RPCs further ahead.)
The final structure for the repository can be found here
The chapter ends with a basic working microservice application.
Currently all the services are using ports of a single machine. They will not work if they're run on seperate machines. We'll solve the problem in the upcoming parts of the series.
It was fun building my first microservice app. Will post the next part asap as I'm done learning it.
See you there!!!
Byee
Top comments (2)
Keep following
good