DEV Community: divv.dev

A day in the life of a beginner JavaScript backend developer

divv.dev — Wed, 29 Jul 2026 02:22:54 +0000

When I just started NodeJs some months ago, I had a smooth ride, understanding came easily. But one error remains evergreen in my memory. A mongoose error.

While co-coding on a tutorial course with my instructor we were working on a user managment system while learning CRUD (Create, Read, Update, Delete ) operations with Mongoose. The course was quite outdated so I thought it nice to use the docs while coding. He used User.create() to create new users in the database but in the docs I found something better. Or so I thought. Using new User() to create users. But something was wrong.. I was'nt seeing any of my new Users in the database. 😭😭😭

I ran my code checked my schema, checked my connection, restarted Vs-code, Postman, my system.. What did I not do that day. Haa God help me I prayed. Frustration everywhere.

Eventually, I took a break. I went to watch a movie, and then I slept until the evening. I woke up and decided to face my nightmare (no pun intended).

I checked the mongoose docs again and found my solution. I decided to revisit the Mongoose documentation. I quickly realized that while new User() creates a new user instance, it doesn’t save it to the database unless you explicitly call .save().

That was it... I fixed it... That was the only thing I did that day. But at least I was growing and learning at the same time. And that is what matters. That's one of the reasons I joined the https://hng.tech/internship program so I can be pushed to the limits of learning more and growing.

If you wish to learn more about HNG Intership check out https://hng.tech/premium.

So bye.. And have an error free day! 👋👋

2024...

divv.dev — Wed, 29 Jul 2026 02:22:53 +0000

I really didn’t see this article coming. I didn’t plan to write a Year in Review, or make a post, or a video, or a collage, or a thread, or a recap — or whatever you guys call it. I didn’t see the point. I thought, “Who wants to read this? I didn’t make 1 million Naira, I didn’t buy a MacBook, I didn’t land a full-time role, and I didn’t get to say, ‘Thank you, JavaScript, TypeScript, CSS, or Web3.’”

But one thing I did get to say was, “Thank You, God.”

I thank God for the experiences I had this year, for the people I met, for my friends, my parents, and myself. I eventually decided to write this because it just felt right (can’t elaborate further). Plus, it’s a nice way to keep a record of myself for 2024. So, read on. Or don’t.

Last year was all about growth and learning for me. Cybersecurity wasn’t even on my radar at the start of the year, but here I am, going into it thanks to a friend who motivated me (and as a bonus, Cybersecurity is actually my minor in school). I also started exploring Web3 — from just scratching the surface to joining an academy to learn more in-depth, all for free. Don’t worry; you’ll see results this year.

My mindset has completely shifted. I’ve grown bolder and more confident, knowing I can take on anything I set my mind to. Whatever it is, I’ll make it work. I’ve also learned to stop blaming others (or circumstances) for my failures and take full responsibility. This shift has made me more determined than ever to work harder and achieve more.

I had some wins too. I completed my two-year-long diploma in Software Engineering at Aptech, which feels like a huge milestone. I also got my first gigs, which taught me a lot in software development and gave me my first taste of spending money I earned myself. Let’s just say — it feels good lol.

This is the simplified version of how I spent 2024. I think I’ve found direction now. I know where I’m going (not that I was lost last year, lol), but things feel clearer. I won’t lie, I’m scared of the work I need to do this year, but I’m not backing down or complaining. More lessons, more experiences, more projects, and more wins — here’s to all of that in 2025.

Happy New Year!

Why I have written nothing this year

divv.dev — Wed, 29 Jul 2026 02:22:51 +0000

The answer is simple.. lots and lots of laziness and oversight.

I remember the begining of the year like yesterday. Well wasn’t it yesterday. I made severall promises. To myself, to people around me. One of them being I would write more blog posts. I didn’t keep that promise. (note the choice of words not ‘couldn’t but didn’t‘).

