DEV Community: Timi

I finally completed my side project

Timi — Wed, 21 Oct 2026 14:27:59 +0000

Timi

Oct 21

Building a Backend for My Old Furniture Store

#backend #nestjs #postgres #sideprojects

5 min read

Building a Backend for My Old Furniture Store

Timi — Wed, 21 Oct 2026 14:27:45 +0000

A few years ago, I started a side project: a storefront that lists furniture for prospective customers. It was my first time understanding how a CMS works under the hood, so I decided to learn Sanity with it. I remember trying to understand GROQ queries and how all of it worked. I got there, and I built the storefront.

Then years went by.

Recently I decided to understand how the backend part of applications works. This was another friction moment. As a frontend engineer, I was used to consuming backend APIs, but I didn't really understand how they worked. So I went back to the furniture store and built a backend for it with NestJS and Postgres. Lo and behold, I found my way around.

This post walks through what I built, flow by flow: auth, cart, orders, and payments.

The mental model that helped

One mental model made everything click: build the logic from services up to controllers.

Services hold the core logic: creating a user, adding to a cart, placing an order.
Controllers set up the routes for those services. These are what I always saw as endpoints from the frontend side.

So when my frontend calls POST /auth/register, a controller receives the request and hands it to a service, which does the actual work. For years I only saw the endpoint. Now I know what sits behind it.

The new terms

Around services and controllers, NestJS has a few more pieces I had to learn.

Modules group everything for one feature: the auth module holds auth's controller, service, and guards.
Imports bring in other modules a module depends on. My auth module imports the users module and the JWT config module, because auth needs both.
Exports make parts of a module available to other modules. I export the auth guards so other modules, like cart and orders, can protect their routes.
Providers are the classes NestJS creates and manages for you, like services.
Constructors are where a class asks for the providers it needs. NestJS sees what a service asks for in its constructor and passes it in. This is called dependency injection.
Guards run before a request reaches the controller and decide whether it's allowed through. My auth guard blocks any request without a valid token.

Auth: creating an account and logging in

The core logic lives in the auth folder.

Registration. I collect basic information about the user. The password is never stored as the user typed it. It's hashed, which is one-way: there's no key that turns a hash back into the password. Even if someone got access to the database, they couldn't read the passwords.

The way it clicked for me: hashing is like a blender. You can't un-blend the result, but the same ingredients always produce the same mush.

Login. Nothing gets decrypted. The backend hashes the password the user just typed, the same way it was hashed at registration, and compares the result to the stored hash. If they match, the password is correct.

Tokens. After login, the user gets an access token. It contains the user's ID and is signed with the server's secret key, so the backend can tell that it issued the token and nobody changed it. Access tokens are short-lived, so I also use refresh tokens. These are long-lived and let users stay logged in without signing in again every time the access token expires.

Cart

The cart module is where a user goes through the store listing and saves items. Users can add available items to their cart, edit a cart item, and delete it.

There's no product table in my database. Products still live in Sanity, so the backend fetches them from Sanity before building a cart. Postgres holds the cart, orders, and inventory; Sanity holds the catalog.

When adding to the cart: if the item is already there, update it. If it isn't, create it.

Prices also come from Sanity on the backend. Before an order is created, the backend computes the cart items and their total. The frontend never sends a price, so nobody can change it before paying.

Orders and reservations

The goal here: no two customers can pay for the same item, even under high traffic.

When a customer places an order, the backend reserves the items in the database. The reservation is kept for 15 minutes. If the user doesn't complete payment in that time, the order expires, a background job releases the reservation, and the items become available again.

The tricky part is the reservation itself. If I checked stock first and reserved it after, there'd be a gap where two users both see "1 left" and both reserve it. So I do both in one statement:

const reservedRows = await tx.$executeRaw`
  UPDATE "Inventory"
  SET reserved = reserved + ${item.quantity}
  WHERE "productId" = ${item.productId}
  AND quantity - reserved - sold >= ${item.quantity}
`;

if (reservedRows === 0) {
  throw new BadRequestException(`${item.productName} is out of stock`);
}

