DEV Community: Tisankan

What I Learned Building a Production LMS with Node.js, MongoDB & AWS in 2026

Tisankan — Mon, 10 Aug 2026 04:45:00 +0000

Building an LMS looks simple at the beginning.

You need users, classes, payments, attendance, recordings, homework, notifications, and reports.

Then you move into production.

Suddenly, you are dealing with authentication, permissions, concurrent requests, payment verification, background jobs, database indexes, cloud costs, logging, deployments, backups, and uptime.

I have been working on a production LMS used across web and mobile, where students attend live classes, tutors manage academic activities, payments are processed online, and several services need to work together reliably.

This post covers the technical decisions that worked, the problems that became more important as the system grew, and what I would change if I started the platform again today.

1. The Architecture

Our main stack includes:

Node.js
NestJS
MongoDB
AWS
Cloudflare
Docker
React / Next.js
Flutter

At a high level, the architecture looks like this:

                    Students / Tutors
                           |
                 +---------+---------+
                 |                   |
                 v                   v
             Web App             Mobile App
          React / Next.js          Flutter
                 |                   |
                 +---------+---------+
                           |
                           v
                       Cloudflare
                           |
                           v
                  Node.js / NestJS API
                           |
          +----------------+----------------+
          |                |                |
          v                v                v
       MongoDB        AWS Services     External APIs
                         |
                +--------+--------+
                |        |        |
                v        v        v
                S3      SES   CloudFront

This architecture has worked well for us.

But the interesting part is not the technology itself.

The important part is how you design the system around it.

2. Node.js Was Not the Problem

One question I often hear is:

Can Node.js handle a serious production system?

For this type of workload, yes.

A typical LMS performs a large amount of I/O work.

Examples include:

Reading student profiles
Fetching timetables
Loading class information
Processing attendance
Checking enrollments
Verifying payments
Loading recordings
Sending notifications
Calling external APIs
Reading and writing database records

Node.js handles this type of workload well.

The bigger performance problems usually come from:

Poor database queries
Missing indexes
Too many database round trips
Unnecessary API calls
Blocking work inside request handlers
Poor background job design
Large payloads
Weak caching strategies

A slow API does not automatically mean your runtime is slow.

Consider a query like this:

await Student.find({
  instituteId,
  status: "ACTIVE",
  classIds: classId,
});

It looks harmless.

But as the collection grows, the wrong indexing strategy can make this request increasingly expensive.

A suitable index might look like:

studentSchema.index({
  instituteId: 1,
  status: 1,
  classIds: 1,
});

Of course, indexes should be designed around your actual query patterns and verified using query execution statistics.

The lesson is simple:

Fix the real bottleneck before replacing the entire technology stack.

Moving from Node.js to another runtime will not fix an unindexed database query.

3. MongoDB Worked Well, but Schema Design Still Matters

MongoDB is easy to start with.

That flexibility can also create problems if you treat schema design as optional.

It is not optional.

Imagine storing every attendance record inside a student document:

{
  "studentId": "ST001",
  "attendance": [
    {},
    {},
    {},
    {}
  ]
}

This might look convenient when the system is small.

It becomes harder to manage when students accumulate large amounts of historical data.

For frequently growing operational data, I prefer dedicated collections.

For example:

students
tutors
classes
enrollments
attendance
payments
recordings
homework
notifications
audit_logs

This makes it easier to:

Index the data correctly
Query records independently
Paginate history
Archive old records
Maintain auditability
Avoid endlessly growing documents

MongoDB gives you flexibility.

It does not remove the need for database architecture.

4. Attendance Is More Complex Than It Looks

An LMS attendance flow sounds simple:

Student joins class
       |
       v
Mark present

Production requirements make it much more complicated.

You may need to know:

When the class started
When the student joined
Whether the student joined late
How many minutes late they were
Whether the tutor joined
Whether the student disconnected and rejoined
Whether an attendance record already exists
Whether the class session is actually valid
Whether the student is enrolled in the class

Now concurrency matters.

Two requests arriving almost at the same time should not create two attendance records.

This pattern is risky:

const attendance = await Attendance.findOne({
  studentId,
  classId,
  sessionId,
});

if (!attendance) {
  await Attendance.create(data);
}

There is a gap between the read and the write.

Two concurrent requests can both see no record and both attempt to create one.

I prefer protecting the invariant at database level:

attendanceSchema.index(
  {
    studentId: 1,
    classId: 1,
    sessionId: 1,
  },
  {
    unique: true,
  },
);

Then the application handles duplicate key conflicts safely.

Application checks are useful.

Database constraints are stronger.

5. Payments Must Be Idempotent

Never assume a payment callback will arrive only once.

Payment providers can retry callbacks.

Network failures happen.

Your API can retry.

Users can refresh pages.

Workers can retry failed jobs.

Imagine this flow:

Payment successful
       |
       v
Store payment
       |
       v
Activate enrollment
       |
       v
Create invoice
       |
       v
Update balance

If the same transaction is processed twice, the consequences can be serious.

Every payment should have a unique reference from the payment provider or your own transaction system.

A basic duplicate check may look like:

const existingPayment = await Payment.findOne({
  gatewayTransactionId,
});

if (existingPayment) {
  return existingPayment;
}

Then enforce uniqueness at database level:

paymentSchema.index(
  {
    gatewayTransactionId: 1,
  },
  {
    unique: true,
  },
);

