DEV Community: Peace Melodi

I Used GoLang to Build a Restaurant Ordering Backend

Peace Melodi — Thu, 27 Aug 2026 08:46:37 +0000

I built a production ready backend for a restaurant ordering platform using Go. The system called Peace Restaurant Co. covers multirole authentication, menu management, transactional order processing, real time order lifecycle tracking, and administrative analytics, all backed by PostgreSQL.

Here is the repo if you want to look through the code: https://github.com/PeaceMelodi/GolangPeace_Restaurantco_App

I also recorded a short demo on YouTube so you can watch the system working end to end before you dive into the code.

The Architecture

The project follows a clean layered structure. Handlers parse requests and write responses. Services hold the business logic. Repositories own the database layer. Models define the contracts everything else depends on.

Each layer talks to the next through interfaces. That keeps the code decoupled and easy to test, and it means I can swap out an implementation without touching the layers around it.

Data Access Without an ORM

For data access I used SQLX with PGX. There is no ORM in this project. Every repository method is explicit. Parameterized queries prevent injection. Structs map to rows using db tags. It is just typed queries returning typed results, and it makes the SQL predictable instead of hidden behind a query builder.

Transactional Checkout

The checkout path is fully transactional. The service validates the incoming payload, fetches current prices from the foods table, computes the total, inserts the order, then writes each order item. All of that runs inside a single database transaction. If any query fails, the whole thing rolls back and nothing is left half written.

Go's error handling made this straightforward to build correctly. Every call returns an error. Every error gets checked before moving on.

Multirole JWT Authentication

Authentication is JWT based, with separate flows for admin and regular users. Tokens are signed with HMAC SHA256. Middleware extracts the token from the Authorization header, verifies the signature, and injects the user ID into the request context. Admin and user routes each run through their own middleware, so the two roles never share permissions by accident. Passwords are hashed with bcrypt before they ever touch the database.

Order Lifecycle Tracking

Orders move through defined states in real time, so both the admin side and the user side always know exactly where an order stands, from the moment it is placed to the moment it is fulfilled.

Analytics in SQL

Analytics runs entirely in SQL rather than being computed in application code. Revenue, user count, and order count are aggregated using CASE statements across weekly, monthly, yearly, and lifetime buckets. Results scan directly into typed structs, and the API returns clean JSON from there.

Shipping It

The build pipeline is minimal on purpose. A multi stage Dockerfile compiles the binary. Compose brings up the API and Postgres together with one command.

Concurrency, For Free

Go handled concurrency without any extra effort on my part. The net/http server manages a goroutine per request. No worker pools. No async overhead to configure. Just predictable performance out of the box.

Wrapping Up

The result is a backend that processes orders, enforces auth, manages data, and reports metrics, built entirely in Go with no framework and no ORM. If you want to see it in action first, watch the demo on YouTube, and if you want to dig into how any specific part works, the full source is in the repo linked above.

I Almost Quit Coding Last Year, Here's What Changed My Mind

Peace Melodi — Thu, 13 Aug 2026 23:05:28 +0000

There was a stretch last year where I seriously considered walking away from coding altogether. Not dramatically, not in one single moment, just a slow, quiet decision building up over weeks. I would open my laptop, stare at a project, and feel nothing but tired. I kept comparing myself to other developers who seemed to be moving faster, understanding more, building bigger things, and somewhere in that comparison, I started to believe I simply wasn't good enough to keep going.

I didn't tell many people how close I actually was to stopping. On the outside, I still showed up, still pushed code, still replied to messages like everything was fine. But quietly, I had already started writing the ending in my head.

What changed things wasn't a breakthrough project or a sudden burst of motivation. It was someone else's words. A message from someone who had been paying more attention to my work than I realized, telling me plainly that what I had built mattered, that they had learned something from it, that I was further along than I gave myself credit for. It wasn't a long message. It didn't need to be. Sometimes the right words land exactly when you need them, not because they say anything new, but because someone finally says out loud what you've stopped being able to tell yourself.

Here is the lesson worth taking from this. We are often the harshest, least accurate narrators of our own progress. Doubt convinces you that you are behind, that you don't belong, that everyone else has it figured out. It rarely tells the truth. Sometimes it takes someone else's voice, someone standing outside your own head, to interrupt that story and remind you it was never as true as it felt.

I'm still here, still writing, still building, because someone took a moment to say something kind at the right time. If you're in that quiet stretch right now, the one where you're questioning whether to keep going, I hope this is that moment for you. You are further along than the doubt is telling you.

