DEV Community: Sahil Khurana

AWS API Gateway and Elastic: The Perfect Pair for Seamless API Management

Sahil Khurana — Thu, 18 Jun 2026 05:59:40 +0000

Key takeaways

AWS API Gateway makes the API easier to manage through a single console that eases API organization and management, improves scalability as well as performance, and comes at a lower cost as well as being more secure.
AWS API Gateway is supported by Elasticsearch to offer efficient search and analysis, which makes data indexing fast, real-time analysis possible, and data visualisation insightful, irrespective of the data type.
AWS API Gateway also integrates well with Elastic Observability, thus allowing the easy tracking of API Key metrics/logs in real-time and enhancing the ability to pinpoint problems and also enhancing the drive towards increased API efficiency.

What Is An API Gateway?

This is not complicated at all. API Gateway is, in essence, a gateway - an intermediary layer placed between the client accessing your API and the server responsible for responding to it.

Amazon AWS API Gateway is a product offered by Amazon and serves as a fully-managed implementation of such a gateway. Every request directed either towards a Lambda function, EC2 instance, or even some on-premise infrastructure has to go through this API Gateway first. This is when things like authentication, rate limiting, and validating requests occur, before passing the request on to your actual application.

One thing I really appreciate about this solution is that you do not need to re-invent the wheel anymore - there's no need for developing security layers or anything like that.

Why Integrate AWS API Gateway into Your System?

Early on, a small project can get away with direct API calls and minimal structure. But once you have multiple services, multiple teams, and real traffic , things start breaking in ways that are hard to trace. API Gateway gives you a layer of control that makes all of it manageable.

Here's what that looks like day-to-day:

Everything in one console - instead of chasing logs across five services, you have a single place to see what every API is doing.
Auto-scaling that actually works - when traffic spikes, it adjusts. Built-in caching means repeated requests don't hammer your backend unnecessarily.
Security without the headache - auth, access policies, and fine-grained permissions are built in. Not an afterthought.
Cost controls that matter - throttling and quotas stop a misbehaving client from running up your AWS bill.
CloudWatch integration - your HTTP, REST, and WebSocket logs go straight into CloudWatch with no extra wiring needed.

It also opens up patterns that are harder to pull off otherwise - serverless APIs through Lambda, hybrid setups mixing cloud and on-prem, and API endpoints that IoT devices can hit directly. That last one is surprisingly useful if you're working anywhere near connected hardware.

What is Elasticsearch?

Elasticsearch explained for a layman: Imagine you have a warehouse with countless boxes, and you need to find a particular object there as soon as possible. Then, Elasticsearch is your solution because it knows where everything is located, even without any labels on those boxes.

On the technical side, Elasticsearch is defined as an open-source distributed search engine and analytics engine, which forms the core component of the Elastic Stack. You may feed it with structured logs, unstructured logs, metric data, or geolocation data; it will process it immediately.

The part that actually impressed me when I first used it was how well it handles scale. You start small, and as your data grows, Elasticsearch grows with it. The distributed architecture isn't just a marketing claim - it actually delivers.

They can leverage it for numerous purposes: from application discovery to log analysis, anomaly detection using machine learning to dedicated research pipelines. Coupled with Logstash and Beats for data ingestion and Kibana for visualizations, they will get themselves an observability stack that covers a wider range of use cases than one might think.

Monitoring AWS API Gateway with Elastic Observability

This is the part worth paying attention to.
API Gateway, on its own, generates data. Elastic Observability turns that data into something you can actually act on. The difference sounds subtle until you've spent three hours debugging a latency issue with no clear dashboard to reference - then it becomes very obvious.

Connecting both of these is pretty easy:

Sign up for an Elastic Cloud account and deploy your application with the agent.
From within Elastic, click on Add Integration and search for AWS API Gateway.
Use your AWS credentials - this integration supports access keys, IAM role ARNs, as well as temporary security credentials.
Enable logging in CloudWatch from the API Gateway side, and you're good to go.

Once it's running, you'll have real-time visibility into metrics that actually tell you something useful:

4XXError / 5XXError - Are failures coming from clients or your backend?
Latency / Integration: Latency - Where exactly is time being lost in the request cycle?
CacheHitCount / CacheMissCount - Is your caching setup doing what you think it is?
Count - Total request volume across any time window you care about
DataProcessed - Volume of data moving through your APIs ConnectCount / MessageCount - WebSocket connection and message tracking

The dashboards you get out of the box are genuinely useful, not just pretty. And when you're ready to go deeper, they're easy enough to customize.

Conclusion

There's a version of API management where you're constantly reacting - a service goes down, someone notices, you dig through logs, you eventually figure out what happened. It's exhausting, and it's avoidable.
Connecting AWS API Gateway with Elastic Observability shifts you into a more proactive position. You see what's happening before it becomes a problem. You make decisions based on actual data instead of gut instinct.
For teams that care about reliability - and honestly, all teams should - this is one of the more worthwhile setups you can put in place.

About Innostax

Innostax provides businesses with outsourced resources for their software development through our services or through our staff augmentation program. We primarily serve startups, scaleups, and Digital Agencies, all of which require contracted development experts when they require assistance to augment their Development Team or with a custom solution to build their product, and as a result, do not want to incur the cost and time to set up and manage an internal Dev Team.

Want to see how we deliver scalable, cost-effective Python development without the overhead of an in-house team? We've broken down the full approach - talent sourcing, project onboarding, tech stack decisions, and business outcomes - in detail on the Innostax blog.
Read more: AWS API Gateway and Elastic: The Perfect Pair for Seamless API Management

MEAN Stack and MERN Stack: What’s Best for Your Business Needs?

Sahil Khurana — Wed, 17 Jun 2026 11:43:34 +0000

Main Points

Therefore, MEAN is all about combining MongoDB, Express.js, Angular, and Node.js in a single JavaScript environment. All languages involved use the same programming language, and it definitely makes everything simpler during development. It is perfect when developing scalable web apps.

The difference between MEAN and MERN consists in replacing Angular with React while keeping the rest components identical. MERN allows using React for designing the front-end part of the application, and that makes the process of interface generation faster. It will suit best single-page applications or other web applications that do not aim at the enterprise level.
In general, deciding on MEAN or MERN stack will depend on the specifics of the project that is being developed and the skills of a particular team.

MERN versus MEAN Stack

In a MEAN stack, JavaScript is used for every operation. JavaScript is used to handle database queries. JavaScript is used for writing server-side logic code. The frontend is written using JavaScript as well. In other words, no need to switch between different languages here.

Data handling in the MEAN stack is done by MongoDB. Express.js is used to handle server-side operations. The UI of applications built using a MEAN stack is designed using Angular. Node.js converts JavaScript into server-side code.
A MERN stack works in a similar manner except that React replaces Angular to design the UI of web applications.

What is MEAN Stack Development?

MEAN brings together four technologies that work well together:

MongoDB: This NoSQL database doesn't lock you into rigid table structures. Everything's stored in JSON-like documents, so you can adjust your data model without massive migrations. Really flexible when requirements change.

Express.js: Minimalist server framework. Nothing but what is needed for your server logic. Doesn’t make you configure everything endlessly just to get started.

Angular: Created by Google to be a full-featured frontend framework. It’s quite prescriptive in its way of doing things. Some people like the orderliness. Other people dislike being constrained.

Node.js: Executes JavaScript code on servers using Google’s V8 engine. Good at dealing with asynchronous processes, so your app stays responsive even under load.

MEAN Stack: The Real Talk

What Works: Code reusability across platforms cuts development time significantly. Massive open-source ecosystem with tons of libraries. Genuinely excellent for real-time, interactive applications where users expect instant responses.

The Challenges: Without careful architecture, your codebase turns messy fast. Data partitioning gets complicated at scale. Configuration mistakes can lead to data loss, which nobody wants to explain to stakeholders.

What is MERN Stack Development?

MERN keeps the same backend but switches to React for the frontend:
MongoDB: Still your flexible NoSQL database handling data storage.

Express.js: Still your reliable framework building web apps and RESTful APIs.

React: Facebook created this component-based library for interfaces. You build reusable components that snap together. Need updates? Change one component instead of rewriting everything.

Node.js: Same server-side JavaScript runtime as MEAN, handling all backend operations.

MEAN Stack vs MERN Stack: Core Differences

The choice between MEAN and MERN can be much more straightforward since they both utilize MongoDB, Express.js, and Node.js. However, there is one question where the answers will determine which way to go: Angular or React.

That's how MEAN and MERN frameworks are different:

Front-End Framework: Angular vs React
Angular (MEAN) is an entire MVC framework. All you need is included, no need to search for additional libraries.
React (MERN) is a simple UI framework which can create complex applications by itself but requires some help in other areas, such as Redux and React-router.
MEAN should be your choice if you value stability and consistency. Otherwise, MERN may become an advantage.
Learning Curve and Development Speed
Angular requires more effort – TypeScript, decorators, dependency injection. Experienced teams have no trouble with it, but new developers or time pressure will cause some delays.
React is much easier to learn. The community is large, documentation is plentiful, and most developers can become productive very quickly.
In case you're working under time pressure or don't have a highly skilled team, go for MERN. If the project is long and complicated and your team has lots of experience, MEAN will be a better choice.
Restful API Development
To be honest, there isn't much difference here. Both stacks use Express.js on the backend side, so developing APIs using either stack will feel virtually the same. Routing, middleware, request handling – nothing to choose here.
Don't let this factor affect your decision.
Community Support
Angular is developed by Google – long-term support, regular updates, enterprise-friendly stack. Not likely to disappear anytime soon.
React has a larger overall community and an enormous ecosystem of libraries and reusable components. Hiring React developers is also easier than Angular at the moment.
MEAN is more stable. MERN is more versatile.

Which Stack Should You Choose?

Choose MEAN when your team knows TypeScript, you're building enterprise-grade software, and structure matters more than speed.
Choose MERN when you need fast iteration, a flexible UI, and your team prefers JavaScript over TypeScript.
Both are battle-tested. The right choice is the one that fits your team's strengths — not whatever's trending right now.

