DEV Community: Dixon Gunasekara

From React Basics to Production Next.js: The Complete Roadmap

Dixon Gunasekara — Sat, 22 Aug 2026 16:17:10 +0000

Here is a structured, fast-track study guide to take you from React fundamentals all the way to building production-grade applications using Next.js.

This flow ensures you build a rock-solid mental model of the "older" core React concepts before layering on the powerful server-side paradigms of modern Next.js.

Phase 1: Core React Essentials

Before touching a meta-framework, you need a deep understanding of standard client-side React. If you are coming from an MVC background or another framework like Angular, focus on React's one-way data flow.

JSX & Component Architecture: Understand how to write declarative UI. Learn how to break down complex interfaces into small, reusable functional components.
State & Props (useState): Master how data moves down the component tree via props, and how local component memory is managed using state.
The Component Lifecycle (useEffect): This is often the trickiest part for beginners. Learn how to synchronize a component with an external system (like fetching data on mount or subscribing to an event) and how to write cleanup functions to prevent memory leaks.
The Essential Hooks Toolkit:

-> useRef: For persisting values between renders without triggering a re-render, or directly accessing DOM elements.
-> useContext: For avoiding "prop drilling" by sharing state globally (like a UI theme or user session) across the component tree.
-> Custom Hooks: Learn to extract reusable logic (e.g., a useFetch hook) out of your UI components.

Phase 2: Advanced React Patterns

Once you can build a basic React app, you need to learn how to make it scale and perform well.

