DEV Community: Tech In Vernacular

Microservices and Micro-Frontends: Full Gist Wey Every Engineer Suppose Know.

Tech In Vernacular — Wed, 15 Jul 2026 16:40:52 +0000

As a software engineer wey don build system wey don scale, make I break down this two big big architecture pattern for you. No be small thing, so grab seat, this one go long o.

Wetin We Dey Talk About Here

For software world, when your app don grow reach one level, one big question go dey knock your door: "How I go split this thing wey don become too big for one team to fit manage?" Na so two related but different answers come dey: Microservices (for backend) and Micro-Frontends (for frontend). We go waka through both, cover why people dey use am, why some people dey avoid am, and every corner and nuance wey dey inside.

Part 1: Microservices

Wetin Microservices Be

Microservices na architecture style where you break one big application (wey dem dey call monolith) into plenty small, independent services. Each service dey own im own business capability, im own database (most times), and e fit deploy separately from the rest.

Instead of one big codebase wey handle everything, like User Management, Payment, Notification, Order Processing all inside one project, you go split am into separate services: user-service, payment-service, notification-service, order-service, and dem go communicate through network, mostly using REST API, gRPC, or message queue like Kafka/RabbitMQ.

Why Microservices Come Dey Exist

Back in the day, most apps na monolith. As company grow, wahala come start:

Deployment palava: You wan change one small button color, but you go redeploy the whole giant application. Risk high.
Scaling wahala: If na only your payment module dey get heavy traffic, you no fit scale am alone, you go scale the whole monolith, wey dey waste server resource.
Team wahala: If 50 engineers dey work inside one codebase, merge conflict go dey plenty, deployment go dey slow, nobody sabi everything again.
Technology lock-in: The whole app dey stuck with one language, one framework, even if one part for don better with different tech.

Microservices come solve this one by breaking things down so each team fit own dem service, deploy independently, scale independently, and even choose dem own tech stack if e make sense.

Types of Microservices Architecture

Microservices no be one-size-fit-all, plenty pattern dey inside:

API Gateway Pattern: One entry point (gateway) wey dey route request go the correct service. E dey hide the complexity of many services from the client.
Database per Service: Each service get im own database, no shared database. This one dey enforce loose coupling but e bring am own wahala (we go talk am later).
Event-Driven Architecture: Services dey communicate through events (using message broker like Kafka, RabbitMQ, SQS) instead of direct calls. This one dey reduce tight coupling.
Saga Pattern: For transaction wey span multiple services, since you no fit use normal database transaction again, Saga dey use sequence of local transactions with compensating actions if one step fail.
Sidecar Pattern: Extra functionality (logging, monitoring, security) dey attached as separate process beside the main service, common for service mesh like Istio.
Strangler Fig Pattern: Gradual way to migrate from monolith to microservices, small small you dey "strangle" the old monolith by replacing pieces of am with new services.
CQRS (Command Query Responsibility Segregation): Separate the read model from write model, sometimes each get dem own service and database.
Backend for Frontend (BFF): Different backend service dey created specifically to serve different frontend clients (mobile app, web app go get dem own BFF).

Advantages of Microservices

Independent deployment: You fit deploy payment-service without touching user-service. Less risk, faster release cycle.
Independent scaling: If notification-service dey chop plenty traffic, you fit scale only that one, no need waste money scaling everywhere.
Technology freedom: One team fit use Node.js, another fit use Go or C#/.NET, as long as dem dey communicate through well-defined API contract.
Fault isolation: If one service crash, in theory the whole system no go die, other services fit still function (though this one need proper design, e no automatic).
Team autonomy: Small team fit own one or two services end-to-end, dem sabi am well well, ownership dey clear.
Easier to understand individually: Each service dey smaller and more focused, so new engineer fit understand one service faster than trying to understand giant monolith.

Disadvantages

Distributed system complexity: Now you get network calls everywhere, and network dey unreliable. You go need handle timeout, retries, circuit breakers, wetin dem call "fallacies of distributed computing."
Data consistency wahala: Since each service get im own database, you lose ACID transactions across services. You go need eventual consistency, Saga patterns, and dat one dey complex to reason about.
Operational overhead: Now you get plenty services to deploy, monitor, log, and debug. You go need proper DevOps culture, container orchestration (Kubernetes), CI/CD pipeline for every service, centralized logging (ELK stack, Grafana/Loki), distributed tracing (Jaeger, Zipkin).
Testing complexity: Integration testing across services harder pass testing one monolith. You go need contract testing (like Pact) to make sure services no dey break each other.
Latency: Every inter-service call na network hop, and network hop dey slower pass function call inside one process. If one request need call five services in sequence, latency go add up.
Debugging nightmare: If bug dey, e fit dey inside one of ten services, and you go need distributed tracing to even find where the problem start from.
Cost: More infrastructure, more servers/containers, more monitoring tools, all of this cost money and engineering time.
Premature complexity: Many startup don kill demself by adopting microservices too early, before dem even sabi wetin dem business domain boundaries be.

When Microservices Dey Applicable

Company/product don grow big, multiple teams dey work on the same codebase, and coordination don become bottleneck.
Different parts of the system get very different scaling needs (e.g., search service need plenty compute, but admin panel no need am).
You need independent deployment cycles because one team dey move fast, another dey move slow, and you no wan block each other.
The business domain don clear well well, you sabi where the boundaries suppose dey (this one relate to Domain-Driven Design, bounded contexts).
You get mature DevOps culture, CI/CD, monitoring, and container orchestration already in place or you dey ready to invest in am.

When Microservices No Dey Applicable

Small team, small product, early stage startup: If na 3-5 engineers, monolith go serve you well, na overhead you go dey add for nothing. Many senior engineers go tell you "start with monolith, split later when pain dey real."
Unclear domain boundaries: If you no sabi where one service suppose end and another suppose start, you go create "distributed monolith," wey be worst of both world, all the complexity of microservices but still tightly coupled.
No proper infrastructure/DevOps maturity: If you no get good CI/CD, container orchestration, monitoring, you go suffer well well trying to manage many services.
Tight deadline, need move fast: Monolith dey faster to build and iterate on early on, when requirement dey change every week.

Part 2: Micro-Frontends

Wetin Micro-Frontends Be

Micro-frontends na the same idea as microservices, but for frontend/UI layer. Instead of one giant frontend app (like one huge React or Angular app wey handle everything: dashboard, checkout, profile, admin), you break the frontend into smaller, independently deployable pieces, and each piece fit own by different team, even use different framework if necessary.

Imagine Amazon website: the search bar, product recommendation, cart, checkout, all of dem fit dey built and deployed by different teams, but as user, you dey see one seamless website.

Why Micro-Frontends Come Dey Exist

As backend don dey split into microservices, frontend teams still dey stuck maintaining one giant monolithic frontend, and dem still get similar wahala as backend monolith used to get:

One giant frontend codebase, everybody dey step on each other toes.
Slow build times as the app grow (webpack build wey take 10 minutes).
Hard to do independent releases, if one team wan ship dem feature, dem go wait for the whole app release train.
Tech stack lock-in, if the whole app dey React, one team wey wan try new tool no fit do am easily.

Types / Approaches to Micro-Frontends

Build-time Integration: Each micro-frontend dey published as npm package, and the main "shell" app import dem as dependencies during build. Simple but e mean say you no fit deploy independently at runtime, you still need rebuild the shell.
Run-time Integration via iframes: Old-school but effective way to isolate micro-frontends completely, each dey inside im own iframe. Strong isolation (CSS/JS no go clash), but bad for UX (routing, shared state, accessibility, SEO all suffer).
Run-time Integration via JavaScript (Module Federation): Webpack 5's Module Federation na the modern popular approach. Different apps fit dynamically load code from each other at runtime, without bundling everything together at build time. This one dey allow true independent deployment.
Web Components: Each micro-frontend dey exposed as custom element (using native Web Components API), and the shell app fit just drop <checkout-widget></checkout-widget> anywhere, framework-agnostic.
Server-Side Composition / Edge-Side Includes (ESI): The server (or CDN edge) dey stitch together HTML fragments from different services before e reach the browser. Companies like Amazon and IKEA don use variants of this one.
Single-SPA framework: A popular meta-framework wey dey orchestrate multiple frontend apps (React, Vue, Angular) to coexist inside one page, handling routing and lifecycle.

Advantages of Micro-Frontends

Independent deployment: Team fit ship dem part of the UI without waiting for other teams or full app redeploy.
Technology diversity: Different teams fit use different framework (though in practice, too much diversity fit cause bundle size wahala, so many companies still dey standardize on one framework even with micro-frontends).
Team autonomy and ownership: Just like microservices, small team fit own one vertical slice of the product end-to-end, from UI to backend.
Incremental upgrades: You fit migrate one old jQuery/Angular.js section to React small small, without doing one big-bang rewrite of the entire app. This one big advantage for legacy modernization.
Isolated failures: If one micro-frontend crash (say the recommendation widget), in theory the rest of the page fit still function, depending on how you implement error boundaries.
Scalable teams: As company grow from 10 to 200 frontend engineers, micro-frontend dey allow you scale organizationally without everybody dey fight for the same repo.

Disadvantages

Increased complexity: Just like microservices, you dey trade simple monolith wahala for distributed system wahala, but now for the frontend, wey plenty engineers no dey used to think about that way.
Bundle size / performance issues: If care no dey taken, you go end up shipping duplicate dependencies (like two versions of React) to the browser, wey go bloat load time and hurt performance.
Inconsistent UX: If teams no coordinate well, users go see inconsistent design, spacing, button styles, interaction pattern across different parts of the same product. You need strong design system (shared component library) to fight this.
Shared state management wahala: How two independently deployed micro-frontends go share state (like logged-in user info, shopping cart) without tight coupling? This one dey genuinely hard, and solutions dey range from custom events, shared global store, to URL-based state.
Routing complexity: Coordinating routing across multiple apps wey dey owned by different teams fit dey messy, especially with nested routes.
Testing and debugging complexity: End-to-end testing across micro-frontends dey harder, and debugging issue wey span multiple apps dey stressful.
CSS conflicts: Without proper isolation (CSS-in-JS, Shadow DOM, CSS modules), styles from one micro-frontend fit leak and clash with another.
Operational overhead: More repos, more CI/CD pipelines, more deployment targets to manage, na real cost for infrastructure and DevOps time.

When Micro-Frontends Dey Applicable