For more complex payment flows, I also want the transaction state machine to be explicit.

For example:

PENDING
   |
   +----> PAID
   |
   +----> FAILED
   |
   +----> CANCELLED

A confirmed payment should not accidentally move backwards because a delayed callback arrived later.

Idempotency is one of the most important patterns in any system that handles money.

6. Do Not Put Everything Inside the API Request

A common early architecture looks like this:

await createEnrollment();
await sendEmail();
await sendSMS();
await sendNotification();
await generateInvoice();
await updateAnalytics();

return response;

It works during development.

But now the user is waiting for every downstream service.

If the SMS provider takes four seconds to respond, your endpoint may also take four extra seconds.

If the email provider fails, should the entire enrollment fail?

Usually, no.

A better architecture is:

API Request
    |
    v
Validate Request
    |
    v
Critical Database Operation
    |
    v
Return Response
    |
    v
Background Queue
    |
    +--> Email
    |
    +--> SMS
    |
    +--> Push Notification
    |
    +--> Analytics
    |
    +--> Non-critical processing

The synchronous request should handle work required to guarantee the main business operation.

Non-critical work should move to background processing.

This improves:

API latency
Reliability
Retry handling
Failure isolation
User experience

It also gives you a better place to manage external provider failures.

7. Cloudflare Became an Important Layer

Cloudflare is not only DNS.

For a public platform, it can provide several useful controls before traffic reaches your application.

Examples include:

DNS
TLS
CDN
DDoS protection
Web Application Firewall
Rate limiting
Bot protection
Caching

The request path becomes:

Internet
   |
   v
Cloudflare
   |
   v
AWS / Application Infrastructure
   |
   v
Node.js API

Rate limiting is especially important for sensitive endpoints.

Examples:

POST /auth/login
POST /auth/password-reset
POST /auth/send-otp
POST /register
POST /payments/verify

These endpoints should not accept unlimited requests from the same source.

The exact rate limits depend on the endpoint and your users.

The key point is to protect expensive and sensitive operations before abuse becomes a production issue.

8. AWS Cost Is Also an Architecture Problem

AWS gives you many ways to solve the same problem.

That flexibility is useful.

It can also become expensive when services are added without understanding how billing behaves at scale.

I mentally separate infrastructure into three categories.

Critical

Services required for the product to function.

Compute
Database
Object storage
Backups
Networking

Operational

Services required to operate the product reliably.

Monitoring
Logging
Alerts
CI/CD
Security tooling

Optional

Services that provide convenience but are not always required immediately.

Before adding a new managed service, I ask:

What exact problem does this solve?
Can our existing infrastructure solve it?
What happens when usage increases 10x?
What is the expected monthly cost?
What does data transfer cost?
How difficult is it to migrate away later?
Is the operational saving worth the additional cost?

Cloud architecture is also cost architecture.

A solution is not scalable if the business cannot afford the scaling curve.

9. Logging Changed How We Debug Production

During development, this is common:

console.log(error);

That is not enough for a production platform.

Logs need context.

This log is not very useful:

Payment failed

A structured event is much easier to investigate:

{
  "level": "error",
  "event": "PAYMENT_VERIFICATION_FAILED",
  "studentId": "ST001",
  "transactionId": "TX12345",
  "provider": "payment_gateway",
  "requestId": "REQ-8F23A1",
  "timestamp": "2026-08-10T04:00:00Z"
}

Now the operations team can answer useful questions.

What happened?
When did it happen?
Which user was affected?
Which transaction failed?
Which request triggered it?
Which external service was involved?

I also like carrying a request or correlation ID across services.

For example:

Client Request
     |
     | requestId: REQ-8F23A1
     v
API
     |
     +--> Database log
     |
     +--> Payment log
     |
     +--> Background job
     |
     +--> Notification log

When something breaks, one ID can help trace the entire flow.

10. Authentication and Authorization Are Different Problems

Authentication answers:

Who is this user?

Authorization answers:

What is this user allowed to do?

They should not be treated as the same thing.

An LMS can have roles such as:

Student
Tutor
Academic Coordinator
Student Consultant
Finance Staff
Administrator
Super Administrator

All of these users may be authenticated.

They should not have the same capabilities.

A system built entirely around checks like this can become difficult to maintain:

if (user.role === "ADMIN") {
  // allow action
}

As the product grows, I prefer permissions that represent capabilities.

For example:

class.create
class.view
class.update

attendance.view
attendance.update

payment.view
payment.verify

recording.view
recording.manage

student.view
student.update

user.permission.manage

Roles then become collections of permissions.

Tutor
  class.view
  attendance.view
  homework.create
  homework.grade
  recording.view

Finance Staff
  payment.view
  payment.verify
  invoice.view

This model scales better when responsibilities change.

It also reduces the temptation to give a user a powerful role just because they need one extra action.

11. Validate Data at the API Boundary

Frontend validation improves user experience.

It is not a security boundary.

Anyone can call your API directly.

That means the backend must validate incoming data independently.

For example:

const schema = Joi.object({
  classId: Joi.string().required(),
  studentId: Joi.string().required(),
  amount: Joi.number().positive().required(),
});

I prefer this flow:

Request
   |
   v
Validation
   |
   v
Authentication
   |
   v
Authorization
   |
   v
Controller
   |
   v
Service
   |
   v
Database / External Services

Your service layer should receive structurally valid data.

This keeps business logic cleaner and reduces defensive checks throughout the codebase.