So Which One Should You Actually Pick?

Want flexibility and simplicity? MERN's probably calling your name. Need a comprehensive framework with structure and guidance? MEAN with Angular might fit better.

Both stacks build modern, high-performance web applications just fine. The real trick is matching your choice to actual project requirements—not what sounds trendy right now.

Think about your team's existing skills. Consider your timeline. Be realistic about complexity. Got Angular experts on staff? Teaching them React wastes time. Same applies in reverse.
Still feeling stuck about which stack fits your specific situation? Sometimes talking through options with experienced full-stack developers saves months of frustration. Innostax works with both MERN and MEAN regularly and can help you figure out what actually makes sense for your needs.

About Innostax

Innostax provides businesses with outsourced resources for their software development through our services or through our staff augmentation program. We primarily serve Startup, Scaleup, and Digital Agencies; all of which require contracted development experts when they require assistance to augment their Development Team or with a custom solution to build their product and as a result do not want to incur the cost and time to set up and manage an internal Dev Team.

Want to see how we deliver scalable, cost-effective Python development without the overhead of an in-house team? We've broken down the full approach—talent sourcing, project onboarding, tech stack decisions, and business outcomes—in detail on the Innostax blog.

Read the full guide: MERN vs MEAN: Choosing the Right Stack

Web Workers Vs. Service Workers in JavaScript

Sahil Khurana — Tue, 16 Jun 2026 10:55:42 +0000

Experiencing an event like this is something we've all encountered. You click on something after a short wait for your web application to load, and immediately the entire page becomes unresponsive before you can even see what happened; you may want to throw your chair through your monitor at this point; your only option is to refresh (collapse) and hope it will work next time. Many times, this problem has been caused by JavaScript; it’s not that JavaScript is a “bad” programming language; it’s just that it performs too much work using a single thread; once that single thread gets overloaded, your user interface won’t perform as intended.

The primary purpose of Web Workers and Service Workers are to provide practical solutions to the problems with web applications; although those are both great-sounding names, they’re, in actuality, two entirely different mechanisms designed to alleviate the issues experienced when using traditional web applications.

Key Takeaways

By using Web Workers and Service Workers in your web applications, you can lower the main UI processing load and run tasks on separate threads; thus increasing the speed of your web application by offloading to other threads to reduce the time an operation requires.
Heavy calculations can be run on the server using web workers and can be done independently of the UI, while at the same time allowing for service workers, which gives users an experience of being able to access a web application without an internet connection, leading to a better experience for the user.
Through web workers and service workers being implemented in your web application, users will see improved performance with faster load times and seamless operation even with slow internet connectivity.

However, what occurs when your UI freezes due to a JavaScript issue? In summary, your JavaScript runs in a thread, which means that there is only one thread for all tasks. And since each task is running on the same thread as all others, once something computationally extensive is executed, everything else subsequently has to wait until that task completes before the rest can move on.

Simply making JavaScript run faster will not resolve this problem; rather, you need to provide an alternate source from which JavaScript can access resources so that it does not have to complete all computing operations in parallel on one thread
For this purpose, web workers allow you to create a secondary thread for performing the more complicated work and thus keep your main thread free to operate in real-time; however, service workers do not perform any computation and instead act as intermediaries between your application and any network resource determining whether to issue requests out to the internet or to return the cached result from previous requests.

These two types of workers each serve a purpose outside of the other; therefore, let’s examine each of them separately and in greater depth.

What are Web Workers?

Think of it like this: your JavaScript app is like a restaurant that has one person cooking. This person has to do everything. They take orders they prepare the food, and cook it. They serve it. When the restaurant gets really busy, everything slows down.

If you hire another person to help with the cooking, that is of like what a Web Worker does. This new person helps with the work in the kitchen so the other person can keep serving the customers without any problems.

When we talk about code, a Web Worker is like a person who works on a task. You give them something to do, and they do it on their own. When they are done, they send you the answer. Your main Web Workers app never even knows that the Web Worker was busy doing something.

How Web Workers Work:

Creating a Worker: You just create a Worker object and point it at your worker script file. One line and you're off.

Communication: Workers and the main thread can't share variables directly - instead they pass messages back and forth using postMessage() and onmessage. It's a bit like sending notes through a door.

Limitations: Here's the catch - Web Workers have zero access to the DOM. They can't read or update anything on the page. Their entire job is computation, and that's it.

// main.js
const worker = new Worker('worker.js');
worker.postMessage('Hello, worker!');
worker.onmessage = function(event) {
  console.log('Received from worker:', event.data);
};

// worker.js
onmessage = function(event) {
  console.log('Received from main thread:', event.data);
  postMessage('Hello, main thread!');
};

What are Service Workers?

Service Workers do something completely different. Instead of helping with processing, they intercept network requests. Every single time your app tries to fetch something from the internet, a Service Worker can step in and say - "I've got this. No need to hit the server."

That's how apps load in under a second even on a slow connection. That's how some web apps work when you're completely offline. The Service Worker cached the right resources ahead of time, and it's serving them locally.

How Service Workers Work:

Installation: This occurs when the Service Worker is first created and implemented into the browser environment.
Activation: Once the Service Worker has been created, it will be activated after the Install event is fired off.
Fetch Event: Each time an application requests any web page, it fires off a Fetch event, which allows you to determine how you will serve that request from either your cache or the network, depending on whether you cached the page previously.
Lifetime: The lifetime of your Service Worker will not end when you close the browser window. The Service Worker will remain in the background waiting for the next time you use the application to intercept requests.

Why Use Web Workers?

If any part of your app does something computationally expensive — think image processing, parsing a huge JSON file, running a real-time algorithm — you should seriously consider moving that work to a Web Worker.

// service-worker.js
self.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open('v1').then(function(cache) {
      return cache.addAll([
        '/',
        '/styles.css',
        '/script.js'
      ]);
    })
  );
});

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

Advantages of Web Workers

When your application is dealing with a long-running computational process such as manipulating an image, parsing a large JSON file, or running a real-time algorithm, consider the idea of processing this work inside a Web Worker:

Boost Performance: The main thread is not busy with expensive operations any longer. While your application is still usable, the heavy lifting takes place in the backend.
Keep Your Users Interacting: Users don't need to care about the computationally intensive operation and can continue scrolling, clicking, etc.. Normally.
Keep Your Users Interacting: Users don't need to care about the computationally intensive operation and can continue scrolling, clicking, etc.. Normally.
Run in Parallel: You can have as many web workers as you need running on the same instance, doing various kinds of tasks. In fact, this is the closest JavaScript gets to true multithreading.

Why Use Service Workers?

If you want your app to feel fast - not just be fast, but actually feel fast - Service Workers are how you get there.

Offline Capability: Your app doesn't die when the internet drops. It serves cached content and keeps working, which is huge for users on spotty connections.
Improve Performance: Pulling from cache is nearly instant. No DNS lookup, no server round-trip, no waiting. Users notice the difference immediately.
Background Sync: If a user submits a form while offline, a Service Worker can hold onto that data and sync it the moment connectivity comes back. No lost work, no frustrating error messages.

How to Implement Web Workers and Service Workers?

Implementing Web Workers

It’s simpler than most people expect. Create a separate JS file for your worker logic, then initialize it from your main script:

Creating a Worker:

const worker = new Worker('worker.js');

Communication:

worker.postMessage('Message to worker');
worker.onmessage = function(event) {
  console.log('Message from worker:', event.data);
};

Implementing Service Workers

One important habit before you register: always check if the browser actually supports Service Workers first. It saves a lot of headaches.

Registering a Service Worker:

if ('serviceWorker' in navigator) { 
navigator.serviceWorker.register('/service-worker.js') 
.then(function(registration) { 
console.log('Service Worker registered with scope:', registration.scope); }); 
}

Handling Events:

// service-worker.js
self.addEventListener('install', function(event) {
  // Perform installation steps
});

self.addEventListener('fetch', function(event) {
  // Handle fetch events
});

Conclusion

As soon as you’ve learned about Web Workers and Service Workers and what they actually do, you won’t be able to look at them any other way. One worker, Web Worker, allows you to run your web-app from within something like a browser, with no chance of freezing your app when there is a lot of activity happening in there. The other (Service Worker) allows your users to receive fast and dependable service, no matter what type of connection they are on.

Both have their own respective problems to solve, but when you put the two together, they solve a lot of issues that might be causing your users to experience poor service. The setup is very easy to do with only event listeners to register, some minor setup scripts, and you’ll have a much more robust experience for your end users.

About Innostax

Innostax is a custom software development and IT staff augmentation company. We deliver outsourced Python development services, build custom software solutions, and provide managed engineering teams for startups, scale-ups, and digital agencies — typically when businesses need skilled Python expertise on demand, without the time and cost of building and maintaining an in-house development team.

Want to see how we deliver scalable, cost-effective Python development without the overhead of an in-house team? We’ve broken down the full approach — talent sourcing, project onboarding, tech stack decisions, and business outcomes — in detail on the Innostax blog.

Read the full guide: Web Workers Vs. Service Workers in JavaScript

SQLAlchemy Essentials: A Beginner’s Roadmap

Sahil Khurana — Mon, 15 Jun 2026 07:27:53 +0000

Key Takeaways

SQLAlchemy is both an ORM and a SQL toolkit — pick one, use both, whatever works for your situation.
Learn Engine, Session, and Declarative Base first. Seriously, before you write anything.
Runs on PostgreSQL, MySQL, SQLite, Oracle — you can swap databases without torching the whole codebase.

Introduction

Month two or three into a backend project is when it usually happens. Not a crash, not a catastrophic failure — just this slow creep of annoyance. The raw SQL strings you threw in early on? They start multiplying. You rename one column and suddenly something is broken in three places you forgot even existed. You spend twenty minutes ctrl+F-ing through files trying to find where you wrote that query six weeks ago.

It's not a crisis. It's just painful in a boring, grinding kind of way.

