Layered Architecture

Architecture

Brief recap: layered architecture divides an application into clear layers (presentation, service, data access, and infrastructure) that separate concerns and make systems easier to reason about and maintain.

<editorjs-style style="background: yellow;color: black;">Why Node.js + Express needs structure as apps scale:</editorjs-style>

Read the conceptual foundation first:&nbsp;<a href="https://www.codearchitecture.in/stories/what-is-layered-architecture-a-complete-flow-principles-and-best-practices" target="_blank">What is Layered Architecture? A Complete Flow, Principles, and Best Practices</a>

2. Why Layered Architecture Fits Node.js &amp; Express

Problems with unstructured Express apps

Separation of concerns in JavaScript backend systems

3. Core Layers in a Node.js + Express Application

This table summarizes responsibilities so developers know where to add code and where not to.

4. Recommended Folder Structure for Layered Architecture in Node.js

A clean, scalable folder structure (example):

How this structure helps in large teams?

5. Request Flow in Layered Architecture (Step-by-Step)

Controller (HTTP) 👉 Service (business logic)&nbsp;

👉&nbsp;Repository (data access)&nbsp;

👉&nbsp;Database

6. Minimal Layered Architecture Example: One Route, One Flow

Many tutorials jump straight into large projects. That can obscure the boundaries between layers. A minimal example helps you internalize where responsibilities live before scaling the pattern across a full application.

This example is a mental model, intentionally small so each file has one clear reason to change.

Class-Based Layers with Explicit Dependency Injection

Layered architecture maps well to class-based design in Node.js: classes express responsibilities and contracts clearly, and constructor-based injection makes dependencies explicit and testable. Constructor injection reduces hidden coupling, simplifies unit testing, and keeps each layer focused on one responsibility.

"This example intentionally uses a class-based architecture for controllers, services, and repositories, with constructor-based dependency injection to keep layers decoupled and testable."

6. Service Layer (Business Logic Boundary)

7. Repository Abstraction (Core Teaching Moment)

In repositories/MongoCategoryRepository.js

Introduce a small composition root (container) responsible for wiring.

10. Request Flow Recap (Reinforced Learning)

Flow in plain English: Route (GET /categories) 👉 Controller (listCategories)&nbsp;

👉 Service (listActiveCategories)&nbsp;

👉&nbsp;Repository (findActive)&nbsp;

👉&nbsp;Database

Each file has exactly one reason to change: routing/HTTP, request handling, business rules, or storage.

MongoCategoryRepository ↓ CategoryService (business rules) ↓ CategoryController (HTTP mapping) ↓ Route (Express)

Dependencies always point inward: route depends on controller, controller depends on service, service depends on repository (injected).

Dependency Injection vs Dependency Versioning

Layered architecture focuses on runtime dependency boundaries and explicit wiring so collaborators can be swapped without changing business logic.

8. Service Layer: The Heart of Business Logic

Layered Architecture in Node.js and Express: Class-Based Design, Dependency Injection, and Best Practices

JavaScript is flexible, and that freedom can lead to entangled code in medium-to-large teams.

Express apps often begin as single-file servers and grow into monoliths where responsibilities blur.

A layered approach enforces boundaries, simplifies testing, and improves onboarding.

Mixed concerns in routes (DB calls, validation, business logic).

Difficulty changing storage, e.g., migrating from MongoDB to Postgres.

Keep HTTP handling in presentation, business rules in services, and storage in repositories.

JavaScript's dynamic nature benefits strongly from explicit boundaries.

MVC groups by role (Model/View/Controller); layered architecture organizes by responsibility boundaries across the stack.

For complex systems, layered architecture often gives clearer extension points and testability than vanilla MVC.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">controllers/</editorjs-style>: Map request to service calls, this should be thin and focused.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">routes/</editorjs-style>: Wire endpoints, versioning, and validators (e.g., Joi/Zod).

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">services/</editorjs-style>: Encapsulate use-cases and transaction boundaries.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">repositories/</editorjs-style>: Single place for SQL/NoSQL queries and pagination logic.

Clear ownership: teams own layers and folders.

