Rakesh K

Going to say something I really mean. I want to make Coder's Gyan the number one backend engineering platform in the world. Where people actually transform their lives through us. That's the dream, and we've already started. Right now I'm deep into a series where we build a production grade backend in Golang from the ground up. I've put a lot of research and time into this, because I want it to be the best Golang backend series on the internet. Not a toy project. The real thing. This one series can genuinely change your level as an engineer. So much more is in the pipeline. Excited isn't a big enough word. Stay with me on this one.

It is gonna be the best series on the internet 💯

@DevkateYog2802 8 videos left to record. Total videos will be 22-25

@codersGyan sir anxiously waiting for this series ! when its coming please tell .

Small thing that saves you in Go: DTOs. Whenever we pass data from one layer to another, across those network boundaries, we reach for a struct to decode or encode it. And here's where many of you make one quiet mistake. You reuse the entity struct for it. I've seen it happen. Suddenly fields you never wanted public are sitting right there in the response. A DTO fixes this. It's just another struct, holding only the fields you actually want to expose. Nothing more. Working on a YouTube series on this. Dropping soon.

The whole series is landing on YouTube. Subscribe so you don't miss it: @CodersGyan" target="_blank" rel="nofollow noopener">youtube.com/@CodersGyan

In 2012 one extra field in a form embarrassed all of GitHub. A researcher named Egor Homakov hit a mass assignment bug. A form was meant to accept only a public key. But the server took every field from the request and bound it straight to the database model. So he added one field that wasn't supposed to be there. A user_id that wasn't his. And just like that his SSH key got attached to the Ruby on Rails organization. He even pushed a commit to the Rails repo to prove the point. One missing boundary. That was the whole bug. In Go the fix is almost boring. You define a struct with only the fields a user is allowed to send, and decode the JSON into that. Anything extra just gets ignored. Working on a series covering this. Dropping soon on yt.

Here's the full SOLID series if you want to go through it: youtube.com/playlist?list=…

2 years ago I made this series, and I knew going in it wouldn't get me views. I made it anyway. Because SOLID is one of the things that helped me build quality software across my whole career, and I wanted those of you doing this work to have it too. 5 principles. That's it. So here's a small reminder. The work you're proudest of isn't always the work that blows up. And that's okay. You share it because it mattered to you.

where I share the research I actually verify before trusting: codersgyan.substack.com

If you all are learning something new with AI, please fact check it. Explicitly. I was researching today and the model handed me a bunch of confident facts. Something felt off, so I pushed back. And it folded. "You're right, I made a mistake." The scary part? It didn't sound unsure even once. It lied with full confidence. Fun fact, the same model that gave me the facts is the one that took them back two messages later. Learning has gotten easier with AI, no doubt. But easy and safe are not the same thing. Don't take what it says as truth. Doubt it, check it, then keep it.

the full production Go backend series is coming here soon: @CodersGyan" target="_blank" rel="nofollow noopener">youtube.com/@CodersGyan

For the longest time I could never remember Go's log levels. Which one is more severe? What actually gets printed? So I sat down today and drew it. Debug is -4, Info is 0, Warn is 4, Error is 8. Once I saw them on a scale, it just clicked. Set your logger to Info and it prints Info and everything above it. Warn and Error included. Anything below, like Debug, stays quiet. That's the whole rule. Current level and greater. I used to dread this. Now I just remember the picture. If something looks confusing to you too, don't take any tension... This one's going into the production Go backend series I'm dropping soon.

the channel where the series drops: @CodersGyan" target="_blank" rel="nofollow noopener">youtube.com/@CodersGyan

This little db.Query call is fine in your toy project. In production it can quietly hurt you. Here's why. Plain Query has no idea your request was cancelled. The user closed the tab, the API timed out, the parent already gave up... and your query keeps running anyway. QueryContext(ctx, ...) fixes that. You pass the context down, and now the call has a way to be cancelled when it's taking too long. Same query. One extra argument. Big difference once real traffic hits. I'm doing a premium series where we use this in practice, not just in theory. Subscribe on YouTube so you don't miss it when it drops.

I build the whole thing std-lib-first here: codersgyan.com/courses/golang

For years in Go we reached for chi, gin, an external router, every single time. Then Go 1.22 changed everything. Method based routing landed right in the standard library. mux.HandleFunc("GET /listings", ...). Plus clean ways to pull params out of the url. Now? I build production backends with nothing but the std lib. No extra router. And I just love it.

the full breakdown: youtu.be/MOq5yM6cMxw?si…

Sad to see Go's defaults for the database connection pool aren't sensible. If you never set these, you're going to have a hard time. With the database, and with performance. SetMaxOpenConns. SetMaxIdleConns. SetConnMaxLifetime. Three settings most people leave untouched and then wonder why things fall over under load. I made a detailed video on this. Even if you don't write Go, the ideas are language agnostic. Have a look.

where I teach this stuff, first principles all the way: codersgyan.com/courses/backen…

A line stayed with me today. "Give a man a fish, you feed him for a day. Teach a man to fish, you feed him for a lifetime." And it made me pause. Because I think this is the thing I've been quietly reaching for all along, without ever naming it. So many tutorials hand you the fish. Copy this code. Run this command. Follow these 10 steps. And honestly, sometimes that's all you need, nothing wrong with it. But I've always felt a pull to go one step further. To explain why something works, not just that it works. I teach backend from first principles. I'm still learning myself every single day. But when I sit down to teach, I want to leave you all with understanding you can actually carry into the next problem. Teach the fishing, and the fish takes care of itself.