I write these thoughts as Peace Melodi, a backend software engineer who cares deeply about building things that hold up under real pressure, real users, and real growth. If any of this resonated with you, I would love to connect.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

Stop Comparing Your Chapter One to Someone Else's Chapter Ten

Peace Melodi — Thu, 13 Aug 2026 22:39:45 +0000

There is a quiet kind of pain that comes from scrolling through other developers' work, seeing what they have built, how fast they seem to be moving, how confident they sound, and feeling smaller with every scroll. Nobody warns you about this part. Not the syntax, not the errors, this one.

Here is what nobody tells you early enough. You are almost never actually looking at someone's beginning. You are looking at their chapter ten, the version of them shaped by years of failed attempts, quiet frustration, and moments they never posted about. What you are comparing is not your starting point against their starting point. It is your starting point against their years.

I used to do this constantly, measuring myself against people who had been doing this far longer than I had, and quietly deciding I was behind, without ever asking behind what, or behind whom, or by what timeline that was even fair to measure by.

Here is the lesson worth sitting with. Growth is not a race with a shared starting line. Everyone begins at a different point, carrying different circumstances, different amounts of time, different amounts of support. Comparing your current chapter to someone else's later chapter will always make you feel like you are losing a race that was never actually fair to begin with.

The people you admire were once exactly where you are now, confused, slow, unsure if any of it would ever click. They just kept turning pages long after it stopped feeling exciting. That is the only real difference, not talent, not timing, just pages turned.

You are not behind. You are simply on your own page, in your own chapter, and that is exactly where you are supposed to be right now.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

The Simple Idea Behind How NestJS Handles Things Going Wrong

Peace Melodi — Wed, 12 Aug 2026 07:28:12 +0000

Every building, no matter how well built, has systems in place for when something goes wrong. A smoke detector does not prevent every fire, but it makes sure that when smoke does appear, something responds immediately, calmly, and in the right way, instead of the whole building being caught completely off guard.

NestJS is built with that same mindset. No app, no matter how carefully written, avoids every single error. Something will eventually go wrong, a piece of information missing, a step failing unexpectedly, a connection dropping at the wrong moment. What matters is not whether something goes wrong, it eventually will, but whether the app knows how to respond when it does.

This is exactly what a part of NestJS called exception filters is built to handle. Think of it as the smoke detector and response system built directly into your app. When something goes wrong somewhere inside, instead of the entire app crashing and leaving everyone confused, exception filters catch that failure the moment it happens and respond to it on purpose, calmly returning a clear, controlled message instead of collapsing into chaos.

Without something like this in place, an error happening deep inside an app can quietly bring the whole thing down, the same way a small unnoticed fire can spread if nothing is watching for it. With exception filters in place, that same error gets caught early, contained, and handled with intention, so the rest of the app keeps standing steady around it.

Here is the lesson worth taking from this, even outside of software. The goal was never to build something that never fails. That is not realistic for anything, software included. The real goal is building something that knows how to respond when failure happens, calmly and on purpose, instead of being caught completely off guard.

That is the quiet confidence NestJS builds into every project from the start, not the absence of things going wrong, but a system already prepared for the moment they do.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

The Quiet Confidence NestJS Gave Me as a Developer

Peace Melodi — Wed, 12 Aug 2026 07:06:15 +0000

There is a specific kind of fear that comes early in a developer's career, the fear that everything you build is one wrong move away from falling apart. I remember that fear well. Shipping something and quietly hoping nothing broke, rather than actually knowing it wouldn't.

NestJS changed that for me slowly, without me noticing it happening at first. It was realizing I could add a new feature to a project without dreading what it might quietly break somewhere else.

Here is what was actually responsible for that shift. NestJS is built around something called dependency injection. Imagine moving into a fully furnished apartment instead of an empty one. You do not need to build your own furniture from scratch just to live there, everything you need is already prepared and handed to you the moment you walk in. Dependency injection works the same way inside NestJS. Instead of each part of your app having to build everything it needs on its own, NestJS hands each part exactly what it needs from the outside, already prepared. Nothing has to quietly depend on how another piece was built internally.

That single design choice is also why testing in NestJS feels far less intimidating. Because each piece already expects to receive what it needs from the outside, you can hand it a controlled, fake version of that thing during testing and check exactly how it behaves, without needing to set up your entire app just to test one small part. NestJS developers often point to this as one of the biggest reasons they trust the framework, not because testing becomes easy, but because it becomes possible without a fight.

Here is the lesson worth taking from this, even outside of software. Real confidence rarely comes from talent alone. It comes from working inside a system built so its pieces stay separate enough that no single mistake can quietly take everything else down with it.