The UPDATE only succeeds if enough stock remains. When two requests hit the same row at the same moment, Postgres makes the second one wait. It then re-checks the condition against the updated row. If the first request took the last item, zero rows are updated and the second user gets "out of stock."

Available stock is quantity - reserved - sold. Reserving doesn't reduce quantity; it increases reserved.

All of this runs inside a database transaction, along with creating the order and its order items. Either everything succeeds or nothing does. If a cart has three items and the third is out of stock, the reservations for the first two are rolled back too.

The order also stores its total and each item's price at the moment it's created. If a price changes in Sanity later, it doesn't affect an order that's already being paid.

Payments with Paystack

Once an order is created, the user pays through Paystack's widget. Paystack is in test mode for this project.

Starting a payment. The request first goes through my auth guard. The backend then calls Paystack with my Paystack secret key as a Bearer token in the authorization header. That key only ever lives on the backend. One gotcha: Paystack takes amounts in kobo, not naira, so the total has to be multiplied by 100.

The webhook. This was the flip for me as a frontend engineer. Normally I call the API. With a webhook, Paystack calls my backend to tell me the payment's status.

The webhook doesn't use my auth guard, because Paystack can't log in as a user. Instead, Paystack signs each webhook with my secret key and sends the signature in the x-paystack-signature header. My backend recomputes the signature and compares. If it doesn't match, the request is rejected, so nobody can fake a successful payment.

Paystack sends back the transaction reference, which is the order ID I sent when initializing the payment. What happens next depends on the order's status:

Pending: process the payment.
Already paid, processing, shipped, or delivered: treat it as a duplicate webhook and ignore it. Paystack can send the same webhook more than once, and this makes sure an order is never processed twice. This is called idempotency.
Cancelled, expired, failed, or refunded, or the amount doesn't match the order total: log the payment, but don't touch the inventory, because the customer hasn't received value for this transaction.

If a customer actually paid for an expired order, their money was taken, so the payment is flagged for a refund. For now, refunds are done manually.

Updating the order. For a valid payment, all the updates run in one database transaction, so either everything succeeds or nothing does. The order status changes to paid, the reservation is released, the sold count goes up, the cart items are deleted, and a successful payment row is created.

Where it stands

The backend runs locally, with Paystack in test mode. Next, I'm connecting the furniture storefront to these APIs, then deploying it. After that, I want to add AI features to the store.

This is a weekly Journal where I get to talk about the open tabs in my head. You should check it out and drop yours too

Timi — Sun, 23 Aug 2026 23:51:16 +0000

Timi

Aug 23

What are you working on? #02

#devjournal #softwareengineering

3 min read

What are you working on? #02

Timi — Sun, 23 Aug 2026 23:50:03 +0000

What are you working on? #02

Alrighttt, how are we doing?

First off, please drop what you're working on this week. 😂

This is the continuation of the series I started last week, where I’m basically documenting some of the things I’m building, learning, figuring out and, occasionally, just thinking about.

So, what have I been working on?

Last week, we were finally able to launch the first version of our credit application internally. This means users within the organization can now use the application and perform actual operations, so we’re moving into more of a user testing phase.

I also had to jump on some pre-launch fixes, and honestly, it was a good feeling.

Launching comes with its own problems, of course, but seeing that announcement mail go out during the week after months of work and iteration was really satisfying. There’s something different about seeing people actually get access to something you've spent months building.

On the backend side, I made some good progress on my e-commerce project too.

I moved from working on the auth flow to users being able to add, update and remove items from their cart. This has been helping me understand the NestJS ecosystem better, especially concepts like dependency injection and the relationship between modules, controllers and services.

This week, I’m moving over to the checkout and inventory side of the project. The goal is to give customers a way to actually pay for their furniture and to start building out inventory management for admin users.

In my software engineering group, a couple of teammates and I are also working on a system design problem for a ticket management system.

That one has been particularly mind-stretching.

It’s one thing to talk about system design in theory, but when you actually have to sit down with people and brainstorm how a system should work, you start seeing how many problems you can create for yourself if you don't think things through properly.

Sometimes, just go through the stress now and save yourself some sleep later. 😂

