1# My Journey From CRUD Developer to Building a Production-Oriented Go Backend

CRUD Naive

When I could create, read, update, and delete, I felt I was ready to create a production application and at that time I was naive, I didn't even know how SQL could operate a database,How databases work such as searching, indexing, and others.

Framework Native

Once I felt I could do CRUD, I immediately used a framework. Use the next.js framework without knowing how the framework works, and feel like magic, from how it can become an https server, how the role of SSR and CSR is used,Using an ORM to communicate to the database, everything felt instant, but I didn't realize I was building a time bomb.

How can I make a bomb that can explode at any time?

Problems increase over time due to not knowing what to do, starting from not knowing how the database works to being hit by the many abstractions provided by the framework.

How do I solve this problem For the application I built?

Trying again from the beginning is the most ridiculous thing after the application is successfully created.

The first step to reducing the number of bombs in the codebase is to understand the purpose of the abstractions provided by the framework used by the application.

Then after knowing what is provided by the framework abstraction, we can immediately sort out the trade-off weights. After that, we can separate which domain belongs to the application and which belongs to the framework so that the rules/feature domains are clear, and this is where the clean architecture comes in.

Layered Architecture

Here I started to learn to organize code and separate application and framework code and not only that, here I learned that applications layers.

• Repository Layer : A place for communication to external such as DB, third parties, and blob storage
• Service Layer : The place where the flow is managed and the repository is used.
• Present Layer : A place to receive requests and send CRUD responses

That's where I started to be interested in how application architecture works, and how an application works, and the problem of not knowing started to decrease because I started to be interested in how things work.

Turning point

From not knowing how things work to being curious about how things work, from how databases use B-trees for searching, to how indexing has trade-offs, How transactions keep data consistent.

This beginning made me start to dive into becoming a reliable engineer.

How do I learn how something works?

Many programming languages are high level and hide the abstractions of how they work, I use Golang because it is a bit low level but still simple, Golang still shows how a connection is reciprocated, and teaches some backend material such as workers, buffers, pointer, and transaction app level

There's a lot I never knew, but I'm getting more and more interested.

What I achieved?

After diving into the backend I started to understand how something worked:

• Connection Pool
• Queue
• SSE
• Worker
• Domain Bounderies
• Unit Of Work
• Testing(Unit Test, Integration Test)
• Concurent
• Error Observable
• DDD (Domain Driven Design)
• App Register(Transport,Handler,Usecase,Repository)

How do I learn and solve the problems I encounter?, see Series "My Journey From CRUD Developer to Building a Production-Oriented Go Backend"