Reduces merge conflicts by separating concerns.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">routes</editorjs-style> receive the request and forward to a <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">controller</editorjs-style>.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">controller</editorjs-style> extracts params and calls a <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">service</editorjs-style> method.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">service</editorjs-style> coordinates operations (validation, orchestration), calling <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">repositories</editorjs-style> as needed.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">repository</editorjs-style> executes persistence logic and returns results.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">service</editorjs-style> applies business rules, returns domain result to <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">controller</editorjs-style>.

<editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">controller</editorjs-style> formats HTTP response and sends it back.

Endpoint: <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">GET /categories</editorjs-style>

What happens at each layer (one sentence each)

Route: Accepts the HTTP request and forwards it to the controller (wired by the container).

Controller: Extracts pagination/query params and calls the service.

Service: Orchestrates the use case and asks the repository for active categories.

Repository: Runs the database query and returns raw records.

Routes should only wire HTTP → controller. No logic, no DB calls, no business rules. Import controllers from the composition root (container), not from raw controller factories.

Extracts request context (query params, headers).

Calls a service method and returns the response.

No DB queries, no business rules, no formatting beyond HTTP concerns.

Services know use-case flows and domain rules, but not HTTP or persistence details.

It is a contract. The abstract class defines the surface area of storage operations without tying implementation details.

Services depend on the abstract methods. Replacing <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">MongoCategoryRepository</editorjs-style> with another implementation requires no changes to services.

This is the ONLY place DB logic lives. Services call <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">findActive()</editorjs-style> without knowing query details.

services call an instance of CategoryRepository (concrete or injected abstraction).

This is NOT a DI framework. It is a single file that composes concrete implementations into functional layers.

Keeping wiring here prevents layers from importing concrete implementations and keeps dependencies one-way.

Dependency injection manages runtime collaborators (which repository or service instance the code talks to at runtime).

Dependency versioning (npm / package.json) manages package versions and upgrades; it is unrelated to runtime wiring.

Extract and sanitize input, call validation middleware or DTO mappers.

Format and send HTTP responses; handle simple input-level errors.

Should: request parsing, sending response, invoking service methods.

Should not: database queries, long business logic, heavy transformations.

Controller receives POST /orders, validates shape, calls orderService.createOrder(payload) and returns 201 with created resource location.


Centralizes business rules and use-case flows.

Keeps controllers thin and repositories focused on storage.

Architecture matters because software that scales, is testable, and is maintainable doesn’t happen by accident, it’s designed. Layered architecture is one of the most enduring, approachable patterns teams use to organize systems so they remain predictable as they grow. This article explains, in plain language, what layered architecture is, why teams use it, and how to apply it well in production systems.

Layered architecture is a way to organize a system into horizontal slices, or layers, each with a clear responsibility and a defined direction for how work flows between them. Each layer communicates mainly with the layer directly above or below it. This creates a predictable path for requests and responses and helps keep concerns separated.

Software projects start small but rarely stay that way. As features, teams, and operational needs increase, codebases tend to become tangled: UI code calls database queries directly, business rules scatter in controllers, and tests become brittle because components are tightly coupled.

Layered architecture exists to prevent that tangling. By separating responsibilities, presentation, orchestration, business logic, data access, and persistence, teams can reason about each part independently. This separation helps scale teams, improve testability, and make deployments safer and more predictable.

If you want to build scalable, clean, and maintainable backend apps with Node.js, don’t miss our exclusive playlist that breaks down <a href="https://www.youtube.com/playlist?list=PLZVBmpM0E_DGngTx5A3f0K-F4m-UalDyb" target="_blank">Layered Architecture</a> in real projects. Learn how to organize your app into logical layers like routes, controllers, services, and data access, so your code becomes easier to build, test, and grow.&nbsp;

Below are the canonical layers you will see described in layered architecture. I use neutral, technology-agnostic names so any developer can map them to their stack.

Analogy: The reception desk at an office, directs visitors and collects basic information, but does not make hiring decisions.

Analogy: A dispatcher who takes a call and routes it to the correct internal team, supplying the necessary context.

Analogy: The operations team that knows company policy and makes decisions based on the rules.

Analogy: The archive department that knows how and where records are stored and finds them on request.

Analogy: The warehouse where physical boxes of records live.