Large organization with multiple independent frontend teams wey dey step on each other for one giant codebase.
Legacy application wey need gradual, incremental modernization instead of risky big-bang rewrite.
Product wey get clearly separable domains for the UI (e.g., checkout flow vs admin dashboard vs marketing pages), where different teams naturally own different verticals.
Company wey don already adopt microservices for backend and wan mirror the same organizational boundary for frontend (Conway's Law: your system architecture go tend to mirror your organization structure).

When Micro-Frontends No Dey Applicable

Small team, small product: If e be 2-3 frontend engineers, one well-structured monolithic SPA with good folder structure and lazy loading go serve you well well. Micro-frontend go just add overhead wey no dey necessary.
Tight, fast-moving product where consistency matter pass independence: If the priority na fast iteration with one unified UX (like early-stage startup MVP), micro-frontend go slow you down.
Team no get discipline around design system / shared standards: Without governance, micro-frontend go quickly turn to "frankenstein UI" wey no gel together.
Performance-critical apps where every kilobyte matter: Micro-frontends fit introduce duplicate dependencies and extra runtime orchestration overhead wey fit hurt Core Web Vitals if not managed carefully.

Part 3: How Microservices and Micro-Frontends Relate

Though na two different layer (backend vs frontend), dem share the same underlying philosophy:

Both na about decomposition: Breaking big monolithic system into smaller, independently ownable, independently deployable pieces.
Both dey follow Conway's Law: "Organizations design systems that mirror their own communication structure." If your company get five independent teams, na natural say your architecture (backend and frontend) go eventually reflect that structure.
Both trade simplicity for scalability (organizational and technical): You dey pay complexity tax upfront to gain team autonomy and independent scaling/deployment later.
Both need strong platform/tooling investment: CI/CD, observability, service mesh (backend) or module federation/design system (frontend), none of this one dey free, e need engineering investment.
BFF (Backend for Frontend) pattern dey bridge both: Many companies dey pair each micro-frontend team with dem own BFF service, so the vertical slice (UI + backend) dey owned end-to-end by one team, wey be one of the cleanest way to organize both patterns together.

Part 4: Key Nuances Wey Every Software Engineer Suppose Sabi

Microservices no be about size, na about boundaries: The mistake plenty team dey make na to think "micro" mean "small lines of code." Na wrong. E dey about clear business boundary (bounded context), not line count. You fit get one "microservice" wey get 10,000 lines because e own a complex domain, and dat one dey fine.
"Distributed Monolith" na the silent killer: If your services dey too tightly coupled (they must always deploy together, dem share database, dem dey call each other synchronously in long chains), you don build distributed monolith, wey combine the wahala of monolith AND microservices together. Worst of both world.
Start with Monolith First (Monolith-First approach): Many respected engineers (including Martin Fowler) don argue say you suppose start new project as monolith, and only split to microservices when you clearly sabi your domain boundaries and you dey feel real pain from the monolith. Premature microservices na expensive mistake.
Team topology matter well well: Conway's Law mean say if you wan successful microservices/micro-frontend architecture, you need align your team structure to match, small autonomous "two-pizza teams" wey each own one vertical slice.
Observability na not optional: Once you split into many services, you MUST invest in centralized logging, distributed tracing, and metrics/dashboards, or you go dey fly blind when something break.
Micro-frontend no automatically mean "use different framework everywhere": In practice, most successful micro-frontend implementations still standardize on one main framework, and only allow diversity for special cases (like migrating legacy code). Too much framework diversity go bloat bundle size and hurt performance.
Database per service dey non-negotiable for "true" microservices: If services dey share one database, you don create tight coupling through the data layer, and you don lose one of the biggest advantage of microservices, which be independent evolution of each service's data model.

Conclusion

Both Microservices and Micro-Frontends dey solve real organizational and technical problems, but dem no be silver bullet. Dem dey shine when your team and product don grow big sotey monolith dey cause real pain: slow deployment, team coordination bottleneck, scaling mismatch. But if you dey early stage, small team, or your domain boundaries no really clear yet, adopting either one too early go just give you complexity wey no really get corresponding benefit.

As software engineer, the real skill no be to sabi "how to build microservices" or "how to build micro-frontends." Na to sabi when to use am, when NOT to use am, and how to migrate incrementally (Strangler Fig pattern) instead of doing risky big-bang rewrite. Architecture na trade-off business, no be trend wey you dey follow because Netflix or Amazon dey use am, dem get different scale, different team size, different problem from wetin you get.

Choose your architecture based on your actual pain points, no be based on wetin dey trend for Twitter/X or LinkedIn.

Happy reading. Cheers🥂!

Flex & Grid - CSS Most Powerful Layout Systems.

Tech In Vernacular — Mon, 22 Jun 2026 10:13:02 +0000

This post na about CSS most powerful layout systems and e go long small, as I go try touch touch most of the important basics.

I been reason to write about this one onto say many many devs dey mostly confuse as per which one dem suppose use, where dem suppose use them and how dem go use them, or even if dem fit join them use. By the time wey you don digest this post finish, I hope say e go don clear for you. Oya make we burst enter am...!

Introduction & Why They Matter

Before CSS Flexbox and Grid, web devs been dey build layout using a collection of hacks: float, inline-blocks, table-display tricks, con still turn prayer warrior, pad am with prayer make everything for no scatter. But all these tools ba, their body no full for application layout, na document layout dem dey for, so friction dey steady dey dey, the layout no really dey smooth. To center element vertically fit take lines of code and constant Stack Overflow.

Now, when Flexbox first burst in around 2012, e come as a genuine layout tool - one-dimensional, flow-based and designed for aligning things for inside container. Grid follow am like 5 years later, for 2017, e carry two-dimensional layout control join body come. These two no only just improve CSS, dem replace the entire paradigm.

Understanding both systems in toto na one skill wey frontend developer fit to steady dey leverage on. Nearly every modern interface - navigation bars, card grids, dashboards, modals, sidebars - dey built with one, the other or both of them join together. Two of them gather dey work together through mama - pikin relationship: you go declare the kain layout mode on top the container (the mama) and na that one go determine how the pikin them go take arrange. Normally, nothing concern another man pikin for this arrangement/layout matter, na strictly family business except if dem call am join.

Before them born dem two (Flexbox and Grid), developers been dey use float wey dem suppose dey use wrap text around images, dem dey use am build columns. Dem go con dey use am with some other guys like clear and overflow: hidden make e for just work, position: absolute dey even comot elements from flow patapata, to get responsive design that time na real war, especially if you no add JavaScript. This kain thing been dey go on for over a decade. So, when Flexbox and Grid enter field, dem no just be any kain average players wey dem wan take boost squad, na galacticos dem be. The industry hand finally hammer confam tools.

CSS FLEXBOX: The One-Dimensional Layout System

Flexbox ehn, na pure layout module wey dem dey use distribute space and align items along a single axis at a time. That axis fit con be horizontal (row) or vertical (column), but e no fit be the two simultaneously. Na this single constraint separate am from Grid.

Even though say na one-way im be, Flexbox na oga for im own lane: dem dey take am dey align navigation items, center content for container, share space between elements, or take build component-level layout like cards and button groups.

To activate Flexbox, we go simply set display: flex or display: inline-flex for on top container element. That single declaration na im go transform the element into flex container, and all im direct pikin go automatically become flex items.

/* Native CSS */
/* Container element */
.container {
  display: flex  /* or inline-flex */
}

/* TailwindCSS */
class="flex "

The moment wey you write display: flex for container like this, three things ghas happen dole: the pikin go arrange "on a straight line" for row (flex-direction: row), the pikin no go enter new line (flex-wrap: nowrap), and the pikin go stretch make their hand for touch their mama head (fill the height).

Flex Container Properties

Na these properties na im dey control the mama and all im pikin as family. Dem be the axes, alignment rules, wrapping behavior, and distribution logic.

flex-direction

This one na e define the main axis - the direction wey the pikin go arrange.

/* Native CSS */
.container {
  flex-direction: row;  /* default: left to right */
  flex-direction: row-reverse;  /* right to left */
  flex-direction: column;  /* top to bottom */
  flex-direction: column-reverse;  /* bottom to top */
}

/* TailwindCSS */
class="flex flex-col flex-row(default) flex-row-reverse flex-col-reverse"

justify-content

This one na how the pikin dem go take align for the main axis. Mainly, na im go determine how dem go take share the space wey remain.

/* Native CSS */
.container {
  justify-content: flex-start;  /* [OOO   ] */
  justify-content: flex-end;  /* [   OOO] */
  justify-content: center;  /* [  OOO  ] */
  justify-content: space-between;  /* [O  O  O] */
  justify-content: space-around;  /* [ O  O  O ] */
  justify-content: space-evenly;  /* [  O  O  O  ]*/
}

/* TailwindCSS */
class="justify-start justify-end justify-center justify-between justify-around justify-evenly"

align-items

This one na im cross the main axis (opposite of the flex-direction). So, if your flex na horizontal, na this one go control the vertical and vice versa.

/* Native CSS */
.container {
  align-items: stretch;  /* default: items fill cross axis height*/
  align-items: flex-start;  /* align to cross-start edge */
  align-items: flex-end;  /* align to cross-end edge */
  align-items: center;  /* center on cross axis */
  align-items: baseline;  /* align to baseline */
}

/* TailwindCSS */
class="items-stretch items-start items-end items-center items-baseline"

flex-wrap

By default, all the pikin go squeeze for one line. flex-wrap: wrap na im go tell them or give them the go ahead make dem enter new line if space no dey or e don dey too long. This one dey useful for responsive layouts.

/* Native CSS */
.container {
  flex-wrap: nowrap;  /* default: no wrap, may overflow */
  flex-wrap: wrap;  /* wrap to new lines, top to bottom */
  flex-wrap: wrap-reverse;  /* wrap to new lines, bottom to top */
}

/* shorthand for direction and wrap together */
.container {
  flex-flow: row wrap;
  flex-flow: column nowrap;
}

/* TailwindCSS */
class="flex-wrap flex-nowrap flex-wrap-reverse"

align-content

if you get may lines unto say the pikin dem dey fall enter another line, na this one go control how dem go take align for the new line for the cross axis. This one no get mouth at all assuming say dem no fall enter new line.

/* Native CSS */
.container {
  flex-wrap: wrap;  /* must wrap for align-content to work */
  align-content: stretch;  /* default */
  align-content: flex-start;
  align-content: flex-end;
  align-content: center;
  align-content: space-between;
  align-content: space-around;
  align-content: space-evenly;
  align-content: normal;
  align-content: baseline;
}

/*  TailwindCSS */
class="flex-wrap content-normal content-stretch content-center content-start content-end content-baseline content-between content-evenly content-around "

gap

This one na im create space between the pikin make dem for see place breathe. This na the preferred way to keep space between pikin dem, no margin, no nothing.

/* Native CSS */
.container {
  display: flex;
  gap: 1rem;  /* equal row and column gap */
  gap: 1rem 2rem;  /* row-gap column-gap */
  row-gap: 2rem;  /* only horizontal */
  column-gap: 2rem;  /* only vertical */
}

/* TailwindCSS */
class="flex gap-2 gap-x-4 gap-y-4"

Flex Item Properties

While container properties dey control the group, na item properties na im dey in charge of individual items, so dem go fit control their own sizing, order and alignment - overriding the container's defaults for that specific element.

flex-grow, flex-shrink, flex-basis

Na these three musketeers dey determine how pikin dem dey size demsef.

/* Native CSS */
.item {
  /* flex-grow : how much to grow relative to siblings */
  flex-grow: 0;  /* default: don't grow */
  flex-grow: 1;  /* grow to fill available space */

  /* flex-shrink : how much to shrink if needed */
  flex-shrink: 1;  /* default: shrink proportionately */
  flex-shrink: 0;  /* don't shrink */

  /* flex-basis : the starting size before grow/shrink */
  flex-basis: auto;  /* default: use content width */
  flex-basis: 200px;  /* start at 200px, then adjust */
  flex-basis: 0;  /* start from 0, all growth from flex-grow */
}

/* shorthand - flex: grow shrink basis */
.item {
  flex: 1;  /* flex: 1 1 0%; most common for equal-width items */
  flex: auto;  /* flex: 1 1 auto */
  flex: none;  /* flex: 0 0 auto; rigid, no grow or shrink */
  flex: 0 0 200px;  /* fixed 200px, no grow, no shrink */
}

/* TailwindCSS */
class="flex flex-grow shrink(flex-shrink: 1) shrink-0 basis-full basis-auto basis-sm basis-md basis-xl basis-1"

align-self

This one dey allow make one pikin position imsef as im like. This one go override align-items for that pikin only.

/* Native CSS */
.item {
  align-self: flex-start;  /* override: hug top */
  align-self: flex-end;  /* override: hug bottom */
  align-self: center;  /* override: vertically center */
  align-self: auto;  /* default: uses align-items value */
}

/* TailwindCSS */
class="self-start self-end self-center self-auto self-stretch self-baseline"

BONUS

To center an item

/* Native CSS */
.center-container {
  display: flex;
  justify-content: center; /* horizontal */
  align-items: center;    /* vertical */
  min-height: 100vh;       /* fill viewport */
}

/* TailwindCSS */
class="flex justify-center items-center"

CSS GRID: The Two-Dimensional Layout System

CSS Grid na the first CSS module wey dem design explicitly for two-dimensional layouts — rows and columns at the same time. As Flexbox dey wey im dey handle one axis, Grid dey handle the entire spatial plane. You go just define tracks, and items fit spread, collect multiple tracks for either direction.

Grid na the right tool for the general layout of a page: where the header, main content, sidebar, and footer dey gather live in relation to each other. Na im still be excellent option for image galleries, dashboards, and any pattern where item placement for both dimensions matters.

Activating Grid

/* Native CSS */
.container {
  display: grid; /* or inline-grid */
}

/* TaiwindCSS */
class="grid "

/*
  Without defining columns/rows, items stack vertically
  by default — one per row, full width.
*/

Grid Container Properties

`grid-template-columns` & `grid-template-rows`

Na these properties dem dey take define the track sizes — the widths of columns and heights of rows.

/* Native CSS */
.grid {
  display: grid;

  /* Fixed pixels */
  grid-template-columns: 200px 200px 200px;

  /* Fractional units — the fr unit */
  grid-template-columns: 1fr 1fr 1fr;    /* 3 equal columns */
  grid-template-columns: 2fr 1fr;        /* 2/3 and 1/3 */
  grid-template-columns: 300px 1fr 1fr;  /* fixed sidebar, 2 equal cols */

  /* repeat() — shorthand for repeated tracks */
  grid-template-columns: repeat(3, 1fr);      /* 1fr 1fr 1fr */
  grid-template-columns: repeat(4, 100px);    /* four 100px cols */

  /* minmax() — flexible range */
  grid-template-columns: repeat(3, minmax(200px, 1fr));

  /* Row heights */
  grid-template-rows: 80px auto 60px; /* header, content, footer */
  grid-template-rows: repeat(3, 150px);
}

/* TailwindCSS */
class="grid grid-cols-<number> grid-cols-[100px_minmax(200px,_1fr)_100px] grid-rows-6  "

The `fr` Unit

The fr (fraction) unit na im represent a fraction of the space wey remain for inside the grid container, after dem comot any track wey dem declare e size. Na wetin make am dey fundamentally different from percentages be that, as per say that one no dey regard gaps, e no send.

/* Native CSS */
.grid {
  display: grid;
  gap: 1rem;

  /* 1. Three equal columns */
  grid-template-columns: repeat(3, 1fr);

  /* 2. Sidebar + main content */
  grid-template-columns: 250px 1fr;

  /* 3. Middle column twice as wide */
  grid-template-columns: 1fr 2fr 1fr;
}

/* TailwindCSS */
class="grid gap-4 grid-cols-3 grid-cols-[1fr_2fr_1fr]"

`auto-fill` and `auto-fit`

Na these keywords we dey use with repeat() to create grids wey really dey responsive without say we declare any media queries.

/* Native CSS*/
.responsive-grid {
  display: grid;
  gap: 1rem;

  /*
    auto-fill: creates as many tracks as fit,
    even if they're empty
  */
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));

  /*
    auto-fit: creates as many tracks as fit,
    but collapses empty tracks to 0 width.
    Items stretch to fill remaining space.
  */
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
}

