DEV Community

Angel Umeh
Angel Umeh

Posted on

Turns Out I Never Knew What Node.js Was

#devjournal #career #learning

I started AltSchool Africa's Backend Engineering program already knowing how to code. I had about 3 years of frontend experience (and multiple Hackerrank certificates to show for it), and had already held professional roles the year prior, so I'd shipped things. I assumed the program would mostly hand me new syntax to bolt onto what I already knew.

That assumption didn't survive the first semester. Thirteen projects later, I don't build software the same way anymore. This is the long version of that story, mostly for myself, but also for anyone weighing whether a structured year-long program is worth it when you already have some experience.

The browser was my whole world

Before AltSchool, I built interfaces. I knew how to make things look right and behave predictably in the browser. What I didn't have was a real mental model of what was happening on the other side of the request. APIs were things I consumed, not things I designed.

That changed early. Once I understood how a request actually moves through a server, gets validated, hits a database, and comes back, my frontend work started improving on its own. I started asking better questions, like why an endpoint was shaped the way it was, instead of quietly adjusting messy frontend logic around it. Frontend development became a way to visualize the systems I was learning to build, which made me sharper on the data side too. It was a side effect of finally understanding both ends of the same conversation.

Unlearning JavaScript

Somewhere in the first few months, I had a moment that felt almost embarrassing given how long I'd already been writing JavaScript. I realized I had never actually understood that Node.js is just a runtime for executing JavaScript outside the browser. Not a framework or a language extension. This reorganized a lot of loose knowledge I'd been carrying around for years.

The same thing happened with TypeScript. I'd always thought of it as just "harder JavaScript" because of the extra syntax, which is technically true but misses the point. Working with NestJS revealed the true power of TypeScript. It is the essential backbone of modular architecture, and its static typing catches entire categories of bugs before they ever exist. The fun part of this was making a codebase legible to whoever opens it next, including future me. I even realized some of the descriptive tooltips in a code editor come from intentional typing and scoping made possible with TypeScript, not some editor magic. I even picked up a HackerRank certification in Angular (Intermediate) even though it wasn't part of the program's stack, simply because I understood well enough to prove so under a clock, with no IDE hints and no Stack Overflow tab open.

I also learned the difference between an API and a server that just supplies data. That distinction sounds small until you're the one designing the boundary between what a client should be allowed to ask for and what the server hands back regardless of the request.

Learning to design data instead of just querying it

A recurring lesson across almost every project: filtering and shaping data is a database concern, not an application concern. Early on it's tempting to pull everything with a broad select('*') and slice it down in application code. It works, but it's also wasteful and it doesn't scale. Now, I ask of any new endpoint what the query itself should already be doing before the data ever reaches application code.

This connected to and refreshed the SQL experience I thought I already knew from my data science work in Python. I saw that I knew how to write queries against data someone else had already organized for me. PostgreSQL, used properly inside a real application with real constraints, forced me to think about schema design, indexing, and query efficiency in a way ad hoc data science scripts never had.

My stateless tokens were rather stately