Let’s trace a simple request through the system: Client to Router to Controller to Service to Repository to Database.

At every hop, code knows only what it needs to know about the next layer, producing a clear, testable chain.

Separation of concerns keeps the system reliable: the sender doesn’t know how trucks are loaded; they only care that the postal system enforces rules consistently.

How layered architecture supports SOLID principles

Layered architecture is naturally aligned with several SOLID principles. Below are the most directly relevant ones with simple, conceptual examples.

S - Single Responsibility Principle (SRP)

Definition in simple terms: A module or class should have one, and only one, reason to change.

How layers help: When responsibilities are separated by layer, each module within a layer changes for reasons specific to that responsibility. For instance, a change in presentation (new UI fields) should not cause repository changes. Controllers change for input/response concerns; services change for business rule changes; repositories change for persistence concerns.

Conceptual example: If tax calculation rules change, only the service/business logic layer should be touched, not the controller or repository.

Definition in simple terms: Components should be open for extension but closed for modification.

How layers help: Because controllers talk to services through stable interfaces and services talk to repositories through interfaces, you can extend behavior by adding new implementations or decorators without modifying existing classes. For example, adding a new discount rule can be implemented by extending the service logic or plugging in a new rule module rather than touching the controller.

Conceptual example: To add caching, implement a cache layer between services and repositories or wrap repository interfaces with a cache implementation. no change to controller or service code if dependencies are inverted.

Definition in simple terms: High-level modules should not depend on low-level modules; both should depend on abstractions.

How layers help: The service layer should depend on repository interfaces (abstractions), not their concrete database implementations. At runtime, a concrete repository implementation is injected. This decouples high-level business rules from low-level persistence details and makes testing easy using mocks or in-memory implementations.

Conceptual example: A service calls OrderRepository.save(order) where OrderRepository is an interface. During tests, a fake repository can be provided so the service can be tested without a real database.

How layered architecture helps scalability, testing, and cloud-native deployments

Clean architecture vs layered architecture

Clean architecture and layered architecture share goals: separation of concerns and testability. The difference is mostly emphasis and naming: clean architecture places more emphasis on dependency rules (outer layers depend on inner layers only via abstractions) and domain-centric design. Layered architecture is more pragmatic and describes horizontal slices. In practice, you can combine both: use layered slices while applying dependency inversion and domain-centric thinking.

Keywords: clean architecture vs layered architecture, controller service repository flow

Conclusion, Why learn layered architecture

Layered architecture is a practical, widely applicable approach for organizing software. It gives teams a shared vocabulary for responsibilities, supports several SOLID principles (especially SRP and DIP), and makes systems more maintainable, testable, and scalable in the cloud era.

If you are building a system that will grow, be maintained by a team, or require robust testing and deployment practices, layered architecture is a reliable starting point. Use clear boundaries, avoid common anti-patterns, and evolve abstractions only when responsibilities become stable.

Want a practical next step? Identify one endpoint in your system and draw the current flow. Label which code belongs to presentation, controller, service, repository, or persistence. Look for violations, business rules in controllers or direct DB calls from presentation, and refactor one violation at a time.

What is Layered Architecture? A Complete Flow, Principles, and Best Practices

Responsibility: Accepts input from clients (web UIs, mobile apps, API consumers) and forwards requests into the application. It is the system boundary, providing routing, protocol translation, and basic validation.

What flows through it: HTTP requests, messages, or other transport-level payloads. It maps external requests to internal requests (e.g., parse JSON to command object).

What it should not do: Implement business rules, data access logic, or complex coordination. It should avoid deep validation that duplicates business rules and should not access databases directly.

Responsibility: Translate inbound requests into application operations. Controllers decode parameters, create request models, call into the service layer, and format responses.

What flows through it: Request models, DTOs (data transfer objects), response wrappers, and status codes.

What it should not do: Hold business logic or data access code. Controllers should be thin orchestration points, not rule engines.

Responsibility: Host the core business rules and processes. This layer expresses the domain logic: validations that matter to the business, decision-making, orchestration of multiple operations, and transaction boundaries.

What flows through it: Domain objects, business commands, domain events. This layer calls repository interfaces to persist or fetch state.