Performance Optimization: Learn when not to render. Master useMemo (caching expensive calculations), useCallback (caching function definitions), and React.memo (preventing child components from re-rendering if their props haven't changed).
Global State Management: While Context API is great, for complex state, learn a modern lightweight state manager like Zustand (or Redux Toolkit if you need enterprise-level strictness).
Client-Side Data Fetching: Learn React Query (TanStack Query). It handles caching, deduplication, background fetching, and loading states—replacing standard useEffect data fetching entirely.

Phase 3: The Next.js Paradigm Shift

Next.js shifts React from being just a client-side library to a full-stack framework. The modern standard is the App Router (/app directory).

React Server Components (RSC): Understand the difference between Server Components (rendered on the server, zero bundle size, direct backend access) and Client Components (marked with "use client", standard React components with state/effects). Default to Server Components.
File-Based Routing: Learn how folders define routes. Understand page.tsx (the UI for a route) and layout.tsx (shared UI like navbars that persist across routes).
Advanced Routing: Master dynamic routes ([id]), route groups ((auth)), and intercepting routes.

Phase 4: Modern Data Architecture

Next.js fundamentally changes how you interact with databases and APIs.

Server-Side Fetching: Learn how to use the native fetch API inside Server Components. Understand caching strategies (force-cache, no-store) and Time-Based/On-Demand Revalidation (ISR).
Server Actions: This replaces traditional API routes. Learn how to write asynchronous server functions that can be called directly from client-side forms to mutate data (e.g., submitting a form directly to a database without building a REST endpoint).
Streaming & Suspense: Learn how to use loading.tsx and React <Suspense> boundaries to progressively stream UI to the user while backend data is still fetching.

Phase 5: Production-Grade Implementation

To build an enterprise-ready application, you need to integrate external tooling for security, data modeling, and deployment.

Concept	Industry Standard Tools to Learn
Authentication	Auth.js (NextAuth) for OAuth/Credentials, or integrating a robust identity provider like AWS Cognito.
Database ORM	Prisma (excellent developer experience) or Drizzle ORM (high performance, SQL-like syntax).
Styling	Tailwind CSS. It is the default standard for modern React/Next.js development.
Error Handling	Master error.tsx for granular error boundaries and not-found.tsx for 404s.
Deployment	Vercel (the creators of Next.js, zero-config) or deploying via containerized pipelines to infrastructure like AWS ECS/Amplify depending on your cloud strategy.

Create React App is Dead. What’s Next? (Vite vs. Next.js)

Dixon Gunasekara — Sat, 22 Aug 2026 03:49:15 +0000

For years, npx create-react-app my-app was the undisputed starting point for almost every React developer. It was the golden standard—a zero-configuration miracle that abstracted away the painful complexities of Webpack and Babel.

But times have changed. As the web evolved, the tools needed to evolve with it. The React core team officially removed Create React App (CRA) from their recommended starting guides, signaling the end of an era. It was slow, bloated, and relied on aging bundler technology.

So, if CRA is dead, what is the new standard? The React community has largely coalesced around two major players: Vite and Next.js.

Here is a breakdown of what they are, how they differ, and which one we should choose for our next project.

Why Did CRA Die?

Before we look forward, let's briefly look back. Create React App fell out of favor for a few key reasons:

Sluggish Performance: CRA relied on Webpack. As our project grew, spinning up the local development server could take excruciatingly long seconds (or minutes).

Lack of Flexibility: It was a "black box." If we needed to tweak the underlying Webpack configuration, we had to eject—a chaotic, one-way operation that exposed massive configuration files and ruined the simplicity CRA promised.

Client-Side Rendering (CSR) Only: CRA only built Single Page Applications (SPAs). As SEO and initial page load speeds became paramount, the industry shifted toward Server-Side Rendering (SSR) and Static Site Generation (SSG)—features CRA didn't support natively.

The Speed Demon: Vite

Created by Evan You (the creator of Vue.js), Vite (French for "fast") is a build tool that aims to provide a significantly faster and leaner development experience for modern web projects.

How it Works

Unlike Webpack, which crawls our entire application and builds a massive bundle before serving it to the browser, Vite leverages native ES modules in the browser. It only compiles the code we are currently looking at. This means the development server starts almost instantly, regardless of our project's size, and Hot Module Replacement (HMR) is incredibly snappy.

When to Choose Vite

Vite is the true spiritual successor to Create React App. If we want to build a traditional Client-Side Rendered (CSR) Single Page Application, Vite is our best bet.

Pros:

Blazing Fast: Near-instant dev server startup and HMR.
Framework Agnostic: It supports React, Vue, Svelte, and vanilla JavaScript.
Easy Configuration: vite.config.js is highly customizable and much simpler than Webpack.

Cons:

SEO Challenges: Like CRA, it builds SPAs, which can be harder for search engines to index effectively without additional work.
No Backend Magic: It is strictly a frontend build tool. We have to bring our own backend and routing solution (like React Router).

How to start:

npm create vite@latest my-app -- --template react

The Full-Stack Powerhouse: Next.js

Built and maintained by Vercel, Next.js is a comprehensive React framework. It doesn't just bundle our code; it dictates an architecture for building robust, production-ready applications.

How it Works

Next.js provides built-in solutions for routing, data fetching, and rendering. Its biggest selling point is its rendering flexibility. We can choose to render pages on the server (SSR), generate them statically at build time (SSG), or stick to traditional client-side rendering (CSR)—often mixing and matching these strategies within the same application.

When to Choose Next.js

Next.js is the heavy hitter. It is the go-to choice if we are building an e-commerce site, a blog, a SaaS product, or any application where SEO, initial load performance, and robust routing are critical.

Pros:

Out-of-the-Box SEO: Server-side rendering ensures search engines can read our content immediately.
File-Based Routing: The App Router (or Pages Router) makes creating new routes as simple as adding a file to a directory.
Full-Stack Capabilities: We can write serverless functions and API routes directly within our Next.js project.

Cons:

Steeper Learning Curve: We have to learn the "Next.js way" of doing things (caching, data fetching, routing), which is more complex than standard React.
Potential Overkill: For a simple dashboard or internal tool, Next.js can be more architecture than our actually need.

How to start:

npx create-next-app@latest

The Verdict: Which Should We Choose?

The decision ultimately comes down to the scope and requirements of our project.

Feature	Vite	Next.js
Best For	Dashboards, Internal Tools, Simple SPAs	E-commerce, Blogs, SaaS, Public-facing Sites
Primary Rendering	Client-Side (CSR)	Server-Side (SSR) / Static (SSG)
Routing	Bring our own (e.g., React Router)	Built-in File-Based Routing
SEO Focus	Low	High
Learning Curve	Low (Similar to standard React)	Medium to High

Kubernetes for Beginners

Dixon Gunasekara — Wed, 19 Aug 2026 02:26:02 +0000

1. Why was Kubernetes invented?

Before Kubernetes, the way companies ran applications went through three major phases:

The Physical Server Era: Applications were run on physical hardware. If one app took up too much memory, other apps on that server would crash. It was expensive and wasteful.

The Virtual Machine (VM) Era: To solve the hardware problem, VMs allowed to run multiple isolated "virtual" computers on one physical server. This was better, but VMs were heavy and slow to start because each one needed its own full operating system.

The Container Era (Docker): Developers realized they didn't need a whole operating system for every app. They created "containers"—lightweight, isolated packages containing just the app and what it needs to run.

The Breaking Point: Containers were brilliant, and companies started using them for everything. But suddenly, instead of managing 10 large VMs, a company had to manage 1,000 tiny containers. If a container crashed in the middle of the night, someone had to manually restart it. If a website went viral, someone had to manually start 50 more containers to handle the traffic. It became a logistical nightmare.

Kubernetes was invented to be the automated "pilot" for the containers.

It handles the things humans are too slow to do:

Automated Scaling: If the app suddenly gets a spike in traffic, Kubernetes automatically creates more containers to handle the load, then scales them back down to save money when traffic drops.
Self-Healing:
If a container crashes, the server dies, or a network drops, Kubernetes instantly notices and starts a replacement container somewhere else without a human having to intervene.
Automated Rollouts:
It allows developers to release new versions of an application slowly, behind the scenes. If the new version has a bug, Kubernetes automatically rolls it back to the old one before users notice.

Ultimately, Kubernetes was invented so developers could stop worrying about how their apps were running and get back to actually writing the code.

2. The main two components of Kubernetes architecture

The Control Plane Node (The Brain)
The Control Plane is responsible for making global decisions about the cluster. It does not run our applications; it manages the machines that do. Its job is to maintain the desired state of the cluster, respond to events (like a node crashing), and schedule workloads.
The Worker Node (The Muscle)
A Worker Node is the machine (virtual or physical) where our actual application workloads (Pods and Containers) are executed. Its sole job is to do what the Control Plane tells it to do and report back on its status.

In a production cluster, we will have many worker nodes to distribute the load and provide redundancy.

3. The components of the Kubernetes Control Plane

kube-apiserver (The Front Door)

This is the only component that interacts directly with the user (via kubectl) and the only component that talks directly to the database (etcd).

Function: It exposes the Kubernetes REST API. When we want to create, read, update, or delete any resource (like a Pod or a Deployment), we send that request here.

Security: It acts as the gatekeeper. It handles authentication, authorization, and admission control.

Scale: It is designed to scale horizontally. In a highly available (HA) cluster, we will run multiple instances of the API server behind a load balancer.

etcd (The Source of Truth)

This is a consistent, highly-available, distributed key-value backing store.

Function: It holds the entire state of our cluster. Every configuration, every secret, and the desired state of every application is saved here.

The "Watch" Pattern: etcd allows the API server to "watch" for changes. If a change occurs in the database, the API server is immediately notified, which then notifies the other control plane components.

Crucial Rule: No other component (not the scheduler, not the controllers, not the worker nodes) is allowed to query etcd directly. They all must ask the API server.

kube-scheduler (The Dispatcher)

When a new Pod is created in etcd, it doesn't have a node assigned to it yet. The scheduler's job is to find it a home.

Function: It watches the API server for newly created Pods with no assigned node, and selects a healthy worker node for them to run on.

Decision Making: It doesn't pick nodes randomly. It runs a two-step process:

-> Filtering: It eliminates nodes that can't run the Pod (e.g., the node doesn't have enough RAM, or the Pod requires a GPU that the node lacks).
-> Scoring: It ranks the remaining nodes to find the optimal placement (e.g., preferring a node that already has the required container image downloaded).