That's usually when people go looking for something better and end up at SQLAlchemy. It's been around since 2006. In Python terms that's ancient history — and yet it's still the default choice for serious backend work. Not because it's easy, it's not, but because it never forces your hand. You want ORM abstractions? Fine. You want to drop down and write actual SQL because the ORM is acting strange? Also fine, you can do that in the same codebase, same connection, no hacks needed. That kind of flexibility is rarer than it sounds.

Here's what you actually need to get started.

What Even Is SQLAlchemy?

Honestly, it's two tools that ship as one.

The first is the SQL Expression Language — SQL, but expressed as Python. You get precise query control without ever touching raw string concatenation. The second is the ORM, which sits on top and removes the database from your mental model almost entirely. Classes become tables. Objects become rows. You think in Python, SQLAlchemy handles the translation.

Most people start with the ORM, fall back to the Expression Language when things get weird, and bounce between both depending on what a given query needs. Some teams skip the ORM altogether and live in the Expression Language. Totally valid either way, nobody's going to argue with you.

Why Bother With It at All?

For a script or a tiny side project — genuinely, don't bother. Plain sqlite3 is sitting right there in the standard library and it'll do the job without any setup.

But once you've got real scale, real team size, a schema that keeps shifting — the "SQL strings everywhere" approach starts falling apart. Fast. That's where SQLAlchemy starts paying rent.

What You Get	Why It Matters
ORM and raw SQL	You're not locked into either. Use what the situation calls for.
Cross-database support	PostgreSQL, MySQL, SQLite, Oracle — change the connection string, not the whole app.
Models as Python classes	Schema lives in code. Any teammate can read it without knowing the database.
Full query visibility	Log every query. No hidden performance problems sneaking through.
18 years of community	Whatever weird thing you run into, someone already has. Check the forums.

Installation

pip install sqlalchemy

Plus a driver for your database:

pip install psycopg2      # PostgreSQL
pip install pymysql       # MySQL

SQLite ships with Python so nothing extra needed there.

Four Things to Understand Before You Write a Single Line

Most SQLAlchemy confusion is from jumping into code examples cold, without any mental picture of the parts involved. Read this first and a lot of the friction disappears.

Engine — Your actual database connection. Manages the connection pool, sits under everything, you set it up once and mostly forget it's there. Nothing else functions without it.

Session — Where you do your work. Queries, inserts, updates — all go through a session. Key thing: changes are held in memory until you call commit(). Nothing hits the database for real until that point. This is intentional. Means you can back out of a half-finished operation if something breaks mid-way.

Declarative Base — A base class. Your model classes inherit from it. It's what lets SQLAlchemy know these Python classes are supposed to map to database tables. You make it once, inherit from it everywhere.

Model — A class that represents a table. One class, one table. One instance of that class, one row. That's the whole idea.

Building Something Step by Step

Step 1 — Connect to a Database

from sqlalchemy import create_engine

engine = create_engine('sqlite:///example.db')

Production would look more like postgresql://user:pass@localhost/mydb — same pattern. SQLite is just the easiest starting point locally since there's nothing to install or configure.

Step 2 — Define a Model

from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy import Column, Integer, String

Base = declarative_base()

class User(Base):
    __tablename__ = 'users'

    id   = Column(Integer, primary_key=True)
    name = Column(String)
    age  = Column(Integer)

__tablename__ is what the table gets called in the actual database. The attributes are columns. Read it a couple times and the pattern sticks pretty naturally.

Step 3 — Create the Tables

Base.metadata.create_all(engine)

Looks at everything hanging off Base, runs the CREATE TABLE statements for you. No hand-writing DDL.

Step 4 — Insert, Query, Update

from sqlalchemy.orm import sessionmaker

Session = sessionmaker(bind=engine)
session = Session()

# Add a record
new_user = User(name="John Doe", age=30)
session.add(new_user)
session.commit()

# Fetch records
users = session.query(User).all()
for user in users:
    print(user.name, user.age)

# Update something
user = session.query(User).filter_by(name="John Doe").first()
user.age = 31
session.commit()

Change something, commit. That's the loop. Forget the commit and the change silently disappears — you'll do this at least once and spend a baffled ten minutes before figuring out why. It happens to everyone, don't stress it.

Step 5 — Relationships

Here's where it gets genuinely useful. Define a relationship once and stop writing joins every time you need linked data:

from sqlalchemy import ForeignKey
from sqlalchemy.orm import relationship

class Post(Base):
    __tablename__ = 'posts'

    id      = Column(Integer, primary_key=True)
    title   = Column(String)
    content = Column(String)
    user_id = Column(Integer, ForeignKey('users.id'))

    user = relationship("User", back_populates="posts")

User.posts = relationship("Post", order_by=Post.id, back_populates="user")

Now user.posts gives you the list. post.user gives you the author. The join happens behind the scenes. You just access properties like it's a regular Python object, because it is.

SQLAlchemy vs the Other Options

Django ORM vs SQLAlchemy is a question that comes up constantly. Here's a straight answer:

	SQLAlchemy	Django ORM	Peewee
Flexibility	High — ORM and raw SQL	Moderate, ORM-first design	Moderate
Learning Curve	Steep up front	Gentler	Easy
Query Control	Full	Limited	Limited
Best Fit	Standalone backends, complex apps	Django projects	Scripts, small projects

If you're in a Django project, just use Django ORM — no argument there, it integrates perfectly and fighting it makes no sense. Peewee is a solid pick for smaller stuff, fast to get going. But outside Django, or whenever query complexity is a real concern, SQLAlchemy is the one that ages well. It's the tool you won't find yourself trying to route around two years in.

Where to Go From Here

The complexity reputation SQLAlchemy has is real but exaggerated. Most projects use a narrow slice of it — models, sessions, queries, relationships. That slice is well-built and once it clicks, it stays clicked.

Start with the ORM. Get something working. When the ORM starts making a particular query harder than it should be — and that will happen eventually — reach for the Expression Language and write the SQL directly. That's the actual workflow, not a theoretical fallback. Experienced people do exactly this, switching between layers depending on what the problem needs.

Runs on a local SQLite file on your machine. Runs on a Postgres cluster with serious traffic. The mental model you build in the first week transfers cleanly years later. That doesn't happen by accident, and it's one of the main reasons the library has lasted this long.

At Innostax, we work through this kind of thing regularly — picking the right database layer, structuring backends that stay maintainable, building data models that hold up under pressure. If you're working through the same questions for your own project, reach out at innostax.com/contact.

Originally published on the Innostax Engineering Blog.

Is Outsourcing ASP.NET the Smarter Route for Your Next Web Project?

Sahil Khurana — Fri, 12 Jun 2026 09:36:21 +0000

Key Takeaways

Performance That Holds Under Pressure — ASP.NET Core doesn't start struggling when traffic spikes. That's the point of it.
Security Baked In, Not Bolted On — The defaults cover authentication, authorization, data protection. You're not starting from zero.
Tooling That's Already Figured Out — Visual Studio, a mature ecosystem, years of community problem-solving. The sharp edges are mostly gone.
Outsourcing Buys Expertise, Not Just Headcount — The real value is a team that's already made the mistakes your project hasn't made yet.
Runs Anywhere — Linux, any cloud, no infrastructure lock-in. That flexibility compounds over time.
Modern Web Features Without the Setup Tax — SignalR, WebSockets, clean routing. Already there.
Works for New Builds and Legacy Fixes Alike — That combination is rarer than the framework marketing makes it seem.

Nobody's Asking the Right Question

Here's what usually happens.

A company needs to build something serious on ASP.NET — or modernize something that's been slowly falling apart for years. Someone raises the outsourcing question. And immediately, the conversation turns into a debate about rates, time zones, and that one bad experience from 2019 that somebody in the room won't let go of.

The meeting ends. Either nothing gets decided, or something gets decided for the wrong reasons.

Meanwhile, the question that actually determines whether outsourcing makes sense — does your current team, with the time and capacity they actually have, have the depth to pull this off well — goes completely unasked.

I've watched this happen a lot. It's almost always the wrong conversation happening instead of the right one.

ASP.NET Core: What It Actually Does Well

I'm not going to run through a feature list. You can find those anywhere.

What's worth saying is that ASP.NET Core is a framework that was built for the uncomfortable end of the requirements spectrum. High traffic. Real security obligations. Applications that need to be running in three years, not rebuilt. The modular architecture means you're not carrying dead weight. The open-source model with Microsoft backing means it's not going anywhere. The performance under load is the reason it keeps showing up in enterprise infrastructure that can't afford to be slow.

The security piece deserves more credit than it usually gets. Authentication, authorization, data protection — these aren't add-ons. They're defaults. For anything operating under compliance requirements, that's not a nice-to-have. It's the difference between a framework that handles those requirements and one that leaves them as an exercise for the developer.

The toolchain is mature in a way that genuinely saves time. Not "mature" as a euphemism for old. Mature as in: most of the problems you'll hit have already been hit, solved, documented, and turned into Stack Overflow answers.

What You're Actually Getting When You Outsource This

Let me be blunt about something.

"Outsourcing" as a word carries a lot of baggage that doesn't apply here. The value isn't cheaper labor. Anyone still selling outsourcing purely on rate arbitrage is selling the wrong thing.

The actual value is this: ASP.NET Core expertise at an enterprise level takes years to develop. Not months. Years of working through real production failures, catching security misconfigurations before they become incidents, understanding which performance patterns hold up at scale and which ones only look good in development. When you bring in a team that already has that, you're not buying their hours. You're buying the years of context behind them.

That context shows up in ways that are hard to put in a proposal but very easy to feel mid-project. Decisions that get made right the first time. Patterns that don't need to be refactored six weeks later. A codebase that doesn't require emergency cleanup before it can go live.

Speed compounds differently with experienced teams. They're not learning the framework while trying to ship. They've already hit the walls your project is going to hit. That's not a small thing — it's often the difference between a deadline that holds and one that doesn't.

Scaling without the hiring circus. Building an internal team for a project-specific need means recruiting, onboarding, and eventually having an uncomfortable conversation about what those people do when the project wraps. Outsourcing skips all of that. The team scales with the work, not the other way around.