Today, I don't hold my breath when I ship something anymore. The fear is gone, replaced by something steadier, built on a framework designed from its foundation to keep me from having to trust blindly.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

You Can Understand How NestJS Keeps Things Clean, Here Is How

Peace Melodi — Wed, 12 Aug 2026 06:46:26 +0000

Have you ever cooked with an ingredient without checking it first, only to realize halfway through that something was off? Most careful cooks do not just grab an ingredient and toss it straight into the pot. They check it first, is it fresh, is it the right amount, is it actually what the recipe called for. That small habit of checking before using is exactly what keeps a kitchen safe and a meal turning out right.

NestJS works the same way with the information it receives. Before your app actually uses anything it is given, whether that is a name typed into a form, an amount entered for a payment, or details submitted through a signup page, NestJS has a way of checking that information first, making sure it is the right shape, the right type, and actually safe to use, before it ever reaches the part of the app doing the real work.

Think of it like a careful cook checking every ingredient before it goes into the pot. If something looks off, too little, the wrong type, missing entirely, it gets caught right there, before it can ruin anything further down the line. Only once everything checks out does it get allowed through to actually be used.

This process, this careful checking step happening quietly before anything is trusted, is called the validation pipe. That is the name behind everything we just walked through, the part of NestJS standing at the door, inspecting what comes in before it is ever allowed to move further.

Here is the lesson worth taking from this, even outside of code. The strongest systems are rarely the ones that never receive anything wrong. They are the ones that check carefully before trusting anything completely. A kitchen that inspects its ingredients rarely gets ruined by one bad item, and an app that checks its information rarely gets broken by one bad request.

You do not need to memorize any technical terms today. You only need to know that NestJS has a built in habit of checking things before trusting them, quietly protecting your app the same way a careful cook protects a meal, one ingredient at a time.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

[Boost]

Peace Melodi — Tue, 11 Aug 2026 11:03:39 +0000

Peace Melodi

Jul 16

If a bank hired me to fix their webhook handling, here is how NestJS would help me start

#nestjs #fintech #backend #typescript

4 min read

What Really Happens Between a Request and a Response in NestJS

Peace Melodi — Tue, 11 Aug 2026 00:02:31 +0000

Have you ever wondered what actually happens in the few seconds between clicking a button on a website and seeing something appear on your screen? It feels instant, almost like magic. But there is a real journey happening behind that moment, and once you understand it, a lot of what feels confusing about NestJS starts to make sense.

Think about how a letter travels through the mail. It gets picked up, sorted, checked to make sure it is addressed correctly, handled by the right person, and eventually delivered, with a reply sometimes making its way back to you. Every step exists for a reason, even though you never see most of it happen.

Something similar happens every time you ask an app to do something, even something as small as clicking a button to log in. That click is really you asking the app a question, and what appears afterward is really its answer coming back to you. NestJS is the system responsible for guiding that journey properly, from your ask all the way to the answer.

Your ask first reaches a part of the app whose only job is to receive it and send it to the right place, like a mail carrier delivering a letter to the correct department. From there, it is often checked to make sure it is allowed to proceed, much like a letter being confirmed safe before it goes further inside. Once it clears that check, it reaches the part that does the real work, quietly preparing an answer behind the scenes. And finally, that answer makes its way back out to you, showing up simply as something appearing on your screen.

In case you are curious what developers call these two moments, your ask is called a request, and the answer coming back is called a response. That is really all those two words mean, your question going in, and the answer coming back out.

Here is the lesson worth taking from this, even outside of code. Anything that feels instant on the surface usually has quiet, careful steps happening underneath it, steps that exist to keep things organized and safe, not to slow things down. The more clearly each step knows its one job, the smoother the whole journey becomes.

You do not need to memorize any technical terms today. You only need to know that every ask you send an app goes on a real journey before an answer comes back. Next time something loads instantly, you can smile a little, knowing there was a quiet, organized journey happening behind that speed.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

You Can Actually Understand NestJS, Here Is Where to Start

Peace Melodi — Mon, 10 Aug 2026 22:56:51 +0000

If you have ever opened a NestJS project for the first time and felt a small wave of panic looking at all the folders and unfamiliar words on your screen, that feeling does not mean you are behind. It just means you are looking at order you do not understand yet, and that fades faster than you think.

Here is the one idea to hold onto before anything else. NestJS exists because growing projects naturally turn messy if nothing holds them together, so it gives every piece of your app a clear, dedicated place to live instead of letting everything pile up in one tangled mess.