12. Keep Controllers Small

One backend pattern I strongly prefer is:

Controller
    |
    v
Service
    |
    v
Repository / Database

Controllers should coordinate HTTP concerns.

They should not become the entire application.

This becomes difficult to maintain:

@Post()
async create() {
  // validate request
  // query student
  // check enrollment
  // verify payment
  // create enrollment
  // send notification
  // send email
  // create audit log
  // update analytics
}

A cleaner controller might look like:

@Post()
async create(@Body() dto: CreateEnrollmentDto) {
  return this.enrollmentService.create(dto);
}

Then the service owns the business process.

For example:

@Injectable()
export class EnrollmentService {
  async create(dto: CreateEnrollmentDto) {
    const student = await this.getStudent(dto.studentId);

    await this.assertCanEnroll(student, dto.classId);

    const enrollment = await this.createEnrollment(dto);

    await this.queuePostEnrollmentTasks(enrollment);

    return enrollment;
  }
}

This improves:

Testability
Readability
Reuse
Debugging
Maintenance

The service should still be kept focused.

A single 2,000-line service is not better than a 2,000-line controller.

13. Observability Is More Than CPU and RAM

A server showing:

CPU: 20%
RAM: 40%

does not mean the application is healthy.

Those metrics are useful, but they are only part of the picture.

For a production LMS, I care about metrics such as:

API response time
API error rate
Database latency
Slow queries
Failed background jobs
Queue depth
Payment verification failures
Login failures
SMS failures
Email failures
External API latency
Application restarts
Memory growth
Disk usage
Availability

I also want alerts based on useful thresholds.

For example:

5xx rate > normal threshold
Payment callback failures increasing
Queue backlog continuously growing
Database latency suddenly increasing
Application restarting repeatedly
Storage nearing capacity

The goal is simple.

I want the engineering team to know about an important problem before students or tutors need to report it.

14. Background Jobs Need Retry Rules

Moving work to a queue does not automatically make it reliable.

You also need to decide what happens when a job fails.

For example:

Send SMS
   |
   v
Provider timeout
   |
   v
Retry
   |
   v
Provider timeout
   |
   v
Retry later

Not every job should retry forever.

A useful policy might look like:

Attempt 1: immediately
Attempt 2: after 30 seconds
Attempt 3: after 2 minutes
Attempt 4: after 10 minutes
Final: mark failed and alert if important

This is a simplified example.

The correct policy depends on the operation.

Payment processing, email delivery, recording synchronization, and analytics may all need different retry behaviour.

You should also make jobs idempotent whenever possible.

A retried job should not accidentally create duplicate data.

15. Audit Logs Are Worth Adding Early

Production systems eventually reach a point where somebody asks:

Who changed this?

You need an answer.

For important administrative actions, I want an audit event containing data such as:

{
  "actorId": "USR001",
  "action": "STUDENT_STATUS_UPDATED",
  "entityType": "student",
  "entityId": "ST001",
  "previousValue": {
    "status": "ACTIVE"
  },
  "newValue": {
    "status": "SUSPENDED"
  },
  "timestamp": "2026-08-10T04:30:00Z"
}

Examples of operations worth auditing include:

Payment changes
Refund actions
Student status changes
Enrollment changes
Role changes
Permission changes
Tutor changes
Manual attendance changes
Important configuration changes

Application logs tell you what the system did.

Audit logs tell you what users and administrators changed.

They solve different problems.

16. Security Needs Multiple Layers

There is no single "security feature" that makes a platform secure.

For a production LMS, I think about security across multiple layers.

Edge

Cloudflare
WAF
Rate limiting
DDoS protection
Bot controls

Application

Authentication
Authorization
Input validation
Secure session/token handling
Idempotency
Safe error handling

Data

Least privilege
Encryption
Backups
Database access controls
Audit logs

Infrastructure

Network restrictions
Secrets management
Patch management
Container security
Monitoring

Development Process

Dependency scanning
Code review
CI/CD controls
Secret scanning
Environment separation

Security becomes much easier when these controls are part of the architecture from the beginning.

17. Separate Development, Staging, and Production

One lesson that becomes obvious as a system grows is that environments need clear boundaries.

At minimum, I want:

Local
Development / Staging
Production

Production credentials should never be casually used during development.

The same applies to:

Databases
Payment gateway credentials
SMS credentials
Email credentials
Storage buckets
API keys
Webhooks

Environment separation protects real users and real data.

It also makes deployment testing much safer.

18. Backups Are Only Useful if You Can Restore Them

"Backups enabled" is not enough.

The real question is:

Can we restore the system successfully when we need to?

A production backup strategy should consider:

Database backups
File/object backups
Retention periods
Restore procedures
Restore testing
Recovery time objectives
Recovery point objectives

If your team has never tested a restore, you do not fully know whether your backup process works.

Recovery should be treated as an engineering workflow, not just a checkbox.

19. What I Would Change If I Started Again

If I rebuilt the LMS today, I would make several decisions earlier.

1. Design background jobs from day one

Email, SMS, notifications, recordings, analytics, and other non-critical processing should not block normal API requests.

2. Add structured logging immediately

Debugging production without useful logs wastes engineering time.

3. Add correlation IDs

Tracing one request across the API, workers, database operations, and external services becomes much easier.

4. Design permissions before adding many roles

Role-only authorization becomes harder to maintain as the organization grows.

5. Create indexes from real query patterns