Writing, for me isn’t my favourite thing to do. I love coding, I love playing games, I spend 30% of my time scrolling mindlessly on X (not that I love that though). But,, I also love looking back. I’m still young and growing and I love making memories, and looking back at them in any form. Weather its taking pctures and videos, or making random ass posts on X to pen (we don’t actually use pens on twitter) down what I’m currently thinking. So I have to do something i don’t love (Writing long ass blogs) to get what i want (documentation in the future).

I didn’t write this year cause I procrastinated a lot. Oh… let me be done with my website I’ll build a dedicated blog section on it and start writing there. Oh.. this portfolio I built is trash let me redesign it and build a blog on that redesign and start writing there. Oh I won’t like writing blogs in code let me build a blog application where I can write my blogs and dynamically render it on my website and other blog platforms cause I wasn’t sure of what to stick with. (Substack, Medium, Hashnode, Dev.to). Eventually I found out the reson i settled with hashnode in the first place. It has excellent developer support. I can write on Hashnode and use the content anywhere using it as a Content Managment System and just fetch and render on my website. I can set up RSS feeds and also work with emails and newsletters in a developer friendly way. It had everything i wanted to custom build. I was just being lazy and distracted.

console.log("I can even write code blocks lmao");

But not anymore. I’d write more going forward. Thanks to my inner conviction of making memories and people like DHH and Theprimeagen (not elaborating further).

Thanks for reading and see you some other time.

2025...

divv.dev — Wed, 29 Jul 2026 02:22:50 +0000

Haha I remember writing 2024… like yesterday. It’s funny how days crawl and years fly. Last year was an experience.

I feel the same way I felt last year..I didn’t want to write cause I didn’t know what to write about but HERE WE GO.

I made the biggest steps in my life this year. I had to leave the comfortable life I had for a little bit more stressful one. I was looking for ‘experience’ they were looking for cheap labour. Perfect match. Nevertheless, I’m proud of my time there. I got to socialize more, touch grass, and meet different people. Funny, lazy, weird, intelligent people. I learned to look life in a third person perspective. It was fun while it lasted though.

There’s something I also clocked (clocked this word clock too lmao) last year.. I didn’t want to make a ton of money and be rich or to get a better job as much as I wanted to be good. I wanted to be very good, talk about worldclass. It was an obsession, it was a drive and it led me to places, trying out different things. Did I become worldclass? NO! Am I closer than I was in 2024 YES!! That is a W in my opinion.

“Run fast alone run far together“ I randomly do/commit to things without thinking first. I don’t know what type of breeze was blowing at 11:00pm of 26th December but I sent this text. I wasn’t faithful to my promise my laptop had an issue around March and I lost all the momentum I had the past months. That didn’t stop me from making 26 posts and gaining some traction on LinkedIn just that I wasn’t following the time schedule I set for myself. Hacker is a nice guy and I probably owe him at least 20k😭😭.

I showed you that so you can see that community is everything. If he didn’t remind me (even though most times I ignored) I wouldn’t have that urgency to post again. I cant possibly talk about how many many times my friends I told to keep me accountable have helped me. I can’t mention them cause I didn’t ask for permission to.

I spoke at devfest ajah too about Ai routers and now I’m too lazy to keep on writing. I’ll make another post about that and some other stuff in detail next time. I wrote this post cause I had to and its 4:21 now.

I also created some whatsapp groups. cracked builders and rustaeceans. I am glad I didn’t overthink and just did what was in my mind.. we are set to do great stuff in 2026. Random advice?? Just Do It

This post barely scratches the surface. Summarizing 8,760 hours of life into one blog post was an impossible task from the start. But I still made a post.. And I was consistent.. That counts for something right??

While it was a great year, it wasn’t a perfect one — and that’s fine. I learned that momentum is fragile, discipline beats motivation, and community quietly carries you when you start slipping. I learned that being “good” is harder than being “lucky,” and far more rewarding.

I didn’t become world-class yet, but I moved closer. I spoke, I tried, I failed, I showed up inconsistently, and I still showed up. That counts.

2025 reminded me that growth doesn’t always look loud. Sometimes it looks like choosing discomfort, losing momentum, finding it again, and refusing to quit.

How I created a Custom Blog using Hashnode as a CMS