An outside view that your internal team structurally cannot have. This one sounds soft but it isn't. Teams that have been working on the same problems in the same codebase for a long time develop patterns — good ones and bad ones — and stop being able to see either clearly. External teams bring different defaults, different instincts, exposure to a wider range of failure modes. That perspective is genuinely useful and genuinely unavailable from inside the building.

When This Framework Is Actually the Right Call

Not every project needs ASP.NET Core. Worth saying that plainly.

If the application needs to handle real traffic from day one, carry meaningful security requirements, and not require a rethink of its architecture in eighteen months — this is probably the right framework. It was built for exactly that combination.

If you're dealing with a legacy .NET system that's become a liability — technical debt that's starting to affect delivery speed, or an architecture that doesn't match how the business works anymore — ASP.NET Core gives you a migration path that doesn't require burning the whole thing down. That matters when there's years of business logic embedded in a stack you can't simply walk away from.

If someone in the room is pushing for Django, Laravel, or Rails instead — those frameworks are fine for the right project. Smaller scope, lower traffic expectations, less demanding security requirements. When those conditions apply, they're legitimate choices. When they don't, ASP.NET Core is usually the more defensible decision and easier to justify twelve months later.

The wrong reason to land on ASP.NET Core: familiarity. "We used it last time" isn't a technical argument. It's a comfort argument. Sometimes they overlap. Often they don't.

So Is Outsourcing the Smarter Route?

For some projects, yes. Clearly.

Specifically: when the project needs the framework, the timeline doesn't allow for internal team ramp-up, and the cost of getting it wrong is higher than the cost of bringing in people who've already gotten it right.

In that situation, outsourcing isn't a compromise. It's the faster, lower-risk path. The partner you bring in starts contributing on day one instead of week six. The decisions they make are informed by experience your team hasn't had yet. The codebase they build doesn't immediately create new problems for whoever maintains it.

The organizations that use ASP.NET Core well — whether they build that capability internally over time or bring it in for specific projects — consistently ship better outcomes than the ones discovering the framework's edges mid-delivery.

The question was never "is outsourcing smart in general." That's not a useful question. The useful question is whether it's the right call for this project, with this team, at this moment. Get that answer right and everything downstream gets easier.

At Innostax, we build with both — the choice comes from what the project actually needs, not what we happen to prefer. If you're trying to figure out whether outsourcing your ASP.NET development makes sense for what you're building, innostax.com/contact is the right place to start.

Originally published on the Innostax Engineering Blog.

AngularJS: Why Businesses and Developers Still Rely on It

Sahil Khurana — Fri, 12 Jun 2026 06:05:41 +0000

A lot of developers I've spoken to treat AngularJS like a legacy decision. Something you maintain, not something you start with. But then you look at the actual list of products built on it — Gmail, PayPal, Upwork, YouTube — and that assumption starts to crack.

AngularJS launched in 2010. Google built it. Over a million websites run on it. That's not a framework on life support. That's one that earned its place by solving real problems in ways people kept coming back to.

So what does it actually do well? And why do teams still pick it when starting something new?

What Do People Actually Build With AngularJS?

The range is wider than most people expect.

Single Page Applications

Gmail. Trello. A single page application rewrites itself dynamically as you interact — no full page reloads, no waiting. The experience feels faster because the browser isn't doing full page requests on every click.

Enterprise Web Applications

Internal tools at scale. Data management, HR systems, supply chain visibility. Several Google and Microsoft products that companies rely on daily were built using AngularJS. Not a framework you'd pick if it couldn't handle complexity.

Dynamic Websites

Upwork and Forbes both run on it. A dynamic website isn't just displaying fixed content — it's pulling and updating data based on who you are, what you're doing, when you're doing it.

Dynamic Web Applications

PayPal. That one tends to surprise people. A dynamic web app responds to your actions in the browser without reloading the full page. The fact that PayPal handles transactions this way tells you something about how the framework performs under pressure.

E-commerce Platforms

Shift4Shop and AngularSpree are both built on it. AngularJS handles product browsing, cart updates, and checkout flows without breaking a sweat.

Content Management Systems

Taiga and Angular CMS. A CMS is multiple people touching the same content at the same time without stepping on each other. AngularJS handles that kind of concurrent state management well.

Dashboards

ArchitectUI, SB Admin Angular, Monarch. A good dashboard makes a lot of information readable at once, and it updates as the data changes without manual pushing. The framework's data binding is well-suited to this.

Social Media and Chat Applications

YouTube is the headline. Sport-Hub and VibeVortex too. Real-time feeds, comment threads, live interactions — exactly the kind of work AngularJS was built for.

Progressive Web Applications

Starbucks and Twitter went this route. A PWA can be installed on a device or run in a browser. AngularJS handles this without needing a completely separate mobile build.

Real-time Applications

Weather.com. Data that updates constantly, served to millions of users. AngularJS handles the update cycle without extra plumbing required.

10 Reasons Developers Choose AngularJS for Web Development

1. MVC Architecture: Structure Before You Need It

Anyone who's worked on a frontend codebase that grew without structure knows what happens. Logic scattered everywhere. No clear ownership. Bugs that are nearly impossible to trace.

MVC fixes that before it starts.

Model handles the data — fetches it, organizes it, holds it.
View shows the data. That's it.
Controller sits between them — processes user input, talks to the Model, delivers output through the View.

Three responsibilities. Three places to look when something breaks. For anything you plan to maintain for more than six months, this matters.

2. Two-Way Data Binding: You Feel It Immediately

You type in a field — the model updates. The model updates — the UI reflects it. No wiring required. No manual sync.