Do not add indexes randomly.

Measure how the application actually reads data.

6. Make payment operations idempotent

Anything involving money must handle duplicate callbacks and retries safely.

7. Add audit logs for important changes

You need to know who changed critical data.

8. Treat infrastructure cost as an engineering metric

A technically impressive architecture that costs more than the business can support is not a good architecture.

9. Test failure paths

Do not test only the happy path.

Test what happens when:

MongoDB is slow
SMS provider fails
Email provider fails
Payment callback is duplicated
Worker crashes
External API times out
User sends the same request twice

10. Keep the architecture understandable

A small team should not need 20 services just because microservices are popular.

Complexity must solve a real problem.

20. Would I Still Choose Node.js?

For this type of system, yes.

I would still be comfortable choosing a stack such as:

Node.js
NestJS
MongoDB or PostgreSQL
AWS
Cloudflare
Docker

Node.js provides good development speed and fits I/O-heavy workloads well.

Would Spring Boot also work?

Yes.

Would Django work?

Yes.

The framework is rarely the main reason a production platform succeeds or fails.

The surrounding engineering decisions matter more.

A badly designed Spring Boot application can fail.

A badly designed Node.js application can fail.

A well-designed version of either can handle serious production workloads.

21. MongoDB or PostgreSQL If I Started Today?

This is one area where I would spend more time on the data model before choosing.

MongoDB works very well when the application's data naturally benefits from document-oriented modelling and flexible structures.

PostgreSQL becomes attractive when the system has increasingly relational workflows such as:

Students
Classes
Enrollments
Invoices
Payments
Attendance
Academic periods
Permissions
Reporting

For a new LMS, I would evaluate these relationships carefully before making the database decision.

The correct answer is not:

MongoDB is always better

or:

PostgreSQL is always better

The better question is:

Which data model makes the core business rules easier to enforce, query, report on, and maintain?

That is the database decision I care about now.

22. The Architecture I Prefer Today

If I were starting a similar platform today, I would keep the first production architecture relatively simple.

                     Cloudflare
                         |
                         v
                 Web / Mobile Clients
                         |
                         v
                  API Load Balancer
                         |
                         v
                Node.js / NestJS API
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
      Database        Queue/Cache      AWS S3
          |              |
          |              v
          |          Background Workers
          |              |
          |      +-------+-------+
          |      |       |       |
          |      v       v       v
          |     SMS     Email   Other APIs
          |
          v
     Backups / Monitoring

I would not introduce additional architectural complexity until the product demonstrates a clear need for it.

A modular monolith can be a very good architecture.

You can still have:

Clear module boundaries
Background workers
Independent queues
Strong observability
Horizontal scaling
Good security controls

without immediately splitting everything into microservices.

Final Thoughts

Building production software changed how I evaluate technology.

I care less about questions like:

Which framework is fastest?

I care more about:

Can we debug it?

Can we secure it?

Can we scale it?

Can we recover from failure?

Can another developer maintain it?

Can we observe it?

Can the business afford to operate it?

Those questions matter much more once real students, tutors, classes, and payments depend on the platform.

The biggest lesson for me has been this:

Production architecture is not about choosing the most powerful technology. It is about making good engineering decisions around the technology you already have.

If you were building an LMS today, which backend would you choose?

Node.js + MongoDB, Node.js + PostgreSQL, Spring Boot + PostgreSQL, Django, or something else?

I would especially like to hear from developers who have operated these stacks in production.

Google just made n8n look expensive 💰

Tisankan — Thu, 04 Dec 2025 03:58:23 +0000

The landscape of business automation has just shifted beneath our feet.

For years, the debate has been between user-friendly tools like Zapier and powerful, developer-centric platforms like n8n. But the release of Google Workspace Studio has introduced a third, massive variable: hyper-intelligent, AI-native automation that is already included in the software suite used by 3 billion people.

As an automation strategist who has built hundreds of workflows, I’ve been analyzing this shift. This isn't just about features; it’s about the fundamental difference between "connecting apps" and "deploying agents."

If your organization is paying $20 to $50 per user for n8n Cloud, or spending valuable engineering hours maintaining self-hosted instances, you need to pay attention.

⚡ The Executive Summary (TL;DR)

If you're short on time, here is the critical breakdown:

The Disruption: Google Workspace Studio is now included free with Business and Enterprise plans, utilizing Gemini 3 to build AI agents via natural language.
The Google Advantage: It requires zero coding skills, creates agents that "reason" rather than just follow scripts, and operates strictly within Google’s enterprise security perimeter.
The n8n Advantage: n8n remains superior for complex, multi-step logic involving non-Google apps, complex data transformation, and scenarios requiring self-hosted infrastructure.

🛠️ The Evolution: From Pipelines to Agents

The Legacy of Connector-Based Automation

Tools like n8n and Zapier are built on "Triggers" and "Actions."

Trigger: A new email arrives.
Action: Parse the body.
Action: Add to a spreadsheet.

This is deterministic automation. It is powerful, but rigid. If the email format changes, the automation breaks. n8n excels here because it allows developers to write JavaScript directly into the nodes, offering infinite flexibility, but it demands technical literacy.

Enter the AI Agent Era

Google Workspace Studio represents Agentic Automation. Instead of building a pipeline, you define a goal.

"Monitor my inbox for unhappy customers, draft a polite reply based on our refund policy in Drive, and log the issue in Sheets."