What it should not do: Depend on concrete data access implementations or worry about transport protocols. It should not format HTTP responses or read request headers.

Responsibility: Abstract persistence and retrieval details. Repositories expose domain-friendly methods like <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">findCustomerById</editorjs-style> or <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">saveOrder</editorjs-style>, hiding query details and storage specifics.

What flows through it: Entities or plain data structures representing persisted state, and queries or commands to the data store.

What it should not do: Contain business rules or orchestrate higher-level workflows. Repositories should avoid returning raw transport models or depending on controller logic.

Responsibility: The physical store(s) for data, relational databases, key-value stores, object stores, or any persistence mechanism. This layer handles transactions, indices, and backup/recovery at the storage level.

What flows through it: Rows, documents, blobs, and storage-specific artifacts.

What it should not do: Contain business logic, format responses for clients, or serve as an application orchestration point.

Client sends a request (for example: “Create order with items”).

Router (entry layer) receives the request and maps it to the appropriate controller/action. It performs protocol-level concerns like authentication checks, rate limiting, or content-type negotiation.

Controller accepts parsed parameters, creates a request model, performs minimal validation (e.g., required fields), and calls the service layer.

Service executes business logic: checks product availability, computes totals, applies promotion rules, and decides whether to accept the order. It may start a transaction and coordinate multiple repository calls.

Repository translates service-level operations into persistence operations: SQL statements, document updates, or calls to cloud storage. It returns domain entities or indicators back to the service.

Database persists the data and returns an acknowledgment or result through the repository.

Service completes work, commits or rolls back transaction, and returns a domain result to the controller.

Controller maps the domain result to an external response format and sends it back to the client.

The client is a sender who drops a letter at a postbox (entry layer).

A postal clerk (controller) receives the letter, reads the address, and decides which sorting center to use.

The sorting center (services) applies routing rules, air vs ground, priority handling, insurance.

The local mail depot (repository) knows how to load the right trucks and update the tracking system.

The trucks and storage yards (database/persistence) physically move and store parcels.

Fat controllers: Pushing business logic into controllers makes code hard to test and reuse. Controllers should be thin.

Leaky repositories: Returning raw transport objects or forcing business rules into repositories blurs boundaries.

Tight coupling across layers: When upper layers import concrete implementations from lower layers, swapping implementations or testing becomes difficult.

Over-abstracting too early: Creating many tiny interfaces before the design stabilizes can add unnecessary complexity.

Using layers as permission to be lazy: Separation is not an excuse for bad code. Layer boundaries must be meaningful and enforced.

Teams that benefit from clear responsibilities and separation of concerns.

Systems where business rules matter and must be tested independently.

Projects that require multiple persistence strategies, or where persistence might change over time.

Systems that will be maintained by multiple teams or that must support parallel development on UI, services, and storage.

Small, throwaway scripts or single-file utilities, here separation can be overkill.

Highly performance-sensitive, tightly optimized systems where the overhead of layers could be significant. In those cases, carefully measured trade-offs are needed.

Systems that require event-driven or microservice choreography patterns as a primary design; sometimes a more decentralized architecture (e.g., event-driven or hexagonal patterns) may suit better.

Scalability: Clear separation makes it easier to scale the parts that need it. For example, stateless controller and service layers can be scaled horizontally behind load balancers, while repositories and databases scale independently (read replicas, sharding, managed storage).

Testing: Unit tests can exercise the service layer with repository mocks. Integration tests can target repository implementations with isolated databases. End-to-end tests can exercise the presentation-to-database flow.

Deployment: With layers, you can deploy independently, e.g., roll out a new version of the service layer without changing the controllers if interfaces are stable. This simplifies CI/CD and reduces blast radius.

Cloud-native considerations: Layered design meshes well with cloud practices: microservices can adopt internal layered patterns; managed databases map naturally to the persistence layer; and infrastructure concerns (observability, scaling) can be addressed per layer (metrics for controllers, tracing for services, performance testing for repositories).

Keep controllers thin; validate only what’s necessary to create a proper request model.

Keep services focused on business rules and orchestration; avoid persistence or formatting concerns.

Define repository interfaces that express business operations, not storage operations.