(Once you've built with two-way binding, going back to managing DOM updates manually is genuinely unpleasant in a way nobody prepares you for.)

3. Dependency Injection: Your Tests Will Thank You

Instead of hardcoding dependencies inside your components, you declare what each piece needs and AngularJS provides it. The practical payoff is in testing — you can swap a real service for a mock one without rewriting anything. Tests stay fast and isolated. For teams that actually run test suites regularly, this matters more than almost anything else on this list.

4. Reusable Components and Directives

Write it once, use it wherever you need it.

Same dropdown logic in three places? Same date-picker behavior across multiple forms? Build it once as a custom directive or component, reference it everywhere. Less duplication, fewer places for bugs to hide, and when requirements change, you update one thing — not six.

5. Single Page App Support That Holds Up

AngularJS for single page app development gives you fast load times and navigation that feels immediate. The application only re-renders what changed — not the whole page.

For products where speed affects whether users stick around, this is worth caring about.

6. Karma and Jasmine Come With It

AngularJS ships with testing tools built in — Karma to run them, Jasmine to write them. Unit tests and end-to-end tests. No separate configuration project just to get your test suite off the ground.

The error messages point somewhere useful too. That might sound like a low bar, but spend a few hours chasing an unhelpful stack trace somewhere else and you'll appreciate it.

7. HTML Templates That Stay Readable

Dynamic directives let you put loops, conditions, and event bindings directly in the template. Not scattered across a collection of JavaScript files someone has to mentally map back to what's on screen.

New people on the team can look at a template and understand what it does. That's worth more than it sounds.

8. Form Validation Is Already There

Required fields, format rules, custom validators — AngularJS has this built in. You're configuring it, not building it. On anything with heavy form work — registration, checkout, multi-step flows — this saves actual time.

9. Same Codebase for Mobile and Desktop

Cross-platform development means one codebase, not two parallel ones. Same logic, same components, consistent behavior across devices. Less to maintain when requirements shift.

10. The Community Hasn't Gone Anywhere

Open-source, Google-maintained, running on over a million sites. The Stack Overflow threads, GitHub repos, libraries, and tutorials are all still there. When you hit something unusual, the odds are good someone already solved it and wrote it up.

Should You Still Use AngularJS in 2026?

If you're on an existing AngularJS codebase — there's rarely a good reason to rip it out. It's stable, well-documented, Google-backed, and still running in production at massive scale.

If you're starting something fresh — give it a real evaluation. Not the dismissive "isn't that old?" kind. An actual one. For teams that want structure from day one, testable code without a long setup process, and a framework that's been proven at scale, AngularJS still competes.

The case for it isn't nostalgia. A framework powering Gmail, PayPal, YouTube, and Upwork earned its spot on that list.

Using AngularJS in production right now? Curious what the use case is — drop it in the comments. And if you've migrated away, what pushed you to do it? 👇

#javascript #webdev #frontend #angular

Sahil Khurana
Chief Technology Officer at Innostax

About Innostax

Innostax is a global software consulting and custom software development company helping growth-stage startups, scaleups, and enterprises build reliable, scalable digital products. Founded in 2014 and headquartered in Framingham, Massachusetts, Innostax specializes in custom software development, web and mobile app development, IT staff augmentation, offshore software development, and digital transformation services — across industries including healthcare, retail, education, travel, and fintech. With a dedicated development team model, a 2-week risk-free trial, and deep expertise in technologies like React.js, Node.js, Python, .NET, and React Native, Innostax co-creates breakthrough solutions that help founders, CTOs, and product leaders ship better software, faster. Learn more at innostax.com.

Django vs. Flask: Choosing the Right Python Framework for Your Business

Sahil Khurana — Wed, 10 Jun 2026 09:17:38 +0000

The real question isn't which framework is better. It's which one you can stop thinking about six months into the project.

Key Takeaways

Project Suitability — Django is built for weight. Flask is built for speed. Know which one your project actually needs before you commit.
Development Flexibility — Django makes decisions so your team doesn't have to. Flask hands those decisions back. Both are features, depending on who's writing the code.
Scalability & Performance — Scaling is an architecture problem first, a framework problem second. Pick the one that matches the system you're building — not the one you hope to build.
Security Features — Django's protections are on by default. Flask's require you to turn them on. In a fast-moving team, that difference is more significant than it sounds.
Ecosystem & Community — Both communities are active and well-documented. You won't be stuck either way.

The Decision Nobody Takes Seriously Enough

I've watched this play out more times than I'd like to count.

A team kicks off a Python project, someone picks a framework — usually the one the most senior person knows best — and everyone moves on. Fast forward six months and the codebase is exhausting to work in. Either they're dragging a full framework through a service that should've been twenty lines of Flask, or they're rebuilding authentication from scratch on something that outgrew its lightweight origins two sprints in.

The framework choice isn't irreversible. But undoing it mid-project is expensive in a way that doesn't show up in any estimate.

Django and Flask are both genuinely good. What they're good for is different. That's the part worth slowing down on.

What You're Actually Getting With Each One

Django arrives with almost everything a web application needs already assembled — an ORM, an admin panel, authentication, form handling, CSRF protection, and more. The design assumption is that most web applications need most of these things, so it makes more sense to ship them integrated than to have every team assemble them independently. For the right project, that assumption holds up.

Flask gives you a core and a blank canvas. Routing, request handling, templates — that's your starting point. Database access, authentication, validation, all of it comes from libraries you select and wire together yourself. That's not a weakness. It's the point. Flask is designed for teams that know exactly what they want and don't want a framework guessing on their behalf.

The honest framing: Django makes the common path fast. Flask makes the custom path clean. Neither is universally better. They're different bets.

Project Size and Complexity

Django is where it makes sense when the application is genuinely large — e-commerce platforms, internal enterprise tools, anything carrying a complex data model and real user management requirements. The built-in admin panel alone has saved weeks of development time on projects that needed internal dashboards but didn't want to build one. Instagram runs on Django. Pinterest too. That's not a marketing point, it's a load reference.

Flask is the right call when the scope stays narrow. A microservice that does one thing well. A REST API where you want full control over what's happening. An MVP that needs to exist in two weeks without inheriting a framework's worth of structure it doesn't need yet.

The failure mode I've seen most: picking Flask because it feels lighter, then six months later manually rebuilding the scaffolding Django would have provided on day one. If the roadmap points toward complexity, start with the framework that handles it.

Development Speed and Flexibility

Django's conventions are the speed. When your project matches what Django expects — which is most standard web applications — the framework carries a lot of the load. You configure rather than construct. The patterns for authentication, the ORM, the admin, the request lifecycle — they're settled. Your team ships features instead of infrastructure.

Flask's freedom is the speed, but only for the right team. Developers who have a clear architectural vision and the experience to execute it move faster when nothing is in the way. The risk is that Flask's openness creates decisions, and decisions create divergence, and divergence in a codebase creates the kind of technical debt that's slow to pay back. Junior teams and Flask is a combination that requires strong leadership to go well.

Scalability and Performance

Both frameworks scale. The more useful question is how the scaling actually works.

Django is well-suited to monolithic architectures under significant traffic. One application, many features, high load. It's been stress-tested in exactly those environments and holds up.
Flask is well-suited to distributed systems where each service is small and independently deployable. In a microservices architecture, Flask's footprint is an advantage — you're not carrying Django's full weight in a service that handles one API endpoint.

One thing worth being direct about: Flask doesn't inherently perform better than Django. Raw performance is an infrastructure and query question far more than a framework question. Pick the architecture that fits your system, then pick the framework that fits the architecture.

Security

This one matters more in practice than most framework comparisons acknowledge.

Django ships with protection against XSS, CSRF, and SQL injection turned on by default. You don't opt into them — you'd have to opt out. For any application handling sensitive user data, that's meaningful. The framework enforces best practices whether or not your team is thinking about them on a given sprint.

Flask can match Django's security posture. But it requires deliberate configuration of each protection, and it requires someone on the team to know what needs configuring. In a well-resourced team with security-aware developers, that's manageable. In a startup moving fast with shifting priorities, it's the kind of thing that slips until it matters. Django removes that risk by design.

Ecosystem and Community

Both frameworks have large, active communities and extensive documentation. Neither is going to leave your team stuck without library support or community knowledge.

Django's ecosystem is broader and more integrated — third-party packages are generally designed to plug into Django's architecture specifically, which means less wiring. Flask's extension ecosystem is healthy and growing, with the practical advantage that you install exactly what the project needs and nothing more.

For most teams, ecosystem isn't the deciding factor here. Both have what you need.

How to Actually Decide

Django is probably the right call when:

The application has real complexity — multiple entities, user management, evolving business logic
The team isn't made up of senior engineers who thrive on architectural freedom
Requirements will keep changing and the schema will keep evolving
You need an internal admin and you don't want to build one
Security coverage from the framework is worth more than configuration control

Flask is probably the right call when:

You're building a microservice, a lightweight API, or a narrowly scoped MVP
The team is experienced and has a clear picture of what the architecture should look like
The system is distributed and each service has one job
You want full control over every library and pattern in the stack

One note: these aren't interchangeable within the same project the way some tooling decisions are. Pick based on the architecture you're committing to — not the one that feels more familiar.

The Bottom Line

Django and Flask have each been solving real problems in production for years. The ecosystems are mature. The communities are active. Neither choice is a risk in isolation.

The risk is picking one without thinking clearly about the other. Django in a project that needed Flask's simplicity means overhead you'll feel every day. Flask in a project that needed Django's structure means scaffolding you'll rebuild piece by piece.

Answer the architecture question first. The framework choice follows from it — and when you get it right, you stop noticing the framework entirely.

At Innostax, we build with both — the choice comes from what the project actually needs, not what we happen to prefer. If you're figuring out the right stack for something you're building, innostax.com/contact is the right place to start that conversation.

Originally published on the Innostax Engineering Blog.

Entity Framework vs. Dapper: Choosing the Right ORM for .NET

Sahil Khurana — Tue, 09 Jun 2026 07:42:08 +0000

It's not about which ORM is better. It's about which one stops getting in your way six months into the project.

Key Takeaways

Tool Fit Over Familiarity — The wrong ORM for your project isn't a code problem. It's a decision problem that shows up in production.
EF for Complexity — Entity Framework earns its place when the data model is large, the schema keeps evolving, and developer speed matters more than raw query performance.
Dapper for Performance — Dapper is the right call when latency is a product constraint and your team is comfortable owning the SQL.
Abstractions Have a Cost — Every layer EF adds between your code and the database is useful — until it isn't. Know when that line gets crossed.
Using Both Is a Valid Answer — EF for complex business logic, Dapper for performance-critical reads. Not the cleanest architecture, but often the honest one.

The Decision Nobody Gets Right on the First Try

I'll be honest — this is a debate I've watched teams get wrong more often than I'd like to admit. Including teams I've been part of.

The conversation usually goes something like this: someone picks whichever ORM they're most comfortable with, ships the project, and six months later they're either wrestling with inexplicable query slowdowns or drowning in handwritten SQL that nobody wants to touch. The tool wasn't wrong. The fit was.

So let me skip the feature matrix and talk about what actually matters when you're making this call.

ORMs Exist Because SQL Gets Tedious. Fast.

If you've ever written the same CRUD logic fifteen times across fifteen different tables, you understand why ORMs exist. They sit between your application and your database and handle the repetitive parts — connections, mappings, relationships — so your team can focus on what the application actually does.

The catch is that every abstraction hides something. The question is whether what it hides is something you needed to see.

Entity Framework: When You Want the Database to Mostly Handle Itself

EF is Microsoft's answer to database management in .NET, and it's genuinely impressive in scope. You write C# and LINQ, it figures out the SQL. Schema changes? There's a migration system that tracks them as code and applies them consistently. Entity relationships, change tracking, support across database providers — it's all there.

I've seen EF shine on large enterprise codebases where the data model is genuinely complex — dozens of entities, evolving business requirements, teams rotating in and out. The ability to write database interactions in C# without thinking about SQL keeps the codebase approachable for developers who aren't SQL-first thinkers.

Where it trips people up: EF's generated queries aren't always efficient. When you're dealing with high data volumes or tight latency requirements, the abstraction starts costing you. And if you don't know enough SQL to recognize when EF is doing something suboptimal, you won't know there's a problem until users start noticing.

Dapper: When You Trust Your Developers More Than Your ORM

Dapper was built by the Stack Overflow team — which tells you everything about its priorities. Stack Overflow serves enormous query volumes. They needed something fast and something they could control completely. Dapper is what they built.

It's a micro-ORM in the most literal sense. You write SQL. It maps the results to .NET objects. That's most of the story.

What you get: Query execution that sits almost directly on top of ADO.NET with minimal overhead. Performance benchmarks consistently favor Dapper, especially at scale. You know exactly what query is hitting your database because you wrote it yourself.

What you give up: Everything EF handles automatically. Migrations, relationship management, change tracking — gone. You own all of that. If your team isn't comfortable writing and maintaining raw SQL, Dapper is going to create more problems than it solves.

Where the Real Differences Show Up

Speed is the obvious one. Dapper wins on raw query performance. For most internal business tools or CRUD-heavy applications, it won't matter enough to change your decision. For high-traffic APIs or anything processing serious data volumes in real time, it absolutely will.

Schema management is where EF has no competition. The migration system is one of the most useful things in the .NET ecosystem and it's often underrated. Dapper has nothing equivalent — you're either writing schema changes by hand or pulling in external tooling.

Query control is the flip side. EF's LINQ queries are readable and cover most cases, but they're not always what you'd write if you were writing SQL directly. Dapper gives you full control. Sometimes that's exactly what a complex or database-specific query needs.

Relationship handling is where Dapper starts to feel like work. EF navigates entity relationships through navigation properties — it's almost invisible. In Dapper, you write the joins yourself. In a simple schema, fine. In a complex one, that adds up quickly.

How to Actually Decide

Reach for EF when:

You're building something with a complex data model
Your team doesn't live in SQL all day
The schema is going to keep evolving
Developer speed matters more than database performance

Reach for Dapper when:

You're building something performance-sensitive
Your team is comfortable with SQL
The schema is relatively stable
Latency is something your users will actually feel

And don't rule out using both. I've worked on codebases where EF handled the complex business logic and Dapper handled the performance-critical read operations. It's not the cleanest answer architecturally, but it's often the honest one.

The Real Question Underneath All of This

It's not "which ORM is better." It's "what's the actual bottleneck in this project — developer time, query performance, SQL expertise, schema complexity?"

Answer that honestly and the tool choice mostly picks itself. The teams that struggle are the ones who skip that question and default to whatever they used last time.

Originally published on the Innostax Engineering Blog.

Google Authenticator integration with Spring Boot

Sahil Khurana — Mon, 08 Jun 2026 07:10:21 +0000

Google Authenticator Integration with Spring Boot

Passwords alone just don't cut it anymore. We've all seen the headlines — data breaches, credential stuffing, account takeovers. And yet, a shocking number of applications still rely on a single password as the only line of defense. If you're building something with Spring Boot and haven't wired up multi-factor authentication yet, this guide is for you.

We'll walk through integrating Google Authenticator into a Spring Boot project — step by step, with real code. By the end, your users will need both their password and a time-sensitive code from their phone to get in. That's a meaningful security upgrade.

What Exactly Is MFA — and Why Should You Care?

Multi-factor authentication (MFA) — sometimes called two-factor authentication or 2FA — is the practice of requiring more than one proof of identity before granting access. Instead of just "something you know" (your password), you add "something you have" (your phone) or "something you are" (a fingerprint).

It sounds simple, but the impact is significant. Even if an attacker manages to steal or guess a user's password, they still can't log in without that second factor. For industries where data sensitivity is high — think fintech, healthcare, legal — MFA isn't optional, it's expected.

How Does a TOTP-Based Factor Actually Work?

Google Authenticator generates what's called a Time-based One-Time Password (TOTP). Here's the basic idea:

When a user first enables 2FA, the server creates a shared secret key and hands it to the user (usually via a QR code). From that point on, both the server and the app on the user's phone use the same algorithm — combining that secret with the current timestamp — to independently calculate a 6-digit code. The codes are valid for only 30 seconds.

When the user logs in, they open Google Authenticator, read the current code, and type it in. The server runs the same calculation and checks if the numbers match. No network call required on the app's side, no SMS that could be intercepted. It's elegant and robust.

What Makes Google Authenticator a Good Choice?

There are several authenticator apps out there, but Google Authenticator remains a go-to for good reasons:

It works completely offline — no cell signal or Wi-Fi needed once set up
It's immune to SIM swap attacks, which plague SMS-based 2FA
Setup is as easy as scanning a QR code
It's free, widely trusted, and available on both iOS and Android

Integrating Google Authenticator into a Spring Boot Project

Let's get into the actual implementation. There are four steps: add the right dependencies, generate a secret key per user, produce a QR code for setup, and verify the TOTP code at login time.

Step 1 — Add the Required Dependencies

Open your pom.xml and add the following:

<dependency>
    <groupId>de.taimos</groupId>
    <artifactId>totp</artifactId>
    <version>1.0</version>
</dependency>

<dependency>
    <groupId>com.google.zxing</groupId>
    <artifactId>core</artifactId>
    <version>3.3.0</version>
    <scope>compile</scope>
</dependency>

<dependency>
    <groupId>com.google.zxing</groupId>
    <artifactId>javase</artifactId>
    <version>3.3.0</version>
    <scope>compile</scope>
</dependency>

The totp library handles the TOTP math. The two zxing libraries handle QR code generation — they're from Google and do a solid job.

Step 2 — Generate a Secret Key for Each User

Every user gets their own unique secret key. This is generated once during setup and stored (securely) in your database alongside their account.

public static String generateSecretKey() {
    SecureRandom random = new SecureRandom();
    byte[] bytes = new byte[20];
    random.nextBytes(bytes);
    Base32 base32 = new Base32();
    return base32.encodeToString(bytes);
}

SecureRandom ensures the key is cryptographically random. The result is a Base32-encoded string — that format is what TOTP libraries and authenticator apps expect.

Step 3 — Generate the QR Code for Setup

Once you have the secret key, you need to present it to the user in a way Google Authenticator can consume. That means building a specially formatted otpauth:// URI and then encoding it as a QR code image.

private static final String ENCODED_SPACE = "%20";
private static final String PLUS_SYMBOL = "+";

public static String generateAuthenticatorQR(String email, String secretKey, String accountName) {
    try {
        String barCodeUrl = getGoogleAuthenticatorBarCode(secretKey, email, accountName);
        return createQRCode(barCodeUrl);
    } catch (Exception e) {
        System.out.println("Error generating QR code: " + e.getMessage());
    }
    return null;
}

private static String getGoogleAuthenticatorBarCode(String secretKey, String account, String issuer) {
    try {
        String utf8 = "UTF-8";
        return "otpauth://totp/"
            + URLEncoder.encode(issuer + ":" + account, utf8).replace(PLUS_SYMBOL, ENCODED_SPACE)
            + "?secret=" + URLEncoder.encode(secretKey, utf8).replace(PLUS_SYMBOL, ENCODED_SPACE)
            + "&issuer=" + URLEncoder.encode(issuer, utf8).replace(PLUS_SYMBOL, ENCODED_SPACE);
    } catch (UnsupportedEncodingException e) {
        throw new IllegalStateException(e);
    }
}

public static String createQRCode(String barCodeData) {
    try {
        String filePath = "QRCode.png";
        int size = 400;
        BitMatrix matrix = new MultiFormatWriter().encode(barCodeData, BarcodeFormat.QR_CODE, size, size);
        FileOutputStream out = new FileOutputStream(filePath);
        MatrixToImageWriter.writeToStream(matrix, "png", out);
        File img = new File(filePath);
        byte[] imgBytes = FileUtils.readFileToByteArray(img);
        return "data:image/PNG;base64," + Base64.getEncoder().encodeToString(imgBytes);
    } catch (Exception e) {
        System.out.println("Error creating QR code: " + e.getMessage());
    }
    return "Failed to generate QR";
}

The method returns a Base64-encoded PNG image that you can drop directly into an <img> tag on your setup page. The user scans it with Google Authenticator, and they're enrolled.

Step 4 — Verify the TOTP at Login

When a user logs in and submits their 6-digit code, you need to verify it against the secret key stored for their account:

public static String getTOTPCode(String secretKey) {
    Base32 base32 = new Base32();
    byte[] bytes = base32.decode(secretKey);
    String hexKey = Hex.encodeHexString(bytes);
    return TOTP.getOTP(hexKey);
}

Call this method with the user's stored secret key, get the expected code back, and compare it to what they entered. If it matches — they're in. If not — reject the attempt.

A Few Things Worth Keeping in Mind

Before you ship this, a couple of practical notes:

Store secret keys securely. Treat them like passwords — encrypt them at rest. If an attacker gets your database and the keys are in plaintext, the 2FA protection is gone.

Handle clock drift. TOTP codes are time-based, so if a user's phone clock is significantly off, valid codes might get rejected. Most TOTP libraries have a tolerance window — usually ±1 interval — to accommodate minor drift. Make sure yours is configured reasonably.

Give users a recovery path. What happens if someone loses their phone? You'll want backup codes or an admin-assisted recovery flow before you mandate 2FA for all users.

Wrapping Up

Adding Google Authenticator to a Spring Boot app is genuinely not that complex — a couple of libraries, some key generation logic, a QR code at setup, and a verification check at login. The lift is small; the security payoff is real.

For any application handling sensitive user data, this kind of layered authentication is increasingly table stakes. Whether you're building for finance, healthcare, or just want to protect your users properly, getting MFA in place early saves a lot of headache down the road.

Have questions or running into something unexpected during setup? Drop a comment or reach out — happy to help troubleshoot.

Building secure authentication systems and need a team that understands backend security beyond just checking compliance boxes? At Innostax, we help companies implement MFA, strengthen authentication flows, and build secure Spring Boot applications that hold up in real-world production environments. Learn more at innostax.com or get in touch at innostax.com/contact.

Originally published on the Innostax Engineering Blog.

How to Use Multiple Prettier Plugins for Consistent Code Formatting ?

Sahil Khurana — Fri, 05 Jun 2026 07:40:37 +0000

Incorporating Multiple Prettier Plugins

I've sat in code reviews where a perfectly decent PR stayed open for two days. Tests green. Logic sound. But somewhere around comment fifteen, the thread had devolved into a debate about trailing commas — and at that point, nobody was reviewing code anymore. They were defending preferences.

That's not a people problem. It's a tooling problem. And Prettier — especially paired with the right set of plugins — solves it completely. The multi-plugin setup most tutorials gloss over is worth the extra thirty minutes to configure.

💡 The short version: A codebase where nobody argues about formatting isn't a utopia. It's what happens when you hand that decision to a tool and tell everyone to move on.

Key Takeaways

Manual formatting consistency breaks down fast. Two developers with different editor settings will produce two versions of the same file. Prettier removes that variable entirely — same output, every time, from everyone.
Formatting time is hidden until you measure it. Across a team running 15–20 PRs a week, the minutes lost to formatting debates add up to roughly a full engineer-day per sprint. That time disappears the moment Prettier is wired in.
Plugins extend Prettier to your full stack — not just JavaScript. One config file, one command, consistent formatting across every language your project touches.
Better plugins mean sharper editor integrations — more accurate autocomplete, earlier error detection, and language server suggestions that actually fit the code you're writing.

Why Prettier Exists — and Why It Took Off

Clean code means more than working code. It means code that someone else can sit down with at 11pm during an incident — exhausted, slightly stressed — understand in under a minute, and modify without second-guessing every formatting choice the original author made.

Prettier was built to clear that bar automatically. It's an open-source formatter, free and opinionated by design. You don't configure Prettier to match your preferences. You configure your preferences to match Prettier.

That sounds like a frustrating trade-off until you realize the whole point is removing formatting from the list of things anyone has to think about. Once developers stop spending review cycles on formatting, the quality of technical feedback on everything else goes up. That's a pattern, not a coincidence.

Out of the box, Prettier handles JavaScript, TypeScript, CSS, HTML, Markdown, JSON, YAML, GraphQL, and a few others — which covers the core of most web stacks. But most real projects are messier. A PHP backend here, a Go microservice there, some XML config nobody wants to touch. That's where plugins come in.

What Prettier Actually Does Under the Hood

This matters more than most tutorials suggest — especially once you start working with plugins.

Prettier doesn't scan your code looking for violations the way a linter does. It parses your source file into an abstract syntax tree — a structured representation of what the code means, stripped of all formatting — and then reprints that tree from scratch, according to its own rules. The original file's formatting is irrelevant. What comes out is always Prettier's version.

That's why Prettier is so consistent. It's not fixing your formatting. It's replacing it.

It also explains why parser support matters so much. If Prettier can't parse a language, it can't format it. Every language needs its own parser, and that parser either ships with Prettier or comes via a plugin. No parser, no formatting — full stop.

Why Multiple Plugins? The Real Argument.

The base Prettier install handles JavaScript and the web stack well. Here's where teams usually run into friction: they set up Prettier, it works beautifully on JavaScript files, and then someone notices it's doing nothing for the SCSS files. Or the PHP templates. Or the GraphQL schemas.

So those files stay inconsistently formatted. The value of having a formatter drops proportionally. Plugins fix this.

Language-specific formatting — and why "good enough" isn't

A generic formatter applied to Python code will produce something syntactically valid but wrong in feel — wrong enough that any developer who writes Python regularly will notice on first read. Same with Go. Same with Ruby. A well-written language plugin carries the formatting expectations of that language's community. It doesn't just make the code consistent — it makes it feel like it belongs.

Framework awareness — more specific than you'd expect

Framework-specific plugins go a step further. A React plugin doesn't just understand JSX syntax — it understands how JSX is supposed to look. Self-closing tags, prop order, multi-line JSX parentheses. That said, check the last commit date before committing to one in a long-lived project. A formatter that hasn't been updated in 18 months may not understand newer framework patterns.

The productivity argument — what "saves time" actually means

Every decision has a cognitive cost. Across a full workday, eliminating a whole category of low-stakes decisions — "should this trailing comma be here?" — hands attention back to things that actually need it. Not just fewer minutes spent formatting — fewer interruptions to flow.

Setting It Up — What the Process Actually Looks Like

Three steps. No magic.

Step 1: Install everything at once

npm install --save-dev prettier \\

prettier-plugin-tailwindcss \\

@prettier/plugin-php \\

prettier-plugin-organize-imports

Use your package manager to pull in Prettier and whatever plugins you need. Grab them all in a single install command.

Step 2: Write one config file

Create a .prettierrc or prettier.config.js at the project root:



"semi": true,

"singleQuote": true,

"trailingComma": "es5",

"printWidth": 100,

"plugins": \[

"prettier-plugin-tailwindcss",

"@prettier/plugin-php",

"prettier-plugin-organize-imports"

\]

Prettier picks this up automatically. One file. One place.

Step 3: Run it — and set it to run automatically

npx prettier --write .

Formats everything. The first time you run this on a codebase that's never had a formatter, expect a large diff — sometimes thousands of files. Every single change is cosmetic. Nothing functional. After that first run, most teams wire Prettier into a pre-commit hook via lint-staged.

What Prettier Handles Natively — and Where Plugins Pick Up

Native support covers the core of modern web development:

JavaScript (JS) and TypeScript (TS), including JSX and TSX variants
CSS, HTML, and Markdown
JSON and YAML
GraphQL queries
Vue.js single-file components
Handlebars templates

Languages without native support: C, C++, Rust, Java, Python, Ruby, PHP, Bash, XML (outside JSX), LaTeX, Perl, SQL. Several have community-maintained plugins — PHP is the most mature example.

Parsers: The Mechanism Behind the Formatting

A parser reads source code and converts it into a format Prettier can work with — specifically, an abstract syntax tree. That tree represents the structure and meaning of the code, independent of how it's formatted.

Prettier ships with parsers for everything it natively supports: Babel for modern JavaScript including JSX, TypeScript natively, Flow for annotated JavaScript, and separate parsers for CSS, SCSS, Less, HTML, Markdown, JSON, YAML, GraphQL, Vue.js, Handlebars, and Angular templates.

When you install a language plugin, what you're really installing is a parser for that language plus the formatting rules Prettier should apply once it has the AST. That's the whole mechanism.

What This Looks Like in a Real Project

Take a moderately sized React codebase — six developers, forty or fifty component files. Without Prettier, the codebase accumulates inconsistency over time. Not because anyone is careless, but because developers set up their editors differently, make different calls under deadline pressure, and inherit formatting decisions from whoever wrote the file first.

After Prettier: every file looks like it came from the same hand. The JSX is consistent. Import blocks follow the same order. Prop formatting doesn't shift between components. New developers can read any file without mentally translating between styles — which in practice is one of the more reliable ways to cut ramp-up time for new hires.

The change in code review is equally noticeable. When formatting is handled automatically, reviewers stop leaving comments about it. The discussion shifts to logic, architecture, edge cases — the parts that actually benefit from human attention.

The Case for Boring Infrastructure

Prettier doesn't ship features. It doesn't write better algorithms or make architectural decisions. What it does — with very little ongoing effort — is eliminate an entire category of low-value friction from development.

Multiple plugins extend that to the full surface of a real-world project. One tool. One config. One command.

Prettier isn't a silver bullet, and it's worth being clear about that. It handles formatting, not code quality. You still need linters for logic issues, code review for architectural decisions, and experienced developers to catch the things tools miss. But for the specific problem it solves — consistent formatting across a shared codebase — it solves it completely.

Set it up once. Wire it into your workflow. Then take formatting off the agenda permanently.

Sahil Khurana - CTO, Innostax

About Innostax

Founded in 2014, Innostax is a software development company built on accountability and ownership. We deliver progress with clarity—flagging risks early, aligning teams, and ensuring quality at every step. With a commitment to responsibility and reliability, we take full ownership of everything we build, making software development seamless and dependable.

Serverless Framework Deployment: Unleash the Power of AWS Lambda

Sahil Khurana — Thu, 04 Jun 2026 09:45:24 +0000

Let me tell you exactly what happened the first time I tried to set up Lambda manually.

Four hours. IAM trust policies I didn't fully understand, ARNs copy-pasted into the wrong fields, an API Gateway that was technically configured but somehow not routing anything correctly, and a deploy that failed with an error message pointing me nowhere useful. I hadn't written a single line of actual business logic yet.

That's when someone on my team mentioned the Serverless Framework. My first reaction was honestly skepticism — another abstraction layer sounded like another thing to learn and eventually fight with. I was wrong about that.

This isn't a "look how clean this tool is" post. It's more like: here's what I actually did to get a Postgres-backed CRUD API running on Lambda, step by step, including the parts that tripped me up.

What the Framework Is Actually Doing Under the Hood

Worth knowing before you start: the Serverless Framework isn't magic. It's generating CloudFormation templates and submitting them to AWS on your behalf. Your Lambda functions, API Gateway routes, CloudWatch log groups — all of it gets provisioned from a single config file.

It works with other providers too, but the AWS integration is where it really earns its keep. The console clicking and manual ARN-wiring that burns time at the start of every serverless project? Gone. Same deploy workflow whether you're building a REST API, an event processor, or a cron job. Once you've done it once, the second project takes a fraction of the time.

What You're Building

Four live endpoints backed by PostgreSQL. A Users table. Create, read, update, delete — nothing exotic, but a real enough foundation that you can extend it into something actual once this guide is done.

You'll need an AWS account, the AWS CLI installed, and the Serverless Framework installed before starting. That's it.

Step 1: Sort Out Your AWS Credentials

Run this to create both config files in one go:

bash
cat <<EOF > ~/.aws/credentials
[default]
aws_access_key_id = <REPLACE_WITH_YOUR_SECRET_KEY>
aws_secret_access_key = <REPLACE_WITH_YOUR_ACCESS_KEY>
EOF

cat <<EOF > ~/.aws/config
[default]
region = eu-west-1
output = json
EOF

Replace the placeholders with your actual keys. I'm using eu-west-1 — swap in whatever region makes sense for where you're deploying.

Step 2: The IAM Role (Seriously, Don't Skip This)

Okay so this is the one that burned me the first time around. The Serverless Framework needs an IAM role with the right permissions to provision resources during deployment. If you skip this, the deploy fails. The error you'll get doesn't say "hey you're missing an IAM role" — it says something vague about permissions and you'll spend a while chasing the wrong thing.
Create the role:

bash
aws iam create-role --role-name serverlessLabs --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}'

Attach the Lambda execution policy to it:

bash
aws iam attach-role-policy --role-name serverlessLabs \
  --policy-arn arn:aws:iam::aws:policy/AWSLambda_FullAccess

Verify it's actually there:

bash
aws iam get-role --role-name serverlessLabs

If you see role details, good. If you get an error, fix it here rather than finding out it's broken in step 7.

Step 3: Project Setup

bash
mkdir node-crud
cd node-crud
npm install -g serverless
npm i prisma
Then init Prisma:
bash
npx prisma init

Two things get created — a prisma/ directory with schema.prisma inside it, and a .env file at the root. The .env is where your database URL goes. Add it to .gitignore right now. Not later. Now.

Step 4: Database Schema
Open prisma/schema.prisma:

prisma
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Users {
  id    String  @id @default(uuid())
  name  String? @db.VarChar(255)
  email String? @db.VarChar(255)
}

Drop your connection string in .env:

env
DATABASE_URL="postgresql://<username>:<password>@<hosted dbURL>:5432/mydb?schema=public"
Now run these three, in this order, all three:
bash
npx prisma format
npx prisma generate
npx prisma migrate dev

format tidies the schema file. generate builds the Prisma client your functions will import. migrate dev actually creates the Users table in your database. If migrate dev fails, stop here and figure out why — your connection string is probably wrong.

Step 5: The Handler Functions

handler.js at the project root:

javascript
const { PrismaClient } = require("@prisma/client");
const prisma = new PrismaClient();

module.exports.create = async (event) => {
  try {
    const { name, email } = JSON.parse(event.body);
    const newUser = await prisma.Users.create({ data: { name, email } });
    return { statusCode: 200, body: JSON.stringify(newUser) };
  } catch (error) {
    return { statusCode: 500, body: JSON.stringify({ error: "Failed to create user: " + error.message }) };
  }
};

module.exports.read = async () => {
  try {
    const users = await prisma.Users.findMany();
    return { statusCode: 200, body: JSON.stringify(users) };
  } catch (error) {
    return { statusCode: 500, body: JSON.stringify({ error: "Failed to fetch users: " + error.message }) };
  }
};

module.exports.update = async (event) => {
  try {
    const { id } = event.pathParameters;
    const { name, email } = JSON.parse(event.body);
    const updatedUser = await prisma.Users.update({
      where: { id: parseInt(id) },
      data: { name, email },
    });
    return { statusCode: 200, body: JSON.stringify(updatedUser) };
  } catch (error) {
    return { statusCode: 500, body: JSON.stringify({ error: "Failed to update user: " + error.message }) };
  }
};

module.exports.delete = async (event) => {
  try {
    const { id } = event.pathParameters;
    const deletedUser = await prisma.Users.delete({ where: { id: parseInt(id) } });
    return { statusCode: 200, body: JSON.stringify({ message: "User deleted successfully", deletedUser }) };
  } catch (error) {
    return { statusCode: 500, body: JSON.stringify({ error: "Failed to delete user: " + error.message }) };
  }
};

Same structure across all four — try the operation, return 200 with the result, catch and return 500 with the actual error message. I've debugged enough Lambda functions that swallow errors silently to know: always include error.message in the 500 response. Future you will appreciate it.

Step 6: serverless.yml

Wipe whatever's in there and replace with this:

yaml
service: postgres-crud-api
provider:
  name: aws
  runtime: nodejs18.x
functions:
  create:
    handler: handler.create
    events:
      - http:
          path: create
          method: post
  read:
    handler: handler.read
    events:
      - http:
          path: read
          method: get
  update:
    handler: handler.update
    events:
      - http:
          path: update/{id}
          method: put
  delete:
    handler: handler.delete
    events:
      - http:
          path: delete/{id}
          method: delete

The provider block sets the target cloud and runtime — Node 18.x here, though honestly check if there's a newer LTS available by the time you're reading this.
functions is where each handler export gets mapped to a route and HTTP method. API Gateway configuration is derived automatically from these entries — you're not touching it anywhere else.

The {id} segments in the update and delete paths become event.pathParameters.id inside the handler. So a request to /update/some-uuid hands you "some-uuid" to work with. That's all there is to it.

Step 7: Deploy

bash
sls deploy

Grab a coffee. Two minutes, give or take. When it finishes, your terminal shows the live API Gateway URLs for all four endpoints. Pop open the AWS console if you want to see what was built — Lambda functions, API Gateway config, CloudFormation stack, all of it created without you touching the console once.

Step 8: Testing

Postman, cURL, doesn't matter. Here's the order I'd go in:

GET /read first. Should return an empty array. If it throws an error instead, something's broken in the Lambda-to-Prisma connection and you want to know before you try writing data.

POST /create — send { "name": "Jane", "email": "jane@example.com" }. Get back a user object with an id? Prisma is talking to Postgres. Lambda is executing. That's the hard part confirmed working.

PUT /update/{id} — use the id from whatever create returned. Change the name. Verify the response reflects it.

DELETE /delete/{id} — the response includes the record that got deleted, so you can confirm you removed the right one.

Create works, read returns it — the full chain is functioning. Everything else from here is adding more of the same.

What's Next

The setup is the slow part. It's done. Adding a new endpoint now is: write the handler function, add the route to serverless.yml, run sls deploy. That's genuinely it.

Natural next steps: JWT auth if you're building anything that needs to be secured, environment variable separation for staging vs production (set it up early, not after you've already deployed to prod by accident), more Prisma models for additional tables, more complex query logic inside the existing handlers.