The AI figures out the "how." This shift from explicit instruction (n8n) to intent-based execution (Google) is vital.

🚀 Why Google Workspace Studio is a Game Changer

1. The Zero-Cost Proposition

The most immediate threat to n8n is economic. This is a battle between "Already Paid For" and "Additional Line Item."

For a company with 100 employees, n8n Cloud can cost thousands annually. Google Workspace Studio is included in the plans companies are already paying for. CFOs will look at this simple math: Why pay for an external tool when our existing infrastructure does it for free?

2. Native Integration Dominance

While n8n connects to 400+ apps, Google owns the ecosystem where work actually happens.

Context Awareness: A Google Agent inherently understands the context of a Google Doc or a Gmail thread.
No Context Switching: The automation lives in the side panel of Gmail or Docs.

3. Natural Language vs. Node Spaghetti

n8n requires you to think like a programmer (JSON, webhooks, error handling). Google Studio requires you to think like a manager.

n8n: Get Row -> IF function -> HTTP Request -> Set Variable
Google: "When a project status changes to 'Done' in Sheets, email the stakeholder."

4. Enterprise-Grade Security

Security teams often view third-party automation tools as "Shadow IT." Google Workspace Studio operates under the same DLP (Data Loss Prevention) controls as the rest of the workspace. Your data isn't leaving the Google tenant to be processed by a third-party AI.

⚖️ Where n8n Still Wins

Despite the disruption, n8n is not dead. It remains the superior tool for developers and complex architectures.

Self-Hosting: n8n’s "fair-code" model allows you to host it on your own infrastructure. For companies with data sovereignty requirements, this is non-negotiable.
Connectivity: If your stack isn't 100% Google (e.g., Salesforce, HubSpot, Custom SQL), n8n is the better "glue."
Deterministic Control: Sometimes you don't want AI to "interpret" your instructions. For financial transactions, you want the exact logic of code.

🔮 The Verdict

Google isn't just entering the automation space. They're making it accessible to everyone.

The same way ChatGPT democratized AI for consumers, Workspace Studio is doing that for business automation.

For 80% of internal workflows (approvals, summaries, simple data entry), Google Workspace Studio is the winner due to cost and ease.
For complex DevOps or cross-platform orchestration, n8n retains its crown.

👋 Want to read more?

I break down the full feature comparison and migration strategy in the full article on my site.

👉 Read the full article at Tisankan.dev

MediMan: 800+ users in 15 days – building healthcare beyond boundaries 🚀

Tisankan — Mon, 01 Dec 2025 06:02:05 +0000

An app my team and I built just hit 800+ users in 15 days 🚀

The wild part? We’re waiving all booking fees until Dec 5th.

Sri Lanka is in the middle of a cyclone crisis right now. People need access to doctors – not tomorrow, not after the storm, but right now. So we made a call: free consultations, zero booking fees, no barriers. Stay indoors. Stay safe. Get medical help instantly.

What we’ve done in 15 days:

50+ verified doctors trust MediMan with their practice

800+ patients chose us over traditional clinic-only healthcare

Families can manage everyone’s health from one secure app

What we’re building:

Instant video consultations

Smart doctor discovery based on real needs

Digital prescriptions that pharmacies accept

A medical record vault so nothing gets lost between clinics

Calendar reminders and 24/7 access

Bank-grade security for sensitive health data

Family profiles: one account, unlimited members, separate histories

This isn’t “yet another telemedicine app.”
We’re rebuilding the patient experience from scratch with family health management at the core.

If you’re into:

Telemedicine / healthtech

Scalable Flutter + Node/Python backends

Infra for sensitive data (security, audit, uptime)

Product stories from 0 → 800 users

…I’d love to have you in this squad.

Links:

User app: https://mediman.life/userapp.html

Website: https://www.mediman.life

How would you evolve a telehealth product like this (features, infra, growth) while keeping privacy and reliability as non‑negotiables?

healthtech #telemedicine #startup #flutter #node #devops #security #productengineering

Angular SEO Mastery: How I Fixed SEO for Our Angular SPA Using AWS Amplify + Prerender.io

Tisankan — Sun, 30 Nov 2025 10:03:08 +0000

Single-page applications (SPAs) built with frameworks like Angular offer fantastic user experiences but often struggle with search engine optimization (SEO). The client-side rendering that makes SPAs so dynamic can be a major obstacle for web crawlers that rely on server-rendered HTML. This is the story of how I fixed SEO for our Angular SPA using AWS Amplify + Prerender.io, transforming our application from an SEO black hole into a discoverable asset. This guide details the challenges we faced, the solutions we implemented, and the best practices we adopted to achieve significant organic traffic growth.
TL;DR

Angular SPAs pose SEO challenges due to client-side rendering. We solved this problem by leveraging AWS Amplify for hosting and deployment, coupled with Prerender.io for pre-rendering our application’s critical pages. This combination enabled search engines to effectively crawl and index our content. The result was a dramatic improvement in organic search rankings and a substantial increase in website traffic. This approach involves configuring Prerender.io middleware, setting up AWS Amplify build processes, and optimizing content for search engines. Through careful planning and execution, we were able to transform our SPA into an SEO powerhouse.
Introduction