kube-controller-manager (The Enforcer)

This is actually a single binary that compiles several distinct, infinite control loops (controllers) into one process.

Function: It continuously watches the current state of the cluster (via the API server) and compares it to the desired state (stored in etcd). If they don't match, it takes action to fix it.

Examples of internal controllers:

-> Node Controller: Notices when a worker node goes offline and responds.

-> ReplicaSet Controller: Ensures the correct number of Pods are running for a given application.

-> Job Controller: Watches for Job objects (one-off tasks) and creates Pods to run those tasks to completion.

cloud-controller-manager (The Liaison - Optional)

If our cluster is running in the cloud (AWS, GCP, Azure), this component lets Kubernetes talk directly to the cloud provider's API.

Function: It separates cloud-specific control logic from the core Kubernetes code.

Examples: If we create a Kubernetes Service of type LoadBalancer, the cloud-controller-manager talks to AWS/GCP to actually spin up a physical load balancer resource in our cloud account and route traffic to our nodes.

4. The components of a Worker Node

kubelet (The Node Captain)

The kubelet is the primary "agent" that runs on every single worker node in the cluster.

-> The Job: It constantly listens to the Control Plane's kube-apiserver for instructions. When the Scheduler assigns a Pod to its node, the kubelet is responsible for making sure the containers described in that Pod are actually running and healthy.