The deployment model doesn't change regardless of what you add to the application. That's the whole point of it.

At Innostax, we've helped engineering teams get through exactly this — serverless setup on AWS, Prisma + Postgres wiring, IAM configurations that don't silently break at deploy time — and built it into backends that hold up past the prototype stage. If you're figuring out the right serverless foundation for your project, innostax.com/contact is where that conversation happens.

Originally published on the Innostax Engineering Blog.

Redux Thunk vs Saga: Choosing the Best Middleware

Sahil Khurana — Wed, 03 Jun 2026 08:17:24 +0000

Here's the situation that gets everyone eventually.

Your Redux setup is clean. Actions dispatch, reducers update state, components re-render, the whole pipeline works exactly like it's supposed to. Then a requirement lands that needs an API call, and suddenly you're staring at a reducer wondering where exactly you're supposed to put a fetch().

You search around. Two names come up constantly: Redux Thunk and Redux Saga. Both solve async side effects in Redux. That's roughly where the similarity ends.

I've shipped production apps with both. They're not interchangeable and the difference isn't just syntax, it's a fundamentally different way of thinking about async control flow. Picking the wrong one for your project's complexity level will cost you later, usually at the worst possible time.

Quick context on what Redux actually does

For anyone newer to this: Redux centralizes your application state in a single store. Components don't manage their own data — they read from the store and dispatch actions to change it. Every state change flows through the same path: action dispatched → reducer processes it → store updates → components re-render.