/*
  auto-fit is usually what you want for card grids.
  With 2 items in a 4-column layout:
  - auto-fill: items are 200px, then empty columns remain
  - auto-fit: items grow to fill the entire row
*/

/* TailwindCSS */
class="grid gap-4 grid-cols-[repeat(auto-fill,minmax(200px,1fr))]"

`grid-template-areas`

This na one of the features wey Grid get wey others no get: we fit give regions for the layout names, con dey use those names dey assign them items.

.page {
  display: grid;
  grid-template-areas:
    "header header header"
    "nav    main   aside"
    "footer footer footer";
  grid-template-columns: 200px 1fr 160px;
  grid-template-rows: 80px 1fr 60px;
  min-height: 100vh;
  gap: 1rem;
}

header { grid-area: header; }
nav    { grid-area: nav;    }
main   { grid-area: main;   }
aside  { grid-area: aside;  }
footer { grid-area: footer; }

/* Responsive: rearrange areas at small screens */
@media (max-width: 768px) {
  .page {
    grid-template-areas:
      "header"
      "nav"
      "main"
      "aside"
      "footer";
    grid-template-columns: 1fr;
  }
}

Alignment Properties

/* Native CSS */
.grid {
  /* Aligns items on the BLOCK (vertical) axis within cells */
  align-items: start | end | center | stretch;

  /* Aligns items on the INLINE (horizontal) axis within cells */
  justify-items: start | end | center | stretch;

  /* Shorthand: align-items + justify-items */
  place-items: center;          /* both centered */
  place-items: start end;       /* block-axis inline-axis */

  /* Aligning the entire grid within its container */
  align-content: center;
  justify-content: center;
  place-content: center;
}

/* TailwindCSS */
class="grid items-center justify-items-start place-items-end content-center place-content-center"

Grid Placement & Spanning

Unlike Flexbox, where items dey follow one particular order, Grid allow you make you place items for anywhere inside the grid — out of order, overlapping, or say you wan spread am across multiple cells in any direction.

`grid-column` and `grid-row`

All these shorthand properties so, na dem specify where individual item fit start and where e fit end using grid line numbers. The lines dey numbered from 1 at the start of the grid go like that till the last line.

/* Native CSS */
/* Grid with 4 columns creates lines 1, 2, 3, 4, 5 */
.item {
  grid-column: 1 / 3;      /* start at line 1, end at line 3 (spans 2 cols) */
  grid-column: 2 / -1;     /* from line 2 to last line */
  grid-column: 1 / span 2; /* start at 1, span 2 columns */
  grid-column: span 3;     /* span 3 cols from auto placement */

  grid-row: 1 / 3;         /* span 2 rows */
  grid-row: span 2;        /* span 2 rows from current position */
}

/* Individual properties */
.item {
  grid-column-start: 1;
  grid-column-end: 4;
  grid-row-start: 2;
  grid-row-end: 4;
}

/* TailwindCSS */
class="grid col-span-2 col-span-auto col-start-auto col-span-full col-end-3 row-auto row-span-5 row-span-full row-span-auto row-end-5 "

Negative Line Numbers

You fit even arrange Grid lines from the back using negative numbers. -1 go be the last line and so on.

/* Native CSS */
.full-width {
  grid-column: 1 / -1; /* always spans full width */
}

.right-two {
  grid-column: -3 / -1; /* last two columns, always */
}

/* TailwindCSS */
class="col-start-1 col-end-[-1]"

Named Grid Lines

/* Native CSS */
.grid {
  grid-template-columns:
    [sidebar-start] 250px [sidebar-end content-start] 1fr [content-end];
}

.sidebar { grid-column: sidebar-start / sidebar-end; }
.content { grid-column: content-start / content-end; }

/* TailwindCSS */
class="grid [grid-template-columns:[sidebar]_200px_[content]_1fr_[ads]_150px]"

class="[grid-column:sidebar] [grid-column:content]"

Grid Auto Placement & `dense`

/* Native CSS */
.grid {
  grid-auto-flow: row;        /* default — fills rows first */
  grid-auto-flow: column;     /* fills columns first */
  grid-auto-flow: row dense;  /* backfills gaps — great for masonry-like layouts */
}

/* Size for implicitly created tracks */
.grid {
  grid-auto-rows: 200px;
  grid-auto-rows: minmax(100px, auto);
  grid-auto-columns: 1fr;
}

/* TailwindCSS */
class="grid-flow-row grid-flow-col grid-flow-col-dense"

Advanced Grid Techniques

Overlapping Items

Grid items fit to share the same cell(s) to create layered compositions. We go con use z-index take control how dem go take stack over each other.

/* Native CSS */
.grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: repeat(3, 100px);
}

/* Background image spans full grid */
.bg-image {
  grid-column: 1 / -1;
  grid-row: 1 / -1;
  z-index: 1;
}

/* Text content placed over the image */
.overlay-text {
  grid-column: 2 / 4;
  grid-row: 2 / 3;
  z-index: 2;
}

/* TailwindCSS */
class="grid grid-cols-4 grid-rows-3 "
class="col-span-1 row-span-1 z-10"
class="col-span-3 row-span-2 z-20"

Subgrid

Subgrid (widely supported since 2023) dey allow make grid item wey be say imself na grid container on e own, to align to im parent tracks, which means e allow the pikin make e inherit im mama columns or rows. This method na the solution to the long-standing problem of grid wey dey inside another grid wey no con fit align to im grandparent columns.

N.B: dey careful with am, e never dey fully supported for Chrome as at when I dey write this post.

/* Native CSS */
.parent-grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1rem;
}

/* A card that spans 3 columns and uses subgrid for its children */
.card {
  grid-column: span 3;
  display: grid;
  grid-template-columns: subgrid; /* inherit parent's column tracks */
}

/* Card children now align to parent grid columns */
.card-icon  { grid-column: 1; }
.card-title { grid-column: 2; }
.card-meta  { grid-column: 3; }

/* TailwindCSS */
class="grid grid-cols-3 "
class="grid grid-cols-subgrid col-span-2 "

Flexbox & Grid Working Together

Flexbox and Grid no be competitors. Both of them dey solve different problems and dem dey very powerful if dem join hand together. The normal pattern na: Grid for macro layout, Flexbox for micro layout.

Use Flexbox for...	Use Grid for...
Navigation bars	Page shell layouts
Button groups	Dashboard layouts
Card content alignment	Image galleries
Centering a single element	Magazine layouts
Toolbars and tag lists	Complex form grids
Horizontal scrolling strips	Any 2D layout problem

Classic Combination: Page Shell + Component Layout