divv.dev — Wed, 29 Jul 2026 02:22:49 +0000

If you’ve read my blogs recently you’d notice something reoccurring. Me always saying I want to write more. But now I’ve put the structures in place that makes that possible. My first blog post was because of HNG in 2024. They said we should write an article as our stage 0 task. In so much loved the experience of writing on Hashnode but didn’t write another article till December 2024.

Hashnode had all I wanted but I wanted my blog on my webiste. That led me to research and eventually I found out I could use it as a headless CMS to manage, write and store all my articles. This blog posts written on Hashnode gives a high level explanation on how I did it and how you can too.

Architecture Overview

I already had my website up and running so my work was simple. Just fetching posts from the endpoint hashnode would provide and then rendering it on the website.

How the Content Flows

So here’s how this thing actually works in practice.

I write and publish all my posts on Hashnode. I don’t use it as a “blog platform” in the traditional sense it’s just the place where content lives. Hashnode handles drafts, publishing, and storing the content, and it also serves that content from its own edge servers, so reads are already geographically close and fast.

My site itself never serves content directly from Hashnode though.

When someone opens a blog post on my site, the request hits my server, not Hashnode. From there, an Astro API Route kicks in (same idea as a Next.js API Route). That API route runs on the server and makes a GraphQL request to Hashnode to fetch the post data.

Important detail: this fetch is server-side only. The browser never talks to Hashnode. No public GraphQL calls from the client, no exposed tokens, no client-side fetching.

Once the data comes back, the Astro server r enders the full HTML for that post on the spot. That’s what server-side rendering means here: the server literally builds the final HTML after you request the page, not at build time, and not in the browser with JavaScript.

The response that gets sent back is already complete HTML. The browser just displays it. There’s no “loading state”, no client-side render step required just to read a post.

To avoid hammering Hashnode and to avoid paying the SSR cost on every request, the rendered HTML is cached on Vercel’s server layer for 24 hours. So the first request after the cache expires does the fetch + render, and everything after that just gets the cached HTML.

Benefits of This Approach

I was able to optimize heavily for SEO here with dynamic meta tags, Open Graph images, and content-specific descriptions generated directly from each blog post. All of that HTML is present before the response ever reaches the browser.

This would not have worked well with a client-side rendered approach. In CSR, JavaScript has to load, execute, and fetch data before meaningful HTML exists. Search engines can execute JavaScript now, but they do it later, inconsistently, and with stricter resource limits. You’re basically hoping the crawler sticks around long enough to render your page. That’s not a reliable SEO strategy.

With SSR, there’s no guessing. The crawler gets exactly the same HTML a user gets.

Another benefit is predictable performance. The browser doesn’t need to download a JS bundle just to read text. The page is readable immediately. JavaScript becomes optional instead of mandatory, which matters a lot on slow devices or bad networks.

Caching makes this approach practical. The expensive part fetching from Hashnode and rendering HTML only happens on cache misses. Even without caching, Hashnode’s edge servers are fast enough and the API limits are generous enough that this would still work just fine in practice as long as there are no bad actors (coughs Hacker) or I am not a celebrity. One day

Everything else is just serving static HTML from Vercel’s edge, which is cheap and fast. Without caching, SSR would be an unnecessary overhead.

Drawbacks of this Approach

As there are advantages there are also disadvantages. The most prominent one being everything being coupled to Hashnode’s Api. If their API is slow or unreachable and the cache is cold, the page doesn't render. Caching hides this most of the time (cause I don't think any serious platform would be down for 24h) but the dependency is still there.

The cache itself is a tradeoff. A 24 hour time to leave (TTL) means content can be stale. If I update a post or fix a typo, users will see the old version until the cache is expired or manually invalidated. That's acceptable for a blog but not too great for time sensitive content.

From a security perspective, SSR reduces exposure but doesn’t eliminate risk. Because each request can trigger backend work, the system is still vulnerable to traffic-based abuse. Without proper rate limiting, someone can force repeated cache misses and amplify load on both your server and Hashnode’s API.