Treat the database as an implementation detail; package queries behind repositories.

Use automated tests targeting each layer: unit tests for services, integration tests for repositories, and end-to-end tests for flows.

Avoid premature abstraction; extract interfaces once you have stable responsibilities.

AWS Services

Deployments

Frontend

Deploying frontend apps should feel predictable, repeatable, and fast. This guide shows you step-by-step how to deploy React and Next.js applications on <a href="https://aws.amazon.com/amplify/" target="_blank" rel="noreferrer">AWS Amplify</a>, from connecting your Git repo to setting custom domains and production best practices. If you're a junior to mid frontend or full stack developer, you'll finish this tutorial knowing how to ship safely to production using AWS Amplify's hosting and CI/CD features.

AWS Amplify is a managed set of services and tools from AWS for building, deploying, and hosting modern web and mobile apps. For frontend developers it provides:

Analogy: think of Amplify as a managed hosting bakery, it bakes and serves your app from source control without you running the oven.



Typical flow when deploying with Amplify:

Deploying a React.js app on AWS Amplify (step-by-step)

This is the most common scenario: a create-react-app or Vite-based SPA.

Amplify supports Next.js with key features like SSR, SSG, and ISR. You can deploy both static exports and server-side features. Amplify runs a build phase and can serve SSR pages via serverless functions.

Edge functions are lightweight serverless functions that run on the CDN edge (CloudFront Lambda@Edge / CloudFront Functions). Amplify provides integrations for edge-like behaviors, but native true-edge deployments are evolving on AWS.

If you need advanced edge compute, evaluate CloudFront Functions or Lambda@Edge directly or Vercel for a more mature edge runtime for Next.js.

Build settings and&nbsp;<code><editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">amplify.yml</editorjs-style></code>&nbsp;explained

Amplify uses <editorjs-style style="background-color: #f5f7fa;
 color: #d63384;
 padding: 2px 6px;
 border-radius: 4px;
 font-family: &quot;Fira Code&quot;, &quot;JetBrains Mono&quot;, monospace;
 font-size: 0.95em;
 white-space: nowrap;">amplify.yml</editorjs-style> to know how to build and publish your app. You can customize install, prebuild, build, and postBuild phases.

Use Amplify Console to set environment variables per branch. These are injected at build time and (for serverless builds) available at runtime for SSR functions.

Using Route 53 is usually the easiest option because Amplify can automatically handle DNS records and SSL validation.

Steps to add a custom domain via Route 53:

If your DNS is managed outside Route 53, you’ll need to manually add the CNAME or A records shown by Amplify and complete domain validation yourself.

Amplify integrates directly with GitHub. Core flow:

Setting up GitHub Actions is optional because Amplify provides hosting + CI. However, some teams prefer running tests in GitHub Actions and only letting Amplify handle the build/publish step.

Performance, caching, and security best practices

When NOT to use Amplify (limitations &amp; alternatives)

Choose Amplify when you want speed-to-market, integrated hosting, and AWS-native tooling. Choose alternatives when you need extreme customization, specialized edge runtimes, or custom server infra.

How to deploy frontend apps like ReactJs, NextJs on AWS Amplify?

CI/CD for static and server-rendered apps

Easy custom domain and TLS certificate management

Integration with backend features (Auth, APIs, Storage) through the Amplify framework (optional)

You want Git-based deploys and managed hosting with minimal infra work

Your app is primarily static or server-side rendered by frameworks like Next.js

You choose AWS native tooling and expect easy integration with other AWS services

Developer pushes code to Git (GitHub/GitLab/Bitbucket)

Amplify pulls the repo, runs the build commands in a build container

Built assets are stored and served via Amplify Hosting + CloudFront distribution

Hosting: stores artifacts and wires up a managed CloudFront distribution

Domain: Amplify provisions a TLS cert and integrates with Route 53 or your DNS provider

Latest Stories

Spotlight

Top Picks

Exclusive

Explore by Categories

Learn Coding

Build Projects

System Design

Computer Science

Jobs

Technology

University News

Market Trends

A growing learning platform for future software engineers

1080+

100+

20+

10+

500+

Latest This Week

In Focus