/* ── OUTER: Grid for page layout ── */
body {
  display: grid;
  grid-template-areas:
    "header"
    "main"
    "footer";
  grid-template-rows: auto 1fr auto;
  min-height: 100vh;
}

/* ── HEADER: Flex for nav layout ── */
header {
  grid-area: header;
  display: flex;
  align-items: center;
  justify-content: space-between;
  padding: 1rem 2rem;
}

/* ── MAIN: Grid for content area ── */
main {
  grid-area: main;
  display: grid;
  grid-template-columns: 1fr 300px;
  gap: 2rem;
  padding: 2rem;
}

/* ── CARD GRID: Grid for cards ── */
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 1.5rem;
}

/* ── CARD: Flex for card internals ── */
.card {
  display: flex;
  flex-direction: column;
}

.card-body {
  flex: 1; /* push button to bottom */
}

/* ── FOOTER: Flex for footer content ── */
footer {
  grid-area: footer;
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 1.5rem 2rem;
}

The outer page na Grid. Each grid area con get Flex containers for internal alignment. Inside each card, flex-direction: column and flex: 1 wey dey their body dey make sure say the action button go always align for the bottom — regardless of content length.

Real-World Layout Patterns

Pattern 1: Responsive Sidebar Layout

.layout {
  display: grid;
  grid-template-columns: minmax(200px, 260px) 1fr;
  gap: 2rem;
  min-height: 100vh;
}

@media (max-width: 768px) {
  .layout {
    grid-template-columns: 1fr; /* sidebar stacks above content */
  }
}

Pattern 2: 12-Column Dashboard Grid

.dashboard {
  display: grid;
  grid-template-columns: repeat(12, 1fr);
  grid-auto-rows: minmax(100px, auto);
  gap: 1rem;
}

.stat-card   { grid-column: span 3; }  /* 4 across */
.chart-main  { grid-column: span 8; }  /* large chart */
.chart-small { grid-column: span 4; }  /* small chart */
.data-table  { grid-column: span 12; } /* full width */

/* Stat card internal layout — Flex */
.stat-card {
  display: flex;
  align-items: center;
  gap: 1rem;
  padding: 1.5rem;
}

@media (max-width: 768px) {
  .stat-card,
  .chart-main,
  .chart-small {
    grid-column: span 12;
  }
}

Pattern 3: Auto-Responsive Card Gallery (No Media Queries)

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 280px), 1fr));
  gap: 1rem;
}
/*
  Adapts from 1 column on mobile to as many as fit,
  never below 280px wide, all equal width — no breakpoints.
*/

Pattern 4: The Pancake Stack

.pancake {
  display: grid;
  grid-template-rows: auto 1fr auto;
  min-height: 100vh;
}
/*
  Header and footer are natural height.
  Main content grows to fill remaining space.
*/

Pattern 5: Pseudo-Masonry with `dense`

.masonry {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  grid-auto-rows: 50px;
  grid-auto-flow: dense; /* fill gaps */
  gap: 0.5rem;
}

.tall  { grid-row: span 4; }
.short { grid-row: span 2; }
.wide  { grid-column: span 2; }

/*
  Note: true masonry is in the CSS spec as
  grid-template-rows: masonry
  but browser support is currently limited.
*/

Tailwind CSS Reference

Tailwind Flexbox Classes

<!-- Display -->
<div class="flex">         <!-- display: flex -->
<div class="inline-flex">  <!-- display: inline-flex -->

<!-- flex-direction -->
class="flex-row"            <!-- flex-direction: row (default) -->
class="flex-row-reverse"    <!-- flex-direction: row-reverse -->
class="flex-col"            <!-- flex-direction: column -->
class="flex-col-reverse"    <!-- flex-direction: column-reverse -->

<!-- flex-wrap -->
class="flex-wrap"           <!-- flex-wrap: wrap -->
class="flex-nowrap"         <!-- flex-wrap: nowrap -->
class="flex-wrap-reverse"   <!-- flex-wrap: wrap-reverse -->

<!-- justify-content -->
class="justify-start"       <!-- justify-content: flex-start -->
class="justify-end"         <!-- justify-content: flex-end -->
class="justify-center"      <!-- justify-content: center -->
class="justify-between"     <!-- justify-content: space-between -->
class="justify-around"      <!-- justify-content: space-around -->
class="justify-evenly"      <!-- justify-content: space-evenly -->

<!-- align-items -->
class="items-start"         <!-- align-items: flex-start -->
class="items-end"           <!-- align-items: flex-end -->
class="items-center"        <!-- align-items: center -->
class="items-baseline"      <!-- align-items: baseline -->
class="items-stretch"       <!-- align-items: stretch -->

<!-- align-content (multi-line) -->
class="content-center"      <!-- align-content: center -->
class="content-between"     <!-- align-content: space-between -->

<!-- Item properties -->
class="flex-1"              <!-- flex: 1 1 0% -->
class="flex-auto"           <!-- flex: 1 1 auto -->
class="flex-none"           <!-- flex: none -->
class="grow"                <!-- flex-grow: 1 -->
class="grow-0"              <!-- flex-grow: 0 -->
class="shrink"              <!-- flex-shrink: 1 -->
class="shrink-0"            <!-- flex-shrink: 0 -->
class="basis-1/3"           <!-- flex-basis: 33.333% -->
class="self-center"         <!-- align-self: center -->
class="order-first"         <!-- order: -9999 -->
class="order-last"          <!-- order: 9999 -->
class="order-3"             <!-- order: 3 -->

<!-- Gap -->
class="gap-4"               <!-- gap: 1rem -->
class="gap-x-4"             <!-- column-gap: 1rem -->
class="gap-y-2"             <!-- row-gap: 0.5rem -->

Tailwind Flexbox Examples

<!-- Navbar: logo left, links center, button right -->
<nav class="flex items-center justify-between px-8 py-4">
  <a class="font-bold text-xl">Brand</a>
  <ul class="flex gap-6">
    <li><a>Home</a></li>
    <li><a>About</a></li>
  </ul>
  <button class="ml-auto bg-blue-600 text-white px-4 py-2 rounded">
    Sign Up
  </button>
</nav>

<!-- Card with flex-col to push button to bottom -->
<div class="flex flex-col h-full p-4 border rounded">
  <h3 class="text-lg font-semibold mb-2">Card Title</h3>
  <p class="flex-1 text-gray-600">Card body content...</p>
  <button class="mt-4 bg-red-500 text-white px-3 py-1.5 text-sm">
    Read More
  </button>
</div>

<!-- Perfect centering -->
<div class="flex items-center justify-center min-h-screen">
  <div>Centered content</div>
</div>

<!-- Sticky footer -->
<body class="flex flex-col min-h-screen">
  <header>...</header>
  <main class="flex-1">...</main>
  <footer>...</footer>
</body>

Tailwind Grid Classes

<!-- Display -->
class="grid"                  <!-- display: grid -->
class="inline-grid"           <!-- display: inline-grid -->

<!-- grid-template-columns -->
class="grid-cols-1"           <!-- repeat(1, minmax(0,1fr)) -->
class="grid-cols-2"           <!-- repeat(2, minmax(0,1fr)) -->
class="grid-cols-3"           <!-- repeat(3, minmax(0,1fr)) -->
class="grid-cols-12"          <!-- 12-column grid -->
class="grid-cols-none"        <!-- no predefined columns -->

<!-- grid-template-rows -->
class="grid-rows-3"           <!-- 3 equal rows -->
class="grid-rows-none"        <!-- auto rows -->

<!-- Column/Row spanning -->
class="col-span-1"            <!-- grid-column: span 1 -->
class="col-span-2"            <!-- grid-column: span 2 -->
class="col-span-full"         <!-- grid-column: 1 / -1 -->
class="row-span-2"            <!-- grid-row: span 2 -->
class="row-span-full"         <!-- grid-row: 1 / -1 -->

<!-- Column/Row start and end -->
class="col-start-1"           <!-- grid-column-start: 1 -->
class="col-end-4"             <!-- grid-column-end: 4 -->
class="row-start-2"           <!-- grid-row-start: 2 -->

<!-- Alignment -->
class="justify-items-center"  <!-- justify-items: center -->
class="items-center"          <!-- align-items: center -->
class="place-items-center"    <!-- place-items: center -->
class="place-content-center"  <!-- place-content: center -->
class="justify-self-end"      <!-- justify-self: end -->

<!-- Auto flow -->
class="grid-flow-row"         <!-- grid-auto-flow: row -->
class="grid-flow-col"         <!-- grid-auto-flow: column -->
class="grid-flow-dense"       <!-- grid-auto-flow: dense -->
class="grid-flow-row-dense"   <!-- grid-auto-flow: row dense -->

Tailwind Grid Examples

<!-- Responsive card grid -->
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-4">
  <div class="...">Card</div>
  <!-- more cards -->
</div>

<!-- 12-column dashboard -->
<div class="grid grid-cols-12 gap-4">
  <div class="col-span-12 md:col-span-3">Sidebar</div>
  <div class="col-span-12 md:col-span-9">Main</div>
</div>

<!-- Feature article: full-width hero + 3 cols below -->
<div class="grid grid-cols-3 gap-4">
  <div class="col-span-full bg-slate-100 h-48">Hero</div>
  <div>Story 1</div>
  <div>Story 2</div>
  <div>Story 3</div>
</div>

<!-- Custom column sizes with arbitrary values -->
<div class="grid [grid-template-columns:250px_1fr] gap-6">
  <aside>Sidebar</aside>
  <main>Content</main>
</div>

<!-- grid-template-areas with arbitrary values -->
<div class="grid
  [grid-template-areas:'header_header''nav_main''footer_footer']
  [grid-template-columns:200px_1fr]">
  <header class="[grid-area:header]">Header</header>
  <nav class="[grid-area:nav]">Nav</nav>
  <main class="[grid-area:main]">Main</main>
  <footer class="[grid-area:footer]">Footer</footer>
</div>

When to Use Which

Scenario	Flexbox	Grid
Navigation bar	Ideal	Overkill
Page shell layout	Possible but awkward	Ideal
Card grids	Works with wrapping	More precise control
Centering one element	2 lines of CSS	Works with `place-items`
Items of unknown count	`flex-wrap` handles it	`auto-fill/fit` also works
Items must align in 2 axes	One axis only	Native two-dimensional
Items overlapping	Not designed for this	Explicit placement allows overlap
Form label + input pairs	Row with `flex-wrap`	`grid-template-columns` aligns
Sidebar layout	Possible	More readable
Content-driven sizing	Items size to content	Possible with `min/max-content`
Complex magazine layout	Can't span rows	Built for this
Equal-height cards	`align-items: stretch`	Row tracks handle this
Sticky footer	`flex-col` + `flex:1` on main	`grid-rows: auto 1fr auto`

The Definitive Rule: If you get layout wey be say na one-dimensional (a row of things, or a column of things), just use Flexbox. If e con be say the layout need better control for both rows and columns simultaneously, or if you need make items spread for multiple rows or columns, carry Grid use. If you dey doubt am, say you be doubting Thomas, just use Grid for the outer structure and then use Flexbox for the inner components.

