Controllers, APIs, Entities, Validations, Business logic, Repositories and their SQL data layer. CQRS for inappropriate use-cases when feeling fancy. Web development is fun. At the beginning…

Web development

Let me tell you a story:

  1. Client sends a request to a Java/PHP/NodeJS backend API
  2. You validate the request arguments and convert them to a data-transfer object (DTO)
  3. Fancy business logic implemented in last Agile sprint gets executed
  4. The DTO gets persisted to a MySQL database
  5. Again, again and again

Sounds familiar?

Don’t worry, this is not a pessimistic article!

Actually, I like web development! At the end, I did PHP and MySQL for 7 years. I am also a creature of habits. I enjoy going to the same coffee shop every morning, using the same techniques and frameworks and I like to maintain projects. My first project, a poker social network, I maintained for 4 years and I would still work on it if I would have more time.

I have built several monoliths. Even over-engineered one by converting it to micro-services 🤦

I tried Clean Code (max 3 arguments per function religion), Anemic Model, TDD, DDD, XXX (pun intended). Waterfall, Lean, Agile (Scrum, Kanban), NoPlan.

As an experienced drug user would say, I tried them all.

Yet, I got bored.


I wasn’t progressing anymore as a developer.
I wasn’t improving my programming skills.

Not because these techniques, methodologies are not working or are’t interesting. All of the above is good. And that’s the point. There is no silver bullet.

  1. Analyse the business requirements
  2. Choose the methodology that will solve the problem most efficiently
  3. Solve the problem
  4. Move on

“When bored, one doesn’t recklessly refactor a project to the latest fancy architecture on the company expense! She/he moves to a more complicated project.” - GophersLand -

Thinking of a next challenge in my career, I decided to explore more low-level programming and topics very new to me as a web developer such as TCP, networking, buffers, encodings, cryptography, parallelism and concurrency on it finest.

I decided to explore Golang and the over-the-roof hyped Blockchain.


Given the fact I recently launched an online school dedicated to Go and blockchain knowledge GophersLand, is safe to say… I really like it! Why? Not because Go is that amazing, even though it totally is, I like it because it helped me grow as a developer.

Working on decentralized Go projects helped me to learn about:

  • Makefiles (damn bash scripts)
  • Compilers
  • Binaries, cross-OS painful compilation (amd64, arm64, windows, OSX…)
  • TCP and networking (proxies, ports management, firewalls…)
  • Buffers, streams, bytes
  • Encodings
  • Cryptography (symmetric ciphers, AES, SHA, RSA…)
  • Functional programming
  • Pointers and Panics (not that I didn’t know how to panic before…)
  • Memory management and resource handling in long running processes
  • Integration tests


Blockchain is actually very fascinating and complicated. Aside the gazillion different implementations, not having a centralized MySQL database forces new software architecture perspective. Built in immutability also doesn’t contribute to the benevolence of bugs. Tests, tests, tests.

I will summarise my experience with the following user story:

As a program, I want to know if a user 0xC966aa57308AcBfEb3726B661BC20c258ceA5D38 has completed a transaction.

If 7/10 blockchain nodes agree he did, I will act upon this consensus.

Ah, life was definitely simpler when I was able to do:

SELECT ... WHERE user_id = "0xC966aa57308AcBfEb3726B661BC20c258ceA5D38"


Call to action

Rumours say, I should skillfully include a CTA at the bottom of the page but I hate luring people so here is the straight truth.

I am going to write a lot about the knowledge acquired by reverse engineering several popular, highly successful Go projects such as go-ethereum, buffalo, go-ipfs and others.

Join me on the path and explore the Go and blockchain world by subscribing to the newsletter below!

Thank you,
Your Gopher Lukáš