Think of a NestJS project like a well organized house. A module is like a room in that house, a kitchen, a bedroom, a living room, each one holding the things that belong together instead of everything being scattered across the floor. A controller is like the front door, it is the part that answers when someone knocks, listens to what they want, and decides where inside the house they need to go. A service is like the kitchen, it is where the real work actually happens, quietly, behind the scenes, after the front door has let the request in. And a guard is like the lock on the door, it checks whether the person knocking is even allowed inside before anything else is allowed to happen.

You do not need to memorize any of this today. You just need to know these four pieces exist, and that each one has its own clear job instead of everything doing everything.

So here is where I actually want you to start. The next time you open a NestJS project, do not try to understand everything at once. Just look for these four things, a room that groups things together, a door that receives requests, a kitchen where the real work happens, and a lock that protects access. That is it. That is enough for today.

You do not need to feel ready to master NestJS right now. You only need to start noticing the order that is already there, and trust that understanding follows people who pay attention, not people who rush.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

Why I Chose NestJS and Never Looked Back

Peace Melodi — Mon, 10 Aug 2026 21:19:04 +0000

A few years ago, I was just another developer trying to figure out how to build things that actually work, not just things that run once and fall apart the moment real users touch them. I tried a few paths. I read a lot. I broke a lot of things. And somewhere along that road, I found NestJS.

At first, it looked like just another tool. Another framework to learn, another thing to add to my resume. But the more I used it, the more I realized something. NestJS wasn't just teaching me how to build backend systems. It was teaching me how to think like someone who builds things meant to last.

I did not choose NestJS because it was trendy. I chose it because it made me feel organized in a way nothing else had. It gave structure to ideas that used to feel messy in my head. It made me feel like a professional, not just someone typing code and hoping it works.

Here is the lesson I want you to take from this, even if you never write a single line of NestJS code. Anything you build, whether it is software, a business, or even your own life, lasts longer when it has structure. Not rules for the sake of rules, but structure that makes room for growth without everything falling apart. That is what NestJS taught me first, before it taught me anything technical. Organize your thinking, and the work becomes easier to carry.

Today, when people ask me why I still use NestJS after all this time, my answer is simple. It is not just a tool I use. It is the reason I became confident in what I do. And once you experience that kind of confidence in your work, it is very hard to walk away from it.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

I Created a NestJS Delivery Dispatch Backend with Concurrency Control & Dockerized Postgres

Peace Melodi — Sat, 08 Aug 2026 13:51:53 +0000

I built this delivery dispatch service to practice and master core backend engineering fundamentals in NestJS. Instead of just building a basic CRUD API, I wanted to understand how real-world dispatch systems manage state transitions, handle route assignments, and keep data consistent under concurrent requests.

The backend is engineered with NestJS, TypeORM, and PostgreSQL running inside Docker containers. To handle state protection, I implemented concurrency guards that intercept duplicate route acceptance requests and immediately throw an HTTP 409 Conflict exception before any invalid state mutation reaches the database.

To streamline my testing workflow without manually dropping database schemas, I also built a Node.js automation script (scripts/clear-db.js) that pipes dynamic SQL queries straight into the Docker container via IPC streams.

In the video, I walk through the route acceptance logic, demonstrate how the HTTP 409 conflict guard blocks duplicate claims, and run a live demo of the automated database reset in action.

Check out the video below to watch the full walkthrough in action. If you enjoy the demo, please give the video a like and leave a comment with your thoughts!

How a Double Entry Ledger Works, Built From Scratch in NestJS

Peace Melodi — Fri, 07 Aug 2026 17:06:20 +0000

I built Parity Ledger to solve a problem most backend systems ignore. Most systems track money with a single balance column, a number sits on an account record, it goes up when money comes in, it goes down when money goes out. That works fine until two requests hit the same account at the same time, or until someone needs to know what actually happened to an account months later and there is nothing but today's number staring back.

Parity Ledger is a double entry bookkeeping engine built with NestJS and Postgres. Instead of storing a balance, every movement of money is written as a permanent, immutable entry. Nothing gets updated, nothing gets deleted. Every transaction writes two entries at once, a debit and a credit, inside a single atomic database transaction, so money can never leave one account without landing in another.

To keep things correct under real concurrent pressure, the ledger uses row level locking at the exact point where two requests could touch the same account balance at once. I built a live dashboard to actually demonstrate this, firing two transfer requests at the same account at the same moment and watching the lock force one to wait its turn.

In the video I walk through how it all works, the reasoning behind ditching the balance column, how the debit/credit pairing is enforced, and a live demo of the concurrency lock in action.