Pro Tips & Common Mistakes

Common Flexbox Mistakes

/* Mistake: using margin instead of gap */
.container { display: flex; }
.item { margin-right: 1rem; } /* last item go get extra margin */

/* Fix: Use gap */
.container { display: flex; gap: 1rem; }


/* Mistake: You go dey expect say flex go work on grandchildren */
.parent { display: flex; }
.child { }        /* flex item */
.grandchild { }   /* Not a flex item */

/* Fix: Make .child a flex container too if e really need am */
.child { display: flex; }


/* Mistake: align-items vs align-content confusion */
.container {
  flex-wrap: wrap;
  align-items: center;   /* centers items within each row */
  align-content: center; /* centers all rows in the container */
  /* If you wan wrap, then both of them dey needed for full vertical centering */
}


/* Mistake: Text dey overflow im flex item */
.text-item { flex: 1; }

/* Fix: flex items dey get min-width:auto by default */
.text-item { flex: 1; min-width: 0; overflow: hidden; }

Common Grid Mistakes

/* Mistake: Using % instead of fr (% no dey consider gap) */
.grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: 33.33% 33.33% 33.33%;
}

/* Fix: Use fr */
.grid { grid-template-columns: 1fr 1fr 1fr; }


/* Mistake: Forgetting grid-auto-rows with auto-placement */
.grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  /* rows go default to height of content, most times na 0px */
}

/* Fix: Explicitly set row height */
.grid { grid-auto-rows: minmax(150px, auto); }


/* Mistake: Mismatched grid-area names */
.page {
  grid-template-areas:
    "header header"
    "sidebar main";
}
aside { grid-area: side; } /* "side" no match "sidebar" */

/* Fix: Names ghas match exactly */
aside { grid-area: sidebar; }

Pro Tips Worth Remembering

Tip	Detail
`gap` > `margin`	Always use `gap` for spacing between grid/flex children.
`min-width: 0`	When flex item get content wey dey pass im boundary, add `min-width: 0` so e go fit shrink properly.
`aspect-ratio` + Grid	Combine `aspect-ratio: 1` with Grid if you want image galleries wey go maintain proportions for any kain size.
`fr` over `%`	The `fr` unit dey share space after fixed tracks and gaps don dey accounted for. Percentage no send.
DevTools first	Chrome and Firefox get better Grid and Flex visualizers. Use them if you dey debug — dem go show line numbers, area names, and track sizes.
*`place-` shorthand**	`place-items: center` and `place-content: center` combine align + justify in one declaration.
Zero query responsive	Use `auto-fit/fill` with `minmax()` if you want card grids wey go adapt to any screen width. No need for media queries.
Don't force one tool	If e don dey be like say you dey force either of the system, you fit consider say na the wrong one you dey use. The right tool no go stress you, e go make am easy, con sweet you.

Final Thought: Mastering Flexbox and Grid no be about memorizing every property. The main thing na to always get which one you wan use for mind, and trust say once you don pick the right one, CSS go handle the remaining. Build things. Break am. Inspect am for DevTools. The layout systems for modern CSS use style sweet once you don enter inside am. Happy Styling!

Cheers!🥂

Hooks and State Management in Modern Frontend Frameworks

Tech In Vernacular — Tue, 09 Jun 2026 10:46:38 +0000

A complete beginner's guide to state management in React/Next.js, Vue/Nuxt, Angular, and Svelte

Before we start: wetin be "state" gan gan sef?

Imagine say you dey build light switch for a webpage. Normal normal, switch fit only dey ON/OFF. The value, that ON/OFF wey the app ghas remember and react to, yeah na the state be that.

State na any data wey fit:

change over time
cause make your UI dey update if e change.

A counter, a list of to-dos, whether a modal dey open or not, the currently logged-in user — all na state.

"State management" na simply how the framework allow make we store data, change am, and keep the UI in sync with the data.

Part 1: React & Next.js

React na the most widely used UI library for the world. Na im introduce the idea of hooks — wey be special functions wey we fit use plug into React own features (like state) from inside the component itself.

The golden rule of React hooks

Na must to always call hooks for the top level of your component — no be inside loops, conditions, or functions wey dey nested.

Na only inside React function components dem fit work (no class components, no plain JavaScript files).

`useState` — your first hook

Na the starting point for most developers be this. useState dey allow make we declare the state and function wey fit dey update am.

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0); // 0 na the starting value

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

Make we break am down:

count na the current value
setCount na the function wey we call to dey update the value
useState(0) set the starting value to 0
Every time wey we call setCount, React go re-render the component with the new value

`useEffect` — reacting to changes

Sometimes we fit wan do something when state change — like we fit wan fetch data when a user ID change, or make we wan update the title for a page when the name change. Na wetin useEffect dey for be that.

import { useState, useEffect } from "react";

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // This runs after the component renders
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, [userId]); // Only re-runs when userId changes

  if (!user) return <p>Loading...</p>;
  return <p>Hello, {user.name}!</p>;
}

The array wey we keep for the end of the function ([userId]) na im we dey call the dependency array. E dey tell React say: "re-run this effect only when userId don change."

Dependency array	Behaviour
`[]` (empty)	Runs once, on mount
`[value]`	Runs when `value` changes
No array at all	Runs after every render

`useContext` — sharing state without passing it everywhere

When many components need the same data (like the user wey dey logged-in or a theme), passing am as props through every level dey cause serious headache. Na wetin useContext carry dey solve be that.

import { createContext, useContext, useState } from "react";

// 1. Create the context
const ThemeContext = createContext("light");

// 2. Wrap your tree in a Provider
function App() {
  const [theme, setTheme] = useState("light");
  return (
    <ThemeContext.Provider value={theme}>
      <Toolbar />
      <button onClick={() => setTheme("dark")}>Toggle theme</button>
    </ThemeContext.Provider>
  );
}

// 3. Read am for anywhere inside the tree
function Toolbar() {
  const theme = useContext(ThemeContext);
  return <p>Current theme: {theme}</p>;
}

`useReducer` — when state gets complex

This one na for when we get many values/state wey from the same family or update logic wey no be soft work, the useReducer clean pass make we con dey manage many useState calls.

import { useReducer } from "react";

const initialState = { count: 0, step: 1 };

function reducer(state, action) {
  switch (action.type) {
    case "increment": return { ...state, count: state.count + state.step };
    case "reset":     return initialState;
    case "setStep":   return { ...state, step: action.payload };
    default:          return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      <p>Count: {state.count}</p>
      <button onClick={() => dispatch({ type: "increment" })}>+</button>
      <button onClick={() => dispatch({ type: "reset" })}>Reset</button>
    </div>
  );
}

Reason dispatch as regular dispatch rider wey dey deliver message ("increment!") and the reducer na the post office wey dey decide wetin to do with the message (as to how and where e dey go).

Performance hooks: `useMemo` and `useCallback`

These ones na optimisation hooks. No dey quick call them — only call them when your app don dey actually dey move slow.

import { useMemo, useCallback } from "react";

// useMemo: cache an expensive calculation
const sortedList = useMemo(
  () => [...items].sort((a, b) => a.name.localeCompare(b.name)),
  [items] // Only re-sort when items changes
);

// useCallback: cache a function so child components no go dey re-render unnecessarily
const handleClick = useCallback(() => {
  doSomething(id);
}, [id]);

New React 18+ hooks

React just dey evolve dey go. Some of the latest and most important additions:

useTransition — this one dey pend state update wey no dey urgent, so that the UI go dey respond dey go normally:

const [isPending, startTransition] = useTransition();

startTransition(() => {
  setSearchResults(heavyFilter(data, query)); // won't block typing
});

useId — e dey generate custom made 1-of-1 IDs (e dey useful for form labels wey dey accessible):

const id = useId();
<label htmlFor={id}>Name</label>
<input id={id} />

Custom hooks — na your secret weapon be this

You fit build your own hooks with React, con add the React's built-in hooks inside your own reusable hooks wey you been create. Normal normal, every hook wey you create ghas start with use, just like built-in hooks.

// useLocalStorage.js
function useLocalStorage(key, initialValue) {
  const [value, setValue] = useState(
    () => JSON.parse(localStorage.getItem(key)) ?? initialValue
  );

  const setStoredValue = (newValue) => {
    setValue(newValue);
    localStorage.setItem(key, JSON.stringify(newValue));
  };

  return [value, setStoredValue];
}

// Use am anywhere for your app
const [theme, setTheme] = useLocalStorage('theme', 'light');

State management beyond hooks: when you suppose use library

Built-in hooks no sad at all for local and mid-level state. For large apps, you go like use one of the following:

Library	Best for
Zustand	Simple global state, minimal boilerplate
Redux Toolkit	Large apps with complex state + devtools
Jotai / Recoil	Atomic state (fine-grained updates)
TanStack Query	Server/async data (caching, fetching, syncing)

Next.js specifics

Next.js na one powerful framework wey dem build on top React. One of the feature wey dem add wey make am loud pass na the server-side capability. The server-side features go change how you go reason about state:

React Server Components (RSC) dey run for server — you no fit use hooks like useState or useEffect inside them. Na data fetching and static content dem dey use these components for.
Client Components (marked with 'use client' at the top of the file) dey work exactly like regular React components, with full hook support.

// This na Server Component — no hooks allowed
export default async function ProductPage({ params }) {
  const product = await db.getProduct(params.id);
  return <ProductDetails product={product} />;
}

'use client'; // Now hooks go work

import { useState } from 'react';

export function AddToCartButton({ productId }) {
  const [added, setAdded] = useState(false);
  return (
    <button onClick={() => setAdded(true)}>
      {added ? 'Added!' : 'Add to Cart'}
    </button>
  );
}

The OT here: keep as many components as possible for the server (faster, no JavaScript sent to browser), so na only when you wan make the component dey interactive, na that time you fit con use client components.

Part 2: Vue & Nuxt

Vue carry different turning for the state roundabout. Instead of hooks, e dey use reactivity system — wey be the way wey Vue take dey declare data wey e go dey watch and e go automatically update the UI if e change.

Vue 3 con introduce the Composition API, wey wan use style do twinnie with React hooks based on their concept but some key differences still dey.

`ref` — reactive primitive values

<script setup>
  import { ref } from 'vue';

  const count = ref(0); // 0 na the starting value

  function increment() {
    count.value++; // for inside script, you go access the value via .value
  }
</script>

<template>
  <!-- For the template, Vue go automatically unwrap .value for you -->
  <p>Count: {{ count }}</p>
  <button @click="increment">Click me</button>
</template>

The .value thing dey make many beginners foh. Just dey remember say: inside that your <script>, you need .value. Inside your <template>, Vue go handle am for you, no worry.

`reactive` — reactive objects

When you get many values wey dem be family, reactive give you chance make you keep all together inside one object so you no need worry about .value:

<script setup>
  import { reactive } from 'vue';

  const user = reactive({
    name: 'Alice',
    age: 30,
    isLoggedIn: false,
  });

  function login() {
    user.isLoggedIn = true; // Directly mutate — Vue go track am automatically
  }
</script>