I’ll also be reading more of Eric Ries’ The Lean Startup this week. It was recommended to me recently, and I haven’t gotten far enough into it to start pretending I have some profound insight from the book yet. 😂 But I’m hoping to cover some good ground this week.

Outside of work and engineering, I spent some time with friends and family over the weekend and really enjoyed it.

I’m also looking forward to the public holiday this week.

Is it me or does the night before a public holiday slap harder than the actual public holiday itself? 😂

There are a couple of other things I’m trying to be more intentional about.

One is using AI more to solve problems in my day-to-day life. I want to get better at seeing a bottleneck and thinking, “Can I build or iterate something with AI to solve this?” It feels like a return to my first love with tech: seeing a problem and trying to build something around it.

I’m also trying to stop running my community responsibilities on vibes. I need to actually put a schedule around the things I’m responsible for instead of leaving them to my mood.

So yeah, that's what I'm working on this week.

A bit of shipping, a bit of backend, a bit of system design, a bit of reading, a bit of figuring out life, and hopefully a bit of rest too.

What are you working on?
Drop it in the comments. I’d genuinely love to hear what you're building, learning, figuring out, or just getting through this week.

what are you working on? sounds familiar

Timi — Sun, 16 Aug 2026 22:12:18 +0000

Timi

Aug 16

What are you working on? #01

#devjournal #development #career #productivity

3 min read

What are you working on? #01

Timi — Sun, 16 Aug 2026 21:51:07 +0000

What are you working on?

I hear these words in my day-to-day.

And sometimes, when I hear them, there’s this little brain freeze that happens because my brain is probably trying to put into words the amount of things that have wandered through my head in the last 24 hours. 😂

So I thought, okay, let me try something.

I want to take some of those wandering thoughts, explorations, things I'm trying out and things I'm learning, and put them into writing.

This is going to be a series where I come and talk about what I'm working on — software engineering, product, work, people, faith, relationships, rest, and whatever else happens to be taking up space in my head at the moment.

So, what am I working on?

I recently started writing backend code, and there’s a bit of a backstory to that.

I built this frontend commerce store years ago where people can come and shop for furniture. At the time, I used a backend-as-a-service to handle the backend side of the application.

Now, I’m coming back to that same system and writing the backend myself with NestJS. I wanted to go beyond just consuming a backend and actually understand what is happening behind the scenes.

The learning process is a bit stretching at the moment because I’m getting familiar with a lot of new concepts. Tiring and frustrating? Yes. But the feeling when I finally understand the reason behind something is always refreshing. That has been really rewarding lately.

I'm also in the middle of launching a mobile application at my workplace, going through system design classes, figuring out how to get the best out of my engineers (AI sub-agents, by the way 😅), and occasionally imagining that dream job where you get to build products that serve millions of people and work with really brilliant minds.

Also, I discovered the productivity rush that comes with using large monitors. 😂

Then there's learning how to rest while also trying to close out all the open loops in my head.

Building reading habits.

Figuring out what to prioritize and, perhaps more importantly, what to drop.

Learning how to build healthier mindsets about life in general.

And sometimes, honestly, maybe all I'm working on is getting some rest or laughing about something ridiculous that happened during the week.

That's kind of the point.

I don't want this to be a series where I come here every week with a perfectly packaged lesson or pretend I've figured everything out.

I just want to document some of the things I'm thinking about and trying out as I go.

I also want to get better at something I've been thinking about for a while: when I see something I want to do, I want to find the closest point of execution instead of waiting for permission to move.

Sometimes we know what we want to do, but somehow convince ourselves that we need to go three levels up, get approval, find the perfect plan, or wait until we're completely ready.

Meanwhile, the closest point of execution might literally be the person sitting on the same floor as us.

Or, in this case, it might just be opening a blank page and starting to write.

So yeah.

Me starting this series is my point of execution.

Let's see how it goes over the next couple of weeks.

And I'd genuinely love to hear from you too.

What are you working on right now?

It could be software engineering or whatever field you're in. It could be something you're building. It could be something you're learning, something you're trying to figure out, something you're trying to let go of, or maybe just something funny that happened this week.

Drop it in the comments. Let's talk.

Also, yes, the last time I said I was writing something, it didn't ship. 😂 Long story.