-> The Watchdog: It doesn't just start containers; it monitors them. If a container crashes, the kubelet tries to restart it based on its defined restart policy. It also continuously reports the node's health and resource usage (CPU/Memory) back to the Control Plane.

Container Runtime (The Engine)

While the kubelet manages the concept of a Pod, it doesn't know how to actually run a container. That is the job of the Container Runtime.

-> The Job: It handles the low-level mechanics of pulling container images from a registry (like Docker Hub or AWS ECR), unpacking them, and running the isolated processes on the host operating system.

-> Examples: Kubernetes used to rely heavily on Docker, but today it uses runtimes that comply with the Container Runtime Interface (CRI), such as containerd or CRI-O.

kube-proxy (The Network Traffic Cop)

Since Pods are constantly being created, destroyed, and moved around, their internal IP addresses are always changing. The kube-proxy ensures that network traffic still finds its way to the right place.

-> The Job: It runs on every node and maintains network rules (usually by manipulating iptables or IPVS on Linux).

-> The Routing: If an external request comes in for your web application, or if a backend service needs to talk to a database Pod on another node, kube-proxy ensures that the traffic is routed dynamically to the correct, currently active Pod, no matter which worker node it happens to be living on.

5. Nodes vs Pods

Node
-> A physical or virtual machine.
-> The Cloud Provider (if managed K8s) or Cluster Admin.
-> Long-lived.
-> Gets a host IP on the internal network.
Pod
-> An abstraction wrapping one or more containers.
-> Kubernetes Control Plane (specifically the Scheduler).
-> Short-lived / Ephemeral.
-> Gets its own unique cluster-internal IP address.
-> Many run on a single Node.

6. ConfigMaps vs Secrets

Feature	ConfigMap	Secret
Best for	Non-sensitive data (URLs, port numbers, config files)	Sensitive data (passwords, API keys, TLS certificates)
Storage Format	Plain text	Base64 encoded
Size Limit	1 MiB	1 MiB
Volume Mount	Standard disk storage	tmpfs (RAM-backed filesystem, never hits disk)

7. Full Architecture of the Production Kubernetes Cluster

How to Track Configuration Changes and Compliance of AWS Resources

Dixon Gunasekara — Sun, 16 Mar 2025 12:24:48 +0000

AWS Config is the most comprehensive service for tracking configuration changes and compliance.

Key Features:

Resource Configuration Tracking: Monitors and records configurations of supported AWS resources over time.
Change History: Stores historical configuration data and changes.
Compliance Auditing: Uses Config Rules to assess compliance with desired configurations.
Automatic Remediation: Triggers AWS Systems Manager Automation to correct non-compliant resources.

Setup Steps:

First, go to AWS Config. If it's not enabled, it will be shown as bellow. Hit Get started.

Then, we get into the first step and we have to select Recording strategy. There are two options from which one should be selected. I'm selecting the first option (All resource types with customisable overrides).

All resource types with customisable overrides
Specific resource type

When selecting one out of these two, we should consider our use case and the pricing.

Next, we have to select Recording frequency. Here also, there are two options from which one should be selected. Here also, I'm selecting the first option (Continuous recording).

Continuous recording
Daily recording

When selecting one out of these two, we should consider our use case and the pricing.

Then, we have the option Override settings where we can override settings. By default, we get one override as shown in the bellow. According to our use case we can remove it or add more.
Next, we can select existing role or let to create a new role for this service. It's under Data governance.
Next, we can select an existing s3 bucket or let to create a new s3 bucket for storing configuration history and snapshots. It's under Delivery channel.

Then, we have optional setting to set up SNS topic.

I'm not selecting a SNS topic here and hit Next.
Next, we come into the second step, where we have to Rules. I'm selecting restricted-ssh rule which is an AWS managed rule. However, We can create Custom Rules using AWS Lambda for specific use cases.

Then, hit the Next and we come into the third step where we can review. If everything is fine, we can hit Confirm.

Next, it will be shown as bellow.

For my account currently, there are no noncompliant rules or resources. Therefore, I'm launch an EC2 instance allowing SSH access from any IP.

Next, again check AWS config dashboard. If it's same as it was earlier, refresh after some time. Then, we'll be able to see it like this. Note that now we can see that there are one noncompliant rule and one noncompliant resource.

We can use Aggregators to collect data across multiple accounts/regions (if we're using AWS Organizations).