Finally, this setup is very opinionated. It works because the problem is simple: read-only blog content. The moment you add users, comments, personalization, or real-time features, this architecture stops being the right tool. Will I add all these features?? I DON'T KNOW, but they are fun to think about.

Conclusion

If you stayed till the end. Thanks a lot.Fun fact this will be my 2nd technical article and I will be writing more deep dives about things I love and things I'm working on so stay tuned ( not like I made that possible lmao). Till we meet again.

I learnt Docker so you don't have to

divv.dev — Wed, 29 Jul 2026 02:22:49 +0000

I lied.

I didn’t learn Docker so you don’t have to.

I learned it because it’s genuinely fun and incredibly useful if you’re serious about a career in software engineering.

So let’s get into it. What is Docker.. why does everyone keep saying “containers” when talking about it? What is an image? Can Docker take pictures? What is the importance of Docker? Why does my code break on prod when i run git push? All these and more I’ll answer in this here.

What is Docker

Docker is an open-source containerization platform that allows developers to package applications and all their dependencies into a standardized, isolated unit called a container. This ensures the application runs consistently and reliably across any computing environment, from a developer's laptop to a testing server or a production cloud platform, effectively solving the "it works on my machine" problem.

When developers build applications, they rarely start from scratch. Instead, they rely on existing code, packages, and tools to move faster.

For example, if I were building an e-commerce site, I’d probably use:

a Node.js runtime (because I’m more comfortable with TypeScript),
Sanity as a CMS,
Clerk for authentication,
and other libraries depending on the features I need.

Before that application can even run, all of these pieces must be present and correctly configured. If any one of them is missing the runtime, a package, an environment variable the application simply won’t work.

All the packages, tools, and software that an application needs in order to run are called dependencies.

This poses a big problem during hosting.

Your local machine already has a lot of things installed: a specific Node.js version, system libraries, environment variables, and cached dependencies. The server you deploy to does not. It starts clean.

So when you push your code to production, you’re not just deploying your application, you’re implicitly assuming that the server has the same environment you were developing in.

Most of the time, that assumption is wrong.

That’s why:

your app works locally but crashes in production,
a dependency behaves differently on the server,
a package installs fine on your machine but fails in CI,
or a minor OS difference suddenly becomes a runtime bug.

This isn’t a coding problem.

It’s an environment problem.

And historically, developers tried to solve it with:

long setup docs,
shell scripts,
manual server configuration,
or “just install Node v20 and hope for the best”.

These approaches don’t scale, they drift over time, and they break silently.

This is the exact problem Docker was built to solve.

Docker was built to let developers define their runtime environment as code and ship it alongside the application, so the same environment can be reproduced across development, CI, staging, and production.

Images & Containers

A Docker image is a read-only template that contains everything needed to run an application: the filesystem, runtime, libraries, and the instructions for how the application should start.

A Docker container is what you get when that image is executed. It’s the running form of the image, isolated from the rest of the system, but using the exact environment defined inside the image.

You can start multiple containers from the same image, each behaving independently, even though they all originate from the same definition.

Simply put, think of it like this: the Docker image is the recipe, and the Docker container is the cooked food. The recipe tells you exactly how the meal should be made. The container is the meal while it’s being eaten.

How Images Are Created

Docker images are built using the Docker CLI and a file called a Dockerfile.

A Dockerfile is a plain text file that contains a sequence of instructions describing what the image should look like: which base image to start from, which dependencies to install, which files to copy into the image, and how the application should be started.

When an image is built, everything defined in the Dockerfile becomes part of that image. From that point on, the environment described by the image does not change. If you need to update a dependency, modify the filesystem, or alter how the application starts, you don’t change the image directly. You update the Dockerfile and build a new image.

That’s why it’s called an image.

This immutability is intentional. It’s what makes Docker environments predictable and reproducible.

The Core Idea

So the problem Docker solves is simple.

Docker brings consistency to development workflows.

When the environment stops changing, an entire class of bugs disappears.

This is the first part of a multi-part series on Docker. In the next parts, I’ll build on this foundation and get into how Docker is used in practice.