But we're here now.

Let's try this.

Amen.

Good stuff

Timi — Sun, 09 Aug 2026 01:20:16 +0000

Shwetha

Aug 6

Fixing your site's metadata: a practical checklist

#webdev #seo #metadata

6 min read

Picked up backend last week, I think I like what I am seeing

Timi — Thu, 23 Jul 2026 13:58:18 +0000

Good read

Timi — Tue, 16 Jun 2026 15:26:01 +0000

Tawanda Nyahuye

Jun 16

Luck == Opportunity Meets Preparation

#productivity #career #learning #analytics

9 min read

Building with AI

Timi — Fri, 22 May 2026 21:31:35 +0000

Timi

May 22

Keep Your Taste

#ai #programming #learning

3 min read

Keep Your Taste

Timi — Fri, 22 May 2026 21:25:58 +0000

I know I said I was going to keep writing about concepts I use every day as a frontend engineer. Previously, I wrote about things like SPA routing, client-side vs server-side rendering, CDNs and all that good stuff. Life happened, a month went by, and honestly my workflow changed so much that it felt wrong to just jump back in without talking about it first.

Not that I stopped learning or building, far from it actually, but the way I approach features and fixes now is very different from what it used to be, mostly because of AI tools like Claude Code.

These days, I spend more time supervising code than actually typing every line myself.

At first, that feeling messed with me a little bit. It almost felt like I was cheating the process somehow. Like, if I’m no longer manually implementing every single thing, what exactly is my role now?

But after a lot of reflection, I’m starting to understand that engineering was never just about repetitive implementation. We were primarily created to think. To make decisions. To identify tradeoffs. To know why something should exist and what approach makes the most sense.

One thing AI does brilliantly though is helping ideas move from zero to one very quickly.

Previously, you could have an idea, think deeply about it, maybe even start building it, then life happens. Work happens. Priorities change. Maybe you just lack discipline (sarrry sarrry 😭) and the project just ends up in the dump of unfinished side projects.

I think a lot of engineers can relate to that.

I got an idea a few months ago that was very personal to me. I started actively taking notes during church services and events, but I noticed I rarely went back to read them. Sometimes the next time I opened a note was the next Sunday.

Discipline issue? Maybe. But I started thinking the real problem was visibility. It’s easy to forget things you never see again.

So I built something. A reminder based mobile app that resurfaces my notes intentionally throughout the week.

And building it was the first time I really felt what AI in a workflow actually means.

I had the idea, I knew the problem, AI helped me move fast on implementation. It gave me a solid template to work with. But decent wasn’t enough. My experience with UX meant I could look at what it gave me and immediately know what felt off. Certain flows weren’t natural. Some interactions didn’t match how users actually behave. So I made the adjustments, not because AI did a bad job, but because I already had a standard in my head.

That’s when I really started understanding taste.

And honestly the code AI produces is very decent my bro 😭

Decent enough that if you’re not careful, you stop thinking deeply about the decisions being made. Sometimes I catch myself just accepting changes quickly without really sitting down to understand if it’s actually the best approach.

But a colleague told me something recently that stuck. He said one thing AI will not take away from engineers is taste.

For me, taste is feeding your mind well enough to make sound judgments. Experiencing enough to know what good actually looks like. Because AI can generate templates but taste is what takes things from generic to actually good.

There has to be a standard in your head already, otherwise AI becomes the standard, and that guy can give some very generic stuff 😭

And honestly staying open minded is not a bad thing. It exposes you to a lot. The good stuff, the bad stuff, all of it. And that’s actually how taste gets built. You have to see what doesn’t work to know what does. So when AI puts something in front of you, you already know.

Thinking gives you something to drive towards. Leave your mind completely open and you will accept anything. That’s what taste protects you from.

So yeah, let’s keep building our taste, keep building things, and keep growing into better builders.

Till I come across something again… see you soon. Byeee 👋

It's a good day to learn more about CDNs

Timi — Mon, 23 Mar 2026 10:24:47 +0000

Timi

Mar 17

Understanding CDNs (Content Delivery Networks)

#performance #webdev #cdn #frontend

5 min read