The connect function from react-redux wires this into your components. It's elegant when it works, and for synchronous state changes it works really well.

The issue is that reducers have to be pure functions. No side effects, no async operations, nothing with unpredictable timing. A fetch call inside a reducer isn't just bad practice — it fundamentally breaks the model. Redux has no built-in answer for this. Thunk and Saga are both third-party answers to that gap, just wildly different ones.

Redux Thunk: Functions returning functions

Thunk's insight is simple. Normally an action creator returns a plain object. Thunk middleware intercepts action creators that return functions instead, and calls them with dispatch and getState. That's the whole trick.

javascript
const fetchData = () => {
  return (dispatch, getState) => {
    api.fetchData()
      .then(data => {
        dispatch({ type: 'FETCH_SUCCESS', payload: data });
      })
      .catch(error => {
        dispatch({ type: 'FETCH_ERROR', payload: error });
      });
  };
};

Why does this work so well for simple cases? Because it's just JavaScript. Functions returning functions — closures, promises, .then() chains. Nothing here requires learning a new paradigm. A developer who's never touched Redux middleware before can read a thunk file and understand what it's doing in about ten minutes.

That's genuinely valuable, and I don't want to undersell it. Fast onboarding matters.

What Thunk doesn't give you is structure for when things get complicated. Need to cancel a request if the user navigates away? Manual. Race condition where two requests fire and you only want the last one? Manual. Multiple async operations that need to coordinate? You're building that coordination logic yourself, in the thunk, and it gets messy fast. I've seen thunk files that are 200 lines of nested promise chains that technically work but that nobody wants to touch.