<template>
  <p>{{ user.name }}, logged in: {{ user.isLoggedIn }}</p>
  <button @click="login">Log in</button>
</template>

ref vs reactive: which one to use?

Use `ref` for...	Use `reactive` for...
Single values (string, number, boolean)	Groups of related values (objects, forms)
Values wey you fit replace entirely	Values wey you wan mutate in place

Many many oga oga devs for Vue now don dey use ref for everything just for consistency — and e dey work for objects too.

`computed` — derived values

computed na Vue's version of useMemo wey dey React, but this one clean pass am. You no need tell am too much, e go automatically track e own dependencies.

<script setup>
  import { ref, computed } from 'vue';

  const firstName = ref('Jane');
  const lastName = ref('Doe');

  // Automatically recalculates when firstName or lastName changes
  const fullName = computed(() => `${firstName.value} ${lastName.value}`);
</script>

<template>
  <p>Full name: {{ fullName }}</p>
</template>

You no need any dependency array — Vue go cover you for that side.

`watch` and `watchEffect` — reacting to changes

These ones na Vue's version of useEffect.

<script setup>
  import { ref, watch, watchEffect } from 'vue';

  const userId = ref(1);
  const user = ref(null);

  // watch: you ghas tell am exactly wetin you need make e watch
  watch(userId, async (newId) => {
    user.value = await fetchUser(newId);
  }, { immediate: true }); // run immediately on setup

  // watchEffect: automatically track dependencies (like useEffect with no array)
  watchEffect(async () => {
    // Runs whenever userId.value is read inside here
    user.value = await fetchUser(userId.value);
  });
</script>

Use watch when you need the old value or you wan dey in control. Use watchEffect for simpler cases wey you just want make e "do something when any of the reactive values change."

`provide` / `inject` — Vue's version of Context

<!-- Parent component -->
<script setup>
  import { provide, ref } from 'vue';

  const theme = ref('light');
  provide('theme', theme); // Make available to all descendants
</script>

<!-- Any pikin, e no get as e deep reach -->
<script setup>
  import { inject } from 'vue';

  const theme = inject('theme'); // Receive it
</script>

`defineProps` and `defineEmits` — component communication

Props dey flow down (parent to pikin), events dey flow up (pikin to parent):

<script setup>
  // Receiving props from parent
  const props = defineProps({
    title: String,
    count: { type: Number, default: 0 },
  });

  // Sending events to parent
  const emit = defineEmits(['update', 'close']);

  function handleClick() {
    emit('update', props.count + 1);
  }
</script>

Composables — Vue's version of custom hooks

Just like React custom hooks, Vue gree you authority make you comot reusable logic keep inside composables:

// useCounter.js
import { ref } from 'vue';

export function useCounter(initialValue = 0) {
  const count = ref(initialValue);
  const increment = () => count.value++;
  const reset = () => (count.value = initialValue);
  return { count, increment, reset };
}

// Usage in any component
const { count, increment, reset } = useCounter(10);

State management beyond composables

Library	Best for
Pinia	The official Vue state library — simple, intuitive, devtools support
VueUse	Collection of 200+ composables for common tasks

Pinia blend well with Vue sotey for most Vue apps, you go don start to dey use am from day one:

// stores/counter.js
import { defineStore } from 'pinia';

export const useCounterStore = defineStore('counter', () => {
  const count = ref(0);
  const doubled = computed(() => count.value * 2);
  function increment() { count.value++; }
  return { count, doubled, increment };
});

// In a component
const counter = useCounterStore();
counter.increment();

Nuxt specifics

Nuxt na Vue's version of Next.js. It adds:

useState (no be React own o, Nuxt sef get e own!) — na for SSR-safe state wey many components dey share:

<script setup>
  // Nuxt's useState — server-safe, shared across the app
  const count = useState('count', () => 0);
</script>

useFetch and useAsyncData — these ones na for data fetching wey dey work for both server and client:

<script setup>
  const { data: posts, pending, error } = await useFetch('/api/posts');
</script>

<template>
  <div v-if="pending">Loading...</div>
  <ul v-else>
    <li v-for="post in posts" :key="post.id">{{ post.title }}</li>
  </ul>
</template>

Part 3: Angular

Angular na the most opinionated of the four. This one, na oga on e own. Na full framework wey get e own solution for almost everything. Unlike React and Vue wey fit no wear TypeScript boot, this one na must, you no wear am the TypeScript boot, e no march be that. Angular dey use TypeScript by default and dem build am around classes, decorators, and dependency injection.

How Angular dey handle state: Services + Signals

Angular components fit get local state, but any state wey you go share dey typically live inside Services — wey be injectable classes wey you go fit chook anywhere for inside the app.

Local state with Signals (Angular 16+)

Angular carry Signals come as modern, reactive way to take dey manage state — e dey simple pass the old taker method:

import { Component, signal, computed, effect } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <p>Count: {{ count() }}</p>
    <p>Doubled: {{ doubled() }}</p>
    <button (click)="increment()">+</button>
  `
})

export class CounterComponent {
  // signal() na Angular's version of useState/ref
  count = signal(0);

  // computed() dey automatically track dependencies — be like Vue's computed
  doubled = computed(() => this.count() * 2);

  increment() {
    this.count.update(v => v + 1); // or: this.count.set(5)
  }
}

You go notice say we dey call the signals like functions — count() not count — so that e go fit read the value and allow make Angular track dependencies.

Older approach: RxJS Observables (a.k.a old taker, egbon adugbo)

Before Signals enter the settings, Angular relied heavily on RxJS Observables — e dey very powerful, but omo, e no easy to learn at all. You go still dey see am for many ogbonge codebase sha:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

@Component({ selector: 'app-example', template: `<p>{{ value }}</p>` })

export class ExampleComponent implements OnInit, OnDestroy {
  value = '';
  private destroy$ = new Subject<void>();

  ngOnInit() {
    someObservable$
      .pipe(takeUntil(this.destroy$)) // auto-unsubscribe on destroy
      .subscribe(val => this.value = val);
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

Signals don dey replace a lot of this complexity — so if you just wan start talking stage with Angular, learn Signals first.

Services — shared state across components

// counter.service.ts
import { Injectable, signal, computed } from '@angular/core';

@Injectable({ providedIn: 'root' }) // 'root' = singleton, available everywhere
export class CounterService {
  private count = signal(0);
  readonly currentCount = this.count.asReadonly(); // expose as read-only
  readonly doubled = computed(() => this.count() * 2);

  increment() { this.count.update(v => v + 1); }
  reset()     { this.count.set(0); }
}

// For inside any component — Angular fit inject am automatically
@Component({ ... })
export class MyComponent {
  constructor(private counter: CounterService) {}
  // Or modern Angular:
  counter = inject(CounterService);
}

The @Injectable({ providedIn: 'root' }) decorator makes the service a singleton — na only one instance dem go dey share across your whole app.

Lifecycle hooks

Angular dey use class methods for lifecycle, instead of React's useEffect:

@Component({ ... })
export class MyComponent implements OnInit, OnDestroy {
  ngOnInit() {
    // Run am once after the component don initialise
    // Same as useEffect(() => {}, [])
  }

  ngOnChanges(changes: SimpleChanges) {
    // Run am when @Input() props don change
    // same as useEffect(() => {}, [prop])
  }

  ngOnDestroy() {
    // Cleanup — na same thing with the return function for inside useEffect
  }
}

Input and Output — Angular's props and events

import { Component, Input, Output, EventEmitter } from '@angular/core';

@Component({
  selector: 'app-greeting',
  template: `
    <p>Hello, {{ name }}!</p>
    <button (click)="clicked.emit(name)">Say hello</button>
  `
})
export class GreetingComponent {
  @Input() name = '';                         // Receive data from parent
  @Output() clicked = new EventEmitter<string>(); // Send events to parent
}

In Angular 17+, dem don give signal new garment (syntax) wey even con clean pass before:

// Modern Angular (17+)
name = input<string>('');        // signal-based Input
clicked = output<string>();       // signal-based Output

Dependency injection — Angular's superpower

Angular get built-in dependency injection (DI) system. You declare wetin the class need, and Angular go provide am:

@Component({ ... })
export class ProductListComponent {
  private productService = inject(ProductService);
  private router = inject(Router);

  products = this.productService.getAll();
}

This one na key design pattern — components no go swallow too much, e go dey thin and dey focused on the template, while services go handle all the data logic.

State management beyond Services

Angular's Services + Signals dey cover most cases well. But for large apps:

Library	Best for
NgRx	Redux-style state management for large, complex apps
NgRx Signal Store	Modern, Signal-based NgRx — simpler than classic NgRx
Akita / Elf	Simpler alternatives to NgRx

Part 4: Svelte

Svelte na the newcomer wey get the most beginner-friendly approach. Unlike React and Vue, Svelte no get virtual DOM — e own na to compile your components into lean, efficient JavaScript at build time.

The result? Less boilerplate, shikini bundle sizes, and for many cases, na e get the simplest syntax out of the four.

Local state — just declare a variable

Na for here gan gan Svelte dey shine pass. For Svelte 5 (which na the current version), you go use wetin dem call runes — this na special compiler instructions wey use eye resemble functions:

<script>
  let count = $state(0); // $state na the Svelte 5 rune
</script>

<p>Count: {count}</p>
<button onclick={() => count++}>Click me</button>

Lobatan. Gaskiya. No useState, no .value, no ref. You go just increment the variable directly and Svelte go handle the rest.

Svelte 4 comparison (older way, but e still common)

<script>
  let count = 0; // In Svelte 4, just a plain variable
</script>

<p>Count: {count}</p>
<button on:click={() => count++}>Click me</button>

The plain variable approach con even wan dey simple pass, but Svelte 5's runes go give you more explicit control for complex scenarios.

`$derived` — reactive computed values

<script>
  let count = $state(0);
  let doubled = $derived(count * 2); // Auto-updates when count changes
</script>

<p>{count} doubled is {doubled}</p>

`$effect` — reacting to state changes

<script>
  let count = $state(0);

  $effect(() => {
    // Runs when count change — be like useEffect but e no need any dependency array!
    console.log('Count changed to:', count);

    return () => {
      console.log('Cleanup!'); // Runs before the next effect or on destroy
    };
  });
</script>

You go notice say e no get any dependency array. Svelte dey steady dey track which reactive values dem dey read inside $effect automatically.

Props — receiving data from a parent

<!-- Greeting.svelte -->
<script>
  let { name, age = 25 } = $props(); // Na $props() go receive all the props wey the parent dey pass
</script>

<p>Hello {name}, you are {age} years old.</p>

<!-- Parent usage -->
<Greeting name="Alice" age={30} />

Two-way binding — this na Svelte's killer feature

<script>
  let name = $state('');
</script>

<!-- bind:value go create the two-way binding — the variable go always dey update anytime wey the input change -->
<input bind:value={name} placeholder="Type your name" />
<p>Hello, {name}!</p>

If na React now, e go need make one of e boys; onChange con handle am for am. Svelte dey run am solo with just one word.

Stores — sharing state between components

For global state, Svelte get stores. For Svelte 5, you fit also use plain $state for inside shared module:

// stores/counter.js
import { writable, derived } from 'svelte/store';

export const count = writable(0);
export const doubled = derived(count, $count => $count * 2);

// Helper functions
export function increment() {
  count.update(n => n + 1);
}
export function reset() {
  count.set(0);
}

<!-- In any component -->
<script>
  import { count, doubled, increment } from './stores/counter.js';
</script>

<!-- The $ prefix auto-subscribes and auto-unsubscribes -->
<p>Count: {$count}, Doubled: {$doubled}</p>
<button onclick={increment}>+</button>

The $ prefix wey we dey write before a store name for inside template na Svelte's "auto-subscribe" syntax be that — na im dey handle subscribing and unsubscribing automatically, so you no need worry about memory leaks.

Svelte 5 module-level state (the new approach)

For Svelte 5, you still even fit share state even more simply:

// sharedState.svelte.js
export let count = $state(0); // Shared reactive state in a module
export let doubled = $derived(count * 2);

<script>
  import { count, doubled } from './sharedState.svelte.js';
</script>

<p>{count} → {doubled}</p>
<button onclick={() => count++}>+</button>

Lifecycle in Svelte

<script>
  import { onMount, onDestroy } from 'svelte';

  let data = $state(null);

  onMount(async () => {
    // Runs when the component mount or e dey added to the DOM
    data = await fetchSomething();
  });

  onDestroy(() => {
    // Runs when component is removed
    clearInterval(timer);
  });
</script>

SvelteKit specifics

SvelteKit na Svelte's own full-stack framework (be like Next.js and Nuxt). Data loading for SvelteKit dey clean and explicit:

// +page.server.js (server-side load function)
export async function load({ params }) {
  const post = await db.getPost(params.id);
  return { post }; // Passed as props to the page
}

<!-- +page.svelte -->
<script>
  let { data } = $props(); // Receives the loaded data automatically
</script>

<h1>{data.post.title}</h1>

Side-by-side comparison

Concept	React	Vue 3	Angular	Svelte 5
Local state	`useState(0)`	`ref(0)`	`signal(0)`	`$state(0)`
Computed value	`useMemo(() => ...)`	`computed(() => ...)`	`computed(() => ...)`	`$derived(...)`
Side effects	`useEffect(() => {}, [dep])`	`watch(dep, fn)`	`effect(() => {})`	`$effect(() => {})`
Context / DI	`useContext(Ctx)`	`inject('key')`	`inject(Service)`	Stores / shared modules
Component props	`function C({ name })`	`defineProps({ name })`	`@Input() name`	`let { name } = $props()`
Events to parent	Callback props	`emit('event', val)`	`@Output() EventEmitter`	`let { onEvent } = $props()`
Global state	Context / Zustand / Redux	Pinia	Services + Signals / NgRx	Stores / shared `.svelte.js`
Meta-framework	Next.js	Nuxt	— (Angular is already full)	SvelteKit

Which one make you learn first?

Omo e no get how to answer this one o. E no really get one correct answer, but na my honest opinion be this:

Learn React if: you wan see more job opportunities, you dey find one wey the ecosystem large gan, and you no mind slightly more boilerplate. React OT (explicit state, explicit effects) go teach you make you dey reason about reactivity carefully.

Learn Vue if: you want the one wey no go too hard you to learn and wey get better documentation. Vue's Composition API dey sharp, and Pinia sef con make the global state dey sweet belle. E strong for European and Asian markets wella.

Learn Angular if: you dey target enterprise companies or financial/government projects. Angular's opinionation mean say teams go dey write consistent code. E heavy to learn, na nama (strong meat to chew), but e dey powerful once you don internalize am.

Learn Svelte if: you love simple, shikini boilerplate and you wan understand how reactivity dey work for the fundamental level. SvelteKit sef na one genuinely delightful framework. E no too get market, but im sef don dey grow quickly.

Key takeaways

State na just data wey your UI need to react to. Every framework na e give you e own way to declare am and to update am.
Effects na how you go dey blend with the outside world — APIs, timers, subscriptions. Every framework get e own way to run code when something change for inside am.
Local state → component-level. Context / Stores / Services → shared between components.
No rush enter global state too early. Start with local state, con dey lift am up when siblings need to share am, and only introduce a state library when water don dey pass garri.
The core concepts dey more important pass the syntax. Once you don understand state, computed values, effects, and context for one framework, to enter another another go mostly be like syntax exercise.

Cheers!🥂

Setting Up Gmail OAuth2 With Nodemailer and Google Cloud Platform (GCP)

Tech In Vernacular — Sat, 06 Jun 2026 11:00:00 +0000

Sending emails from applications now don evolve significantly from how e take dey be over the years. The normal way wey be username and password authentication for Gmail SMTP wey we been dey use before no really dey market again because of some kind security matters and Google's own restriction for apps wey dey considered "less secure".

The latest way now wey secure pass na to use Gmail OAuth2 authentication, with another external emailing padi like Nodemailer. I been just run am for my portfolio na why e sweet me to write like this, make another person for fit find am helpful.

For this guide, you go sabi how to:

Configure a Google Cloud Platform (GCP) project
Enable the Gmail API
Configure the OAuth Consent Screen
Generate OAuth credentials
Generate a refresh token
Configure Nodemailer with Gmail OAuth2
Handle common errors
Secure your application properly

This tutorial go work for:

Node.js
Express
Nuxt server routes
Vue backend APIs
Next.js API routes
TypeScript projects

Why use Gmail OAuth2?
Prerequisites
Creating a Google Cloud Project
Enabling the Gmail API
Configuring the OAuth Consent Screen
Creating OAuth Credentials
Installing Dependencies
Generating a Refresh Token
Configuring Nodemailer
Sending Emails
Escaping HTML and Preventing Injection
Common Errors and Fixes
Production Recommendations
Final Thoughts

Why use Gmail OAuth2?

Google don deprecate the password-based SMTP authentication for many applications.

OAuth2 dey offer:

Better security
Token-based authentication
No exposed Gmail passwords
Controlled access scopes
Revocable access

Instead make you do something like:

auth: {
  user: "example@gmail.com",
  pass: "gmail-password"
}

You go just do like this:

auth: {
  type: "OAuth2",
  user,
  clientId,
  clientSecret,
  refreshToken
}

Prerequisites

Before you start cook anything, make sure say the following ingredients dey ground:

A Google account
Node.js installed
npm or yarn
A backend/server environment
Basic knowledge of JavaScript or TypeScript

Creating a Google Cloud Project

Go to the Google Cloud Console:

Google Cloud Console

Step 1: Create new project

Click the project dropdown wey dey the top bar
Click New Project
Enter project name wey you want
Click Create

Wait for the project make e initialize.

Enabling the Gmail API

Once your project don create:

Open the APIs Library:

Google APIs Library

Search for:

Gmail API

Click the Gmail API
Click Enable

If you no enable this Gmail API, the OAuth email sending go just dey chop dust.

Configuring the OAuth Consent Screen

This step na must before you go generate OAuth credentials.

Navigate go:

OAuth Consent Screen

Step 1: Choose user type

Choose:

External

Then click Create.

Step 2: Fill the app information

Provide:

App name
Support email
Developer contact email

Example:

App Name: Portfolio Mailer

Step 3: Add test users

If your app still dey for testing mode:

Open the Test Users section
Add the Gmail account wey you wan dey use for sending the emails

If you jump this step pass, you go dey jam error:

unauthorized_client

Creating OAuth credentials

Now, na to create the OAuth credentials.

Go to:

Google Cloud Credentials

Step 1: Create OAuth client ID

Click Create Credentials
Select OAuth Client ID

Step 2: Select application type

Choose:

Web Application

No go choose:

Desktop App
Android
iOS

Step 3: Add redirect URI

Under the following section:

Authorized redirect URIs

Add:

http://localhost:3000

or your preferred port. This one na must if we wan generate refresh tokens.

Step 4: Save credentials

After you don done, Google go provide:

Client ID
Client Secret

Save them securely, you fit copy am or you fit download am.

Installing dependencies

Install the packages wey you go need:

npm install nodemailer googleapis dotenv

For TypeScript, also run:

npm install -D tsx typescript

Environment variables

Create a .env file:

SMTP_USER=your-email@gmail.com

GOOGLE_CLIENT_ID=your-client-id
GOOGLE_CLIENT_SECRET=your-client-secret
GOOGLE_OAUTH_REFRESH_TOKEN=your-refresh-token

No go ever commit .env files go GitHub, dem suppose don sing this one for your ear enough.

Generating a refresh token

This na one of the most important part for this setup.

Step 1: Create a script

Create a script file:

scripts/generate-refresh-token.ts

for the root of your application.

Then add the following code:

import { google } from "googleapis";
import dotenv from "dotenv";

dotenv.config();

const oauth2Client = new google.auth.OAuth2(
    process.env.GOOGLE_CLIENT_ID,
    process.env.GOOGLE_CLIENT_SECRET,
    "http://localhost:3000"
);

const scopes = [
    "https://mail.google.com/",
];

const url = oauth2Client.generateAuthUrl({
    access_type: "offline",
    scope: scopes,
    prompt: "consent",
});

console.log("Authorization url: ", url);

Step 2: Run the script

Using TypeScript, run:

npx tsx scripts/generate-refresh-token.ts

Or JavaScript:

node scripts/generate-refresh-token.js

Step 3: Open the authorization URL

The terminal go vomit the Google authorization URL give you.

Copy the link open am for your browser.

SMTP_USER

And approve the permissions wey go come up.

Step 4: Copy the authorization code

After the approval, Google go redirect go the url wey you set for step 3 when you dey create the OAuth credentials:

http://localhost:3000/?code=...

Copy the code value.

Example:

4/0AX4XfWh...

Step 5: Exchange code for the refresh token

Update the script with the following:

import { google } from "googleapis";
import dotenv from "dotenv";

dotenv.config();

const oauth2Client = new google.auth.OAuth2(
    process.env.GOOGLE_CLIENT_ID,
    process.env.GOOGLE_CLIENT_SECRET,
    "http://localhost:3000"
);

async function getRefreshToken() {
    const code = "PASTE_AUTHORIZATION_CODE_HERE";

    const { tokens } = await oauth2Client.getToken(code);

    console.log("Get tokens: ", tokens);
}

getRefreshToken();

Step 6: Run the script again

npx tsx scripts/generate-refresh-token.ts

You suppose see something wey go be like this:

{
  "access_token": "...",
  "refresh_token": "...",
  "scope": "https://mail.google.com/",
  "token_type": "Bearer"
}

Copy the refresh token put inside the .env.

Configuring Nodemailer

Now make we configure the transporter.

import nodemailer from "nodemailer";
import { google } from "googleapis";

const clientId = process.env.GOOGLE_CLIENT_ID!;
const clientSecret = process.env.GOOGLE_CLIENT_SECRET!;
const refreshToken = process.env.GOOGLE_OAUTH_REFRESH_TOKEN!;
const user = process.env.SMTP_USER!;

const oauth2Client = new google.auth.OAuth2(
    clientId,
    clientSecret,
    "https://developers.google.com/oauthplayground"
);

oauth2Client.setCredentials({
    refresh_token: refreshToken,
});

async function createTransporter() {
    const accessToken = await oauth2Client.getAccessToken();

    return nodemailer.createTransport({
        service: "gmail",
        auth: {
            type: "OAuth2",
            user,
            clientId,
            clientSecret,
            refreshToken,
            accessToken: accessToken.token || undefined,
        },
    });
}

Sending emails

Example:

const transporter = await createTransporter();

await transporter.sendMail({
    from: `"Portfolio Contact" <${user}>`,
    replyTo: "visitor@example.com",
    to: user,
    subject: "New Portfolio Message",

    text: `