Early in the program, I made a mistake common enough to be almost a rite of passage: I misunderstood how JWT authentication is supposed to work and often stored tokens in server side sessions (who doesn't love baking cookies, eh?), which defeats the entire point of a stateless token. JWTs are meant to be self contained and verified straight from the Authorization header on every request, no session middleware holding state on the server.

I learned why stateless authentication exists as a pattern, and every project since, including my capstone, uses proper Bearer token verification with role based access control, and I understand exactly why it's built that way instead of just copying a template.

Reopening Florence with new eyes

I'd actually already tried backend engineering before AltSchool. My first experience was when I was trying to figure out CORS limitations, and with some help from my friends I once wrote up a simple server. I even built my own startup's product, Florence*, surrounded by a lot of documentation and some AI (well before today's LLMs got as good as they have at coding).

Around the seventh month of the program when I went back to Florence, it was actually a proud moment for me to be able to laugh at my code. I could point to the exact architectural gaps, the places I'd skipped proper validation, the parts where I'd solved problems with brute force instead of a structural fix. This was one of the more validating moments of the whole course. I hadn't just learned new things in a bootcamp, I could revisit problems I'd already run into in the wild, on my own, before I had the language for them.

Projects for breakfast, lunch and dinner

AltSchool's diploma program runs three semesters. Across all three, I worked on some thirteen projects as a requisite part of my coursework, not counting theoretical assessments. My GitHub list has the full lineup:

It was roughly one significant submission every three to four weeks, for a full year. It was the kind of intensity I wanted, and throughout it I held myself to a standard of treating every assignment as something that should be portfolio-ready.

First semester was web fundamentals: semantic HTML, CSS Flex & Grid, responsive layouts, and JS in the browser.

Second semester was where the backend actually began: Express servers, MongoDB, REST API design, CORS, JWT and session-based auth, validating data with Joi, testing with Jest, documenting everything in Postman.

Third semester raised the ceiling: TypeScript, cron jobs, queues with BullJS, webhooks, rate limiting, logging, security hardening for Express apps, WebSockets with Socket.io, object-oriented design, server-sent events. Best part? None of it stayed theoretical. Cron jobs became the core of the reminder emails on the birthday reminder app. Webhooks became the Paystack confirmation flow in the restaurant chatbot.

By the time I got to my capstone project, I wasn't doing anything new under the pressure of a deadline or the need to make something fancy; I was simply applying patterns I'd already stress-tested a dozen times.

Part of that standard also meant documenting my APIs properly, and I did not expect to enjoy this. Documenting an endpoint forces you to step through exactly what happens: what the request looks like, what validations run, what the response looks like when everything goes right and how I find the weak points in my own code. In my attempts to make the documentation clearer and more robust, I frequently caught errors and edge cases I had forgotten to think about, which usually meant the API got better in the process of fixing them. Documentation stopped being a chore to satisfy a grading rubric and started being another phase of the real work.

One pattern that became obvious partway through the program was that Frontend Mentor challenges I'd built years ago as pure UI exercises could become full-stack, real products the moment I paired them with a proper backend. I just caught a fun opportunity to build functionality behind a design I already liked, and I didn't miss it. My favorite example is Blogr, originally a blog API built and documented for my second semester exam, that's evolved into a full stack app with design inspiration drawn from a Frontend Mentor blog landing page. The aesthetic & style was extended to more pages to better capture the API's capabilities (see it on GitHub). I wrote about that semester here.

Eventful, literally

Eventful is an event ticketing platform I submitted for my Capstone Project, and it's the clearest evidence of everything above landing in one place:

  • NestJS on the backend, Next.js on the frontend
  • Supabase/PostgreSQL for the data layer
  • Paystack for payments, confirmed via webhooks
  • Nodemailer for transactional email
  • QR codes generated and embedded into ticket emails, scanned at the door to mark tickets used
  • Scheduled reminder emails via @nestjs/schedule
  • JWT auth with role separation: creators get event management and analytics, eventees get ticket purchasing and their own history
  • API Docs on Postman

None of these pieces were unfamiliar by the time I built them. I'd already used Paystack for Florence* and on prior assignments like the restaurant chatbot. I'd worked with Supabase and PostgreSQL enough times that schema design felt automatic instead of intimidating, I even knew how to drop and recreate tables. The QR flow, encoding a ticket identifier, generating a PNG, storing it, verifying it later, was new in the specific implementation but not conceptually foreign, specifically because I'd already built comparable verification flows for smaller assignments, but generally because my time in AltSchool had reinforced in me how to use the knowledge I already have to gain more.

I was selected to present Eventful at my pre-graduation showcase, and by all accounts it went well. Part of that came down to something I already had before the program: an eye for clean, consistent visual design, which you might notice in the slides. But most of it came down to preparation: because the capstone wasn't far removed from a year of assignments and prior years of experience in technical communication & presentations, I could easily tell a technical story to a mixed audience without hesitation.

The multitasker

AltSchool ran concurrently with my NYSC service year. I remember missing my opening parade march to write my AltSchool entrance exam, which I scored 90% on. By the time NYSC wrapped up on 21st May this year, I was eagerly awaiting the start of my capstone exam, which I submitted a fortnight later. For most of the stretch in between, I also held down full-time work: about seven months as a frontend engineer, followed by a full stack contract role for about 6 weeks. Backend fundamentals from AltSchool showed up almost immediately in decisions I was making at work, and constraints I ran into at work sharpened how I approached AltSchool assignments. It wasn't always easy to manage the schedule, but the pressure was exciting because I never had the luxury of learning something and forgetting it before I got to use it.

In the same May, I built and shipped my portfolio site after almost 8 months of putting it off. It is live at angelumeh.dev, with most of what's here in more detail than a single article can hold.

More than code

AltSchool's coursework wasn't only practical. Alongside the assignments there were quizzes that tested understanding, which separated it from being yet another code-and-submit bootcamp. But the part I didn't expect was the career support layered on top of the technical curriculum. CV positioning, application strategy, and professional presentation and communication were treated almost as seriously as the code. Some of it I already knew from experience, but it was a pleasant relief to know that AltSchool reinforced these things (and would have taught me regardless). I've since learned to present myself better as a candidate, a skill I've been approximating on my own for a long time.

I'm really grateful for the friends who supported and encouraged me through the program, especially Zubair (@zubs) who always had the time to read my code and helped me see the process of API documentation for what it is; and Edwin who helped sharpen my understanding of database design. Working near experienced people and getting called out kindly but clearly made it more real and a lot less academic.

What's next

A year of AltSchool didn't just add backend skills to a frontend résumé. It gave me a way of thinking that connects both sides of a system, and thirteen projects' worth of proof that it wasn't accidental.

What's actually next though is I'm searching for my next role. I build across the stack and I'm open to a role that connects me to talented people and allows me to build the way this past year has taught me to. If you're deciding whether a program like this is worth it when you already have some development experience, my answer is this article. 😁

Author

Thank you for reading this far! Connect with me via:

Top comments (0)