Redux Saga: A completely different mental model

Saga takes an approach that seemed strange to me when I first encountered it. Instead of intercepting action creators, Saga runs persistent background processes — "sagas" — that watch for specific actions and respond with their own async logic. They live entirely separately from your normal Redux flow.

javascript
function* fetchDataSaga() {
  try {
    const data = yield call(api.fetchData);
    yield put({ type: 'FETCH_SUCCESS', payload: data });
  } catch (error) {
    yield put({ type: 'FETCH_ERROR', payload: error });
  }
}

function* watchFetchData() {
  yield takeEvery('FETCH_REQUEST', fetchDataSaga);
}

The function* and yield syntax is what stops people cold. Generator functions aren't something most JavaScript developers use regularly, and the first time you see yield call(api.fetchData) instead of just await api.fetchData(), it raises obvious questions about why you'd add that layer of indirection.

The answer becomes clear when complexity hits. takeEvery, takeLatest, race, cancel — these are built-in Saga effects for patterns that Thunk handles awkwardly at best. takeLatest automatically cancels any previous in-flight request when a new one fires. One line. In Thunk that's a manual cancellation token, a ref, conditional dispatch logic. It's doable but it's work.

Once generators click — and it takes a few days of actual use, not just reading about them — the sequential-looking flow of a saga is easier to reason about than deeply nested promise chains. That's the tradeoff: steeper upfront cost, better ceiling.

The testing difference is bigger than people realize

This is something the comparison articles usually gloss over.
Testing a thunk is quick:

vascript
const store = mockStore({});
await store.dispatch(fetchData());
expect(store.getActions()).toEqual([{ type: 'FETCH_SUCCESS', payload: mockData }]);

You call it, check what got dispatched, done. If you're moving fast and the async logic is simple, this is a real advantage.
Testing a saga is more involved. You're stepping through a generator, asserting on each yield effect:

javascript
const gen = fetchDataSaga();
expect(gen.next().value).toEqual(call(api.fetchData));
expect(gen.next(mockData).value).toEqual(put({ type: 'FETCH_SUCCESS', payload: mockData }));

There's more setup. Libraries like redux-saga-test-plan help significantly. The end result is actually more thorough coverage of your async behavior — you're testing the logic of the saga step by step, not just the final dispatched actions. But it takes longer to write. That's just true.

So which one

Genuinely depends on where your app is and where it's going.

Simple app, a handful of API calls, standard loading/error states, team that needs to move quickly — Thunk. There's no complexity justifying the Saga investment and adding it anyway just creates overhead without payoff.

Larger app, async operations that need to cancel each other, coordinate with each other, debounce, handle race conditions — Saga. The generator model that feels awkward in week one becomes the thing you're grateful for in month six when you need to add cancellation to something and it takes an hour instead of a day.

The mistake I see most often is teams adopting Saga on a simple app because it seems more "professional," then spending weeks onboarding developers onto generator syntax for async logic that a few thunks would have handled fine. The other mistake is teams sticking with Thunk on a growing application well past the point where the complexity is screaming for something more structured.

Neither is universally better. They solve different versions of the same problem.

At Innostax, we've helped React teams make this exact call — Thunk when the complexity didn't warrant more, Saga when it did, and migrated between the two when an app outgrew its original choice. If you're figuring out the right async architecture for your Redux application, innostax.com/contact is where that conversation happens.

Originally published on the Innostax Engineering Blog.