Name: John Doe
Email: visitor@example.com

Message:
Hello there!
`,

    html: `
        <div>
            <h2>New Portfolio Message</h2>

            <p><strong>Name:</strong> John Doe</p>

            <p>
                <strong>Email:</strong>
                visitor@example.com
            </p>

            <p>Hello there!</p>
        </div>
    `,
});

Important: Use `replyTo` instead of `from`

This one na one common mistake wey fit happen.

No go do like this:

from: "visitor@example.com"

Gmail fit reject am, e dey get choko sometimes.

Instead, do am like this:

from: `"Portfolio Contact" <${user}>`,
replyTo: visitorEmail,

This one dey sweet Gmail belle, e go still allow make you fit send direct replies give the visitor.

Escaping HTML and preventing injection

No go ever inject raw user input put inside the HTML. This no safe at all and proper wahala fit brew if anyhow person go jam am:

html: `<p>${message}</p>`

Create an escapeHtml helper function, this way dey safe enough:

function escapeHtml(unsafe: string) {
    return unsafe
        .replace(/&/g, "&amp;")
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;")
        .replace(/"/g, "&quot;")
        .replace(/'/g, "&#039;");
}

or install the package, run:

npm install --save-dev escape-html @types/escape-html

Then use am like this:

const safeMessage = escapeHtml(message);

Then pass am:

html: `<p>${safeMessage}</p>`

Recommended security improvements

Validate email inputs

const emailRegex =
    /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

if (!emailRegex.test(email)) {
    throw new Error("Invalid email");
}

Limit input length

if (message.length > 5000) {
    throw new Error("Message too long");
}

Rate limit requests

Mount security for your form make you secure am from spam.

Recommended:

Cloudflare Turnstile
reCAPTCHA
IP rate limiting

Common errors and fixes

`unauthorized_client`

Cause:

OAuth consent no dey configured correctly
Gmail account no dey added as test user
Wrong OAuth client type

Fix:

Add yourself as a test user
Use Web Application OAuth client

`redirect_uri_mismatch`

Cause:

Missing redirect URI

Fix:
Add the local server with your desired port:

http://localhost:3000

to:

Authorized redirect URIs

`invalid_grant`

Cause:

Expired or revoked refresh token

Fix:

Generate a new refresh token

`Username and password not accepted`

Cause:

Using password auth instead of the OAuth2

Fix:

Use OAuth2 credentials

Production recommendations

For small forms like the portfolio/contact forms, the Gmail OAuth2 works well.

However, for scalable production apps, consider dedicated email providers like:

Advantages:

Better deliverability
Easier setup
Analytics
Fewer Gmail restrictions

Full code implementation

My full code implementation inside my Nuxt server component for my portfolio

import nodemailer from "nodemailer";
import escapeHtml from "escape-html";

export default defineEventHandler(async (event) => {
    const body = await readBody(event);

    if (!body) {
        throw createError({
            statusCode: 400,
            statusMessage: "Invalid request payload. Body is required.",
        });
    }

    const { name, email, subject, message, } = body;

    // Validation
    if (!name || typeof name !== "string" || !name.trim()) {
        throw createError({
            statusCode: 400,
            statusMessage: "Name is required and must be a valid text.",
        });
    }

    if (!email || typeof email !== "string" || !email.trim()) {
        throw createError({
            statusCode: 400,
            statusMessage: "Email address is required.",
        });
    }

    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!emailRegex.test(email.trim())) {
        throw createError({
            statusCode: 400,
            statusMessage: "Please provide a valid email address.",
        });
    }

    if (!message || typeof message !== "string" || !message.trim()) {
        throw createError({
            statusCode: 400,
            statusMessage: "Message is required and must be a valid text.",
        });
    }

    if (message.length > 5000) {
        throw createError({
            statusCode: 400,
            statusMessage: "Message too long",
        });
    }

    const trimmedName = escapeHtml(name.trim());
    const trimmedEmail = escapeHtml(email.trim());
    const trimmedSubject = escapeHtml(subject.trim());
    const trimmedMessage = escapeHtml(message.trim());


    // Dispatching
    const user = process.env.SMTP_USER;
    const receiver = process.env.CONTACT_EMAIL_RECEIVER ?? user;
    const clientId = process.env.GOOGLE_CLIENT_ID;
    const clientSecret = process.env.GOOGLE_CLIENT_SECRET;
    const refreshToken = process.env.GOOGLE_OAUTH_REFRESH_TOKEN;


    if (user && clientId && clientSecret && refreshToken) {
        try {
            const transporter = nodemailer.createTransport({
                service: "gmail",
                auth: {
                    type: "OAuth2",
                    user: user,
                    clientId: clientId,
                    clientSecret: clientSecret,
                    refreshToken: refreshToken,
                }
            })

            await transporter.sendMail({
                from: `"Portfolio Contact" <${user}>`,
                replyTo: trimmedEmail,
                to: receiver,
                subject: `${trimmedSubject ?? `Portfolio Message from ${trimmedName}`}`,
                text: `Name: ${trimmedName}\nEmail: ${trimmedEmail}\n\nMessage:\n${trimmedMessage}`,
                html: `
                    <div style="font-family: sans-serif; padding: 20px; color: #333; max-width: 600px; border: 1px solid #e2e8f0; border-radius: 12px;">
                        <h2 style="color: #235347; border-bottom: 2px solid #235347; padding-bottom: 8px;">New Contact Form Message</h2>
                        <p><strong>Name:</strong> ${trimmedName}</p>
                        <p><strong>Email:</strong> <a href="mailto:${trimmedEmail}">${trimmedEmail}</a></p>
                        <p><strong>Message:</strong></p>
                        <blockquote style="background: #f7fafc; padding: 15px; border-left: 4px solid #235347; margin: 0; white-space: pre-wrap;">${trimmedMessage}</blockquote>
                        <hr style="border: 0; border-top: 1px solid #e2e8f0; margin: 20px 0;" />
                        <p style="font-size: 0.875rem; color: #718096;">Sent from your Portfolio contact form.</p>
                    </div>
                `,
            });

            return {
                success: true,
                message: "Message sent successfully via SMTP!",
            };
        } catch (error: any) {
            console.error("SMTP sending error:", error);
            throw createError({
                statusCode: 500,
                statusMessage: `Failed to send email. Error: ${error.message || "SMTP Configuration Issue"}`,
            });
        }
    }
})

Final thoughts

Setting up Gmail OAuth2 with Nodemailer fit be like say na heavy or too much work because say the following dey involved:

Google Cloud configuration
OAuth flows
API permissions
Token generation

But once you don configure am properly, e go provide a secure and production-ready email solution wey no need make you expose your Gmail password.

The key steps no pass:

Enable Gmail API
Configure OAuth consent
Create OAuth credentials
Generate a refresh token
Configure Nodemailer correctly
Use replyTo instead of arbitrary from addresses
Escape user input to prevent injection

Once all these things don gather stand well, your application fit dey use Gmail and OAuth2 authentication dey send emails securely, you mind sef go dey at rest. I hope say you go find am usefully helpful.

Cheers🥂!

DEV Community: Tech In Vernacular

Microservices and Micro-Frontends: Full Gist Wey Every Engineer Suppose Know.

Wetin We Dey Talk About Here

Part 1: Microservices

Wetin Microservices Be

Why Microservices Come Dey Exist

Types of Microservices Architecture

Advantages of Microservices

Disadvantages

When Microservices Dey Applicable

When Microservices No Dey Applicable

Part 2: Micro-Frontends

Wetin Micro-Frontends Be

Why Micro-Frontends Come Dey Exist

Types / Approaches to Micro-Frontends

Advantages of Micro-Frontends

Disadvantages

When Micro-Frontends Dey Applicable

When Micro-Frontends No Dey Applicable

Part 3: How Microservices and Micro-Frontends Relate

Part 4: Key Nuances Wey Every Software Engineer Suppose Sabi

Conclusion

Flex & Grid - CSS Most Powerful Layout Systems.

Introduction & Why They Matter

CSS FLEXBOX: The One-Dimensional Layout System

Flex Container Properties

flex-direction

justify-content

align-items

flex-wrap

align-content

gap

Flex Item Properties

flex-grow, flex-shrink, flex-basis

align-self

BONUS

To center an item

CSS GRID: The Two-Dimensional Layout System

Activating Grid

Grid Container Properties

grid-template-columns & grid-template-rows

The fr Unit

auto-fill and auto-fit

grid-template-areas

Alignment Properties

Grid Placement & Spanning

grid-column and grid-row

Negative Line Numbers

Named Grid Lines

Grid Auto Placement & dense

Advanced Grid Techniques

Overlapping Items

Subgrid

Flexbox & Grid Working Together

Classic Combination: Page Shell + Component Layout

Real-World Layout Patterns

Pattern 1: Responsive Sidebar Layout

Pattern 2: 12-Column Dashboard Grid

Pattern 3: Auto-Responsive Card Gallery (No Media Queries)

Pattern 4: The Pancake Stack

Pattern 5: Pseudo-Masonry with dense

Tailwind CSS Reference

Tailwind Flexbox Classes

Tailwind Flexbox Examples

Tailwind Grid Classes

Tailwind Grid Examples

When to Use Which

Pro Tips & Common Mistakes

Common Flexbox Mistakes

Common Grid Mistakes

Pro Tips Worth Remembering

Hooks and State Management in Modern Frontend Frameworks

A complete beginner's guide to state management in React/Next.js, Vue/Nuxt, Angular, and Svelte

Before we start: wetin be "state" gan gan sef?

Part 1: React & Next.js

The golden rule of React hooks

useState — your first hook

useEffect — reacting to changes

useContext — sharing state without passing it everywhere

useReducer — when state gets complex

`grid-template-columns` & `grid-template-rows`

The `fr` Unit

`auto-fill` and `auto-fit`

`grid-template-areas`

`grid-column` and `grid-row`

Grid Auto Placement & `dense`

Pattern 5: Pseudo-Masonry with `dense`

`useState` — your first hook

`useEffect` — reacting to changes

`useContext` — sharing state without passing it everywhere

`useReducer` — when state gets complex

Performance hooks: `useMemo` and `useCallback`

`ref` — reactive primitive values

`reactive` — reactive objects

`computed` — derived values

`watch` and `watchEffect` — reacting to changes

`provide` / `inject` — Vue's version of Context

`defineProps` and `defineEmits` — component communication

`$derived` — reactive computed values

`$effect` — reacting to state changes

Important: Use `replyTo` instead of `from`