In today’s digital landscape, a strong SEO presence is crucial for any business seeking online visibility. For companies relying on Angular SPAs, achieving this visibility can be particularly challenging. Search engines like Google prioritize websites that offer readily crawlable and indexable content. Traditional Angular SPAs, with their heavy reliance on JavaScript for rendering content, often fall short in this regard. The core issue lies in the fact that search engine crawlers may not execute JavaScript effectively, leading to incomplete or inaccurate indexing of the website’s content.

Our journey began with a promising Angular SPA that delivered an exceptional user experience. However, despite our best efforts in content creation and on-page optimization, our organic search traffic remained disappointingly low. We quickly realized that the SPA’s client-side rendering was hindering search engine crawlers from properly understanding and indexing our website. This realization led us to explore various solutions, ultimately culminating in the successful implementation of AWS Amplify and Prerender.io.

This comprehensive guide details our experience of how I fixed SEO for our Angular SPA using AWS Amplify + Prerender.io. We’ll walk you through the initial challenges, the research process, the implementation steps, and the ongoing optimization strategies that led to a significant improvement in our SEO performance. Whether you’re a seasoned Angular developer or a marketing professional seeking to enhance your SPA’s visibility, this guide provides practical insights and actionable steps to help you achieve your SEO goals.
What Works: The Power of Prerendering and AWS Amplify

The key to unlocking SEO potential for Angular SPAs lies in addressing the fundamental issue of client-side rendering. Search engines need to be able to access and understand the content of your website, and if that content is only rendered after JavaScript execution, they may struggle to index it effectively. This is where prerendering comes into play. Prerendering involves generating static HTML versions of your website’s pages at build time or on demand, which can then be served to search engine crawlers and other bots. This ensures that crawlers receive fully rendered content, allowing them to index your website accurately and improve its search engine rankings.

Prerender.io is a popular service that provides on-demand prerendering for SPAs. It works by intercepting requests from search engine crawlers and other bots, rendering the corresponding page in a headless browser, and then serving the static HTML to the crawler. This process is transparent to the user, who continues to experience the dynamic functionality of the Angular SPA. Prerender.io supports various frameworks, including Angular, React, and Vue.js, and offers flexible integration options to suit different development workflows.

AWS Amplify provides a comprehensive platform for building, deploying, and hosting full-stack web and mobile applications. Its features include serverless functions, authentication, storage, and CI/CD pipelines. In the context of Angular SPAs, AWS Amplify simplifies the deployment process and provides a scalable and reliable hosting environment. Its built-in CI/CD capabilities allow for automated builds and deployments, ensuring that your website is always up-to-date with the latest changes.

The combination of AWS Amplify and Prerender.io offers a powerful solution for optimizing the SEO of Angular SPAs. AWS Amplify provides the infrastructure for hosting and deploying the application, while Prerender.io ensures that search engine crawlers receive fully rendered HTML content. This approach allows you to leverage the benefits of both technologies, resulting in improved search engine rankings, increased organic traffic, and a better overall user experience. We found that using a serverless approach, as described in this AWS blog post, was particularly helpful in scaling our application. Furthermore, integrating a dynamic rendering strategy as recommended by Google, became much more manageable with this setup.

In our experience, implementing this strategy yielded significant results. We observed a dramatic increase in the number of pages indexed by search engines, as well as a noticeable improvement in our website’s search engine rankings for relevant keywords. This, in turn, led to a substantial increase in organic traffic, ultimately driving more leads and conversions for our business. The enhanced crawlability also allowed us to better leverage structured data, improving our rich snippet presence in search results.
Deep Dive: Understanding the Technical Details

To fully grasp how I fixed SEO for our Angular SPA using AWS Amplify + Prerender.io, it’s essential to delve into the technical details of the implementation. This involves understanding how Prerender.io works, how to configure it within your Angular application, and how to integrate it with AWS Amplify’s build and deployment process.

Prerender.io operates as a middleware that intercepts requests from search engine crawlers. When a crawler requests a page from your Angular SPA, the middleware checks the user agent to determine if it’s a bot. If it is, the middleware forwards the request to the Prerender.io service, which renders the page in a headless browser. The resulting HTML is then returned to the crawler, allowing it to index the page’s content. For regular users, the request is passed through to the Angular SPA as normal, ensuring that they continue to experience the dynamic functionality of the application. This approach ensures that human users always receive the latest version of the application, while search engine bots see the prerendered HTML snapshot. Furthermore, we found that optimizing our Cumulative Layout Shift (CLS) score dramatically improved the perceived loading speed of the pre-rendered content.

Configuring Prerender.io within your Angular application typically involves adding middleware to your server or using a client-side library. The specific implementation will depend on your application’s architecture and hosting environment. In our case, we opted for a middleware approach, which allowed us to intercept requests at the server level and redirect them to Prerender.io as needed. This involved installing the Prerender.io middleware package and configuring it to identify search engine crawlers based on their user agents. The configuration also included specifying the Prerender.io API token and any other relevant settings.

Integrating Prerender.io with AWS Amplify requires configuring the build process to include the necessary middleware and dependencies. This can be achieved by modifying the amplify.yml file, which defines the build and deployment settings for your AWS Amplify project. The amplify.yml file allows you to specify custom build commands, environment variables, and other settings that are specific to your application. In our case, we added a build command to install the Prerender.io middleware package and configure it to run as part of the application server. We also set environment variables for the Prerender.io API token and other relevant settings. It’s also crucial to ensure that your Angular build process generates a production-ready build that is optimized for performance. This includes minifying JavaScript and CSS files, optimizing images, and enabling gzip compression.

A crucial aspect of this setup is ensuring proper cache invalidation. When content changes, you need to ensure that Prerender.io updates its cached version of the page. This can be achieved by implementing a cache invalidation strategy that triggers a re-render of the page whenever the content is updated. This can be done programmatically through the Prerender.io API or by using a content management system (CMS) that integrates with Prerender.io.
Best Practices for Angular SEO with Amplify and Prerender.io

While implementing AWS Amplify and Prerender.io is a significant step towards improving your Angular SPA’s SEO, it’s crucial to follow best practices to maximize your results. These best practices encompass various aspects of SEO, including content optimization, technical SEO, and performance optimization. By adhering to these guidelines, you can ensure that your website is not only crawlable and indexable but also provides a positive user experience, which is a key ranking factor for search engines.

Content Optimization: High-quality, relevant content is the foundation of any successful SEO strategy. Focus on creating content that is valuable to your target audience and addresses their specific needs and interests. Conduct keyword research to identify the terms that your audience is using to search for information related to your business, and incorporate those keywords naturally into your content. Avoid keyword stuffing, which can negatively impact your search engine rankings. In addition to optimizing your content for keywords, focus on creating engaging and informative content that keeps users on your website longer and encourages them to share it with others. Consider using a tool like Ahrefs or Semrush for keyword research and competitive analysis.

Technical SEO: Technical SEO involves optimizing the technical aspects of your website to make it easier for search engines to crawl and index. This includes ensuring that your website has a clear and logical site structure, using descriptive URLs, creating a sitemap, and implementing proper redirects. Pay close attention to your website’s mobile-friendliness, as mobile-first indexing is now the default for Google. Use Google’s Mobile-Friendly Test tool to check your website’s mobile-friendliness. Also, ensure that your website loads quickly, as page speed is a critical ranking factor. Use Google’s PageSpeed Insights tool to identify areas for improvement in your website’s performance. Implementing XML sitemaps is also vital to help search engines discover your content.

Performance Optimization: Website performance is crucial for both SEO and user experience. A slow-loading website can frustrate users and lead to higher bounce rates, which can negatively impact your search engine rankings. Optimize your website’s performance by minimizing HTTP requests, compressing images, leveraging browser caching, and using a content delivery network (CDN). Consider using a tool like Cloudflare to improve your website’s performance and security. It is also crucial to monitor your application’s performance regularly using tools like Google Analytics and Google Search Console. These tools provide valuable insights into your website’s traffic, rankings, and technical issues. Use this data to identify areas for improvement and track the effectiveness of your SEO efforts.

Schema Markup: Implementing schema markup, also known as structured data, is a powerful way to enhance your website’s visibility in search results. Schema markup provides search engines with additional information about your website’s content, allowing them to display rich snippets in search results. Rich snippets can include things like star ratings, product prices, and event dates, which can make your website stand out from the competition and attract more clicks. Use Google’s Rich Results Test tool to validate your schema markup implementation.

By following these best practices, you can maximize the effectiveness of your Angular SEO strategy and achieve significant improvements in your website’s search engine rankings and organic traffic. Remember that SEO is an ongoing process, and it’s important to continuously monitor your website’s performance and adapt your strategy as needed.
Implementation: Step-by-Step Guide

This section provides a concise step-by-step guide on how I fixed SEO for our Angular SPA using AWS Amplify + Prerender.io. This is a simplified overview, and specific steps may vary based on your project setup.

Set up AWS Amplify: Create an AWS account and initialize an Amplify project in your Angular application. Use the Amplify CLI to connect your project to your AWS account and configure the necessary resources.
Install Prerender.io Middleware: Install the Prerender.io middleware package in your Angular project. This package will intercept requests from search engine crawlers and redirect them to the Prerender.io service.
Configure Prerender.io: Obtain an API token from Prerender.io and configure the middleware with your token. This will allow the middleware to authenticate with the Prerender.io service.
Update `amplify.yml`: Modify the `amplify.yml` file to include the Prerender.io middleware in your build process. This will ensure that the middleware is deployed along with your Angular application.
Deploy to AWS Amplify: Deploy your Angular application to AWS Amplify. The Amplify CI/CD pipeline will automatically build and deploy your application, including the Prerender.io middleware.
Verify Implementation: Use a tool like Google’s Rich Results Test to verify that your website is being prerendered correctly. This will ensure that search engine crawlers are receiving the fully rendered HTML content.

Remember to thoroughly test your implementation to ensure that everything is working as expected. Monitor your website’s performance and SEO metrics to track the effectiveness of your changes. This process can be further streamlined by using Infrastructure as Code (IaC) tools like Terraform to manage your AWS resources.
FAQs: Addressing Common Questions

Here are some frequently asked questions related to implementing AWS Amplify and Prerender.io for Angular SPA SEO:

Q: Is Prerender.io free?
A: Prerender.io offers a free plan with limited usage, as well as paid plans with higher usage limits. The best plan for you will depend on the size and traffic of your website.

Q: Does Prerender.io work with all search engines?
A: Prerender.io is designed to work with all major search engines, including Google, Bing, and Yahoo. It identifies search engine crawlers based on their user agents and serves them the prerendered HTML content.

Q: How does Prerender.io affect website performance?
A: Prerender.io can slightly increase the initial load time for search engine crawlers, as it needs to render the page in a headless browser. However, this impact is typically minimal and is outweighed by the benefits of improved SEO.

Q: Can I use other prerendering solutions with AWS Amplify?
A: Yes, AWS Amplify is compatible with other prerendering solutions, such as server-side rendering (SSR) frameworks like Angular Universal. The choice of prerendering solution will depend on your specific needs and requirements.

Q: How do I handle dynamic content with Prerender.io?
A: Dynamic content can be handled by updating the prerendered content whenever the dynamic content changes. This can be achieved by implementing a cache invalidation strategy that triggers a re-render of the page whenever the content is updated.

Q: What about SEO for logged-in or personalized content?
A: Prerendering personalized content is complex. Generally, focus on prerendering public-facing pages. For logged-in content, ensure proper robots.txt rules to prevent crawling and indexing of sensitive information.

Q: How often should I re-prerender my pages?
A: The frequency of re-prerendering depends on how often your content changes. For frequently updated content, consider implementing a real-time cache invalidation strategy. For less frequently updated content, a daily or weekly re-prerendering schedule may be sufficient.
References

Below are some useful resources to further enhance your understanding of Angular SEO, AWS Amplify, and Prerender.io:

Angular SEO Guide – Official Angular documentation on SEO best practices.
AWS Amplify Documentation – Comprehensive documentation on AWS Amplify features and services.
Prerender.io Documentation – Detailed documentation on Prerender.io integration and configuration.
Google Search Central – Official Google documentation on crawling and indexing.
Web.dev – Google’s resource for building modern web experiences.
Google on Dynamic Rendering – Google’s official guide on dynamic rendering strategies.
Moz SEO Learning Center – A comprehensive resource for learning about SEO.
Ahrefs SEO Basics – A guide to the fundamentals of SEO.
Cloudflare CDN – Information on Content Delivery Networks and their benefits.

Ready to Boost Your Angular SPA’s SEO?

How I fixed SEO for our Angular SPA using AWS Amplify + Prerender.io is a journey that requires careful planning and execution, but the rewards are well worth the effort. By implementing the strategies and best practices outlined in this guide, you can transform your Angular SPA from an SEO liability into a powerful asset that drives organic traffic and generates leads for your business.

Take the first step towards unlocking your Angular SPA’s SEO potential today! Contact us for a free consultation and let our team of experts help you implement a customized SEO strategy that meets your specific needs and goals. Don’t let your Angular SPA remain hidden from search engines. Embrace the power of AWS Amplify and Prerender.io and watch your organic traffic soar. Get started with a free AWS Amplify account and explore the possibilities!

DepShield: Cut Your Node.js Bundle Size by 30-40% in 5 Seconds

Tisankan — Thu, 20 Nov 2025 19:34:07 +0000

DepShield: Cut Your Node.js Bundle Size by 30-40% in 5 Seconds

The Problem We All Face

Your Node.js projects accumulate unused dependencies like technical debt. A typical codebase with 145+ files? You probably have 3-5 packages sitting there doing nothing.

What this costs you:

📦 30-40% bloated bundle sizes
🐌 Slower CI/CD pipelines & Lambda cold starts
🔒 More security vulnerabilities to patch
💰 Wasted disk space and bandwidth

Last week, I built DepShield to solve this problem once and for all.

What is DepShield?

DepShield is a smart dependency analyzer & optimizer for Node.js projects. It automatically detects unused dependencies, shows you exactly how much space you can reclaim, and integrates seamlessly into your CI/CD pipeline.

Think of it as a "linter for your dependencies."

Why DepShield Stands Out

🔍 95%+ Accuracy

AST-based parsing (not fragile regex tricks). It actually parses your code, understands import statements, and identifies what's truly unused.

⚡ Lightning Fast

Scans 100+ files in 2-5 seconds. No waiting around for analysis.

📊 Shows Real Savings

Not just "lodash is unused" — it tells you "lodash is 69.8 KB, you can save 3.3 MB total". Numbers matter.

🎨 Beautiful CLI

Intuitive, emoji-rich output that developers actually want to read.

🚀 CI/CD Ready

JSON export for automation
Exit codes for strict mode
GitHub Actions integration planned
Works in your deployment pipeline

🤝 Zero Production Dependencies

Lightweight and secure. Ships as a single binary.

Quick Start (30 Seconds)

npm install -g depshield depshield scan

From Full-Stack Developer to CTO: My Journey in Tech

Tisankan — Mon, 16 Jun 2025 15:06:16 +0000

Hey DEV Community 👋,

I'm Tisankan Jeyakumar — a passionate full-stack developer and currently serving as CTO @ Yarl Ventures.

I started out as a curious coder and gradually evolved into someone who now builds and scales platforms from the ground up. My focus lies in creating clean, scalable, and user-centric solutions that solve real-world problems.

🧰 My Tech Stack

Frontend: React, Flutter
Backend: Node.js, NestJS, Laravel
Databases: MongoDB, Firebase, PostgreSQL
Tools: Docker, Redis, Prisma, Git, Postman
Cloud: AWS, Oracle Cloud

🚀 What I’m Exploring Now

I'm currently diving deeper into:

Advanced NestJS architecture
Microservices with Prisma ORM
Flutter web + mobile cross-platform best practices

🤝 Let’s Connect

I’m here to learn, share, and collaborate with fellow devs. If you're working on interesting problems or just want to chat tech, feel free to say hi!

Thanks for reading 🙌

webdev #fullstack #cto #nestjs #flutter #cloud #startup #devlife #productivity