DEV Community: Soumyajit Mukherjee

🧠 Building a Mental Health Prediction System with Machine Learning, SHAP & Flask

Soumyajit Mukherjee — Wed, 26 Aug 2026 09:17:56 +0000

I built an end-to-end Mental Health Prediction & Assessment System that combines machine learning, standardized screening, Explainable AI and a web application.

The objective was to explore what a more complete ML application looks like beyond simply training a model in a Jupyter Notebook.

🚀 What does the application do?

The system combines two major components:

1. Machine-learning-based risk prediction
2. PHQ-9-based clinical symptom screening

The results are presented through a web interface with additional explainability and support features.

🤖 Machine Learning Pipeline

I evaluated multiple classification algorithms:

AdaBoost
Random Forest
XGBoost
Logistic Regression

After tuning and evaluation, the AdaBoost classifier achieved approximately 86.9% accuracy and was selected as the final model.

Model evaluation included:

Confusion matrices
ROC-AUC curves
Precision-Recall metrics

🩺 PHQ-9 Integration

One of the more interesting parts of the project is the integration of the Patient Health Questionnaire (PHQ-9).

The questionnaire contains nine questions and generates a score from 0 to 27.

The project uses this standardized screening layer alongside the machine-learning prediction rather than presenting the ML model as a medical diagnosis.

🔍 Explainable AI with SHAP

A prediction is much more useful when users can understand why a model reached it.

That's why I integrated SHAP (SHapley Additive exPlanations).

The application generates visual explanations showing how individual features contributed to a particular prediction.

This turns:

"The model predicted this."

into:

"These features contributed to the model's prediction."

That's an important distinction when building responsible ML applications.

🏗️ Architecture

The application uses:

User
  ↓
Web Interface
  ↓
Flask Application
  ↓
Data Processing
  ↓
ML Model
  ↓
Risk Prediction
  ↓
SHAP Explanation
  ↓
Result Dashboard

The project also contains serialized ML artifacts such as the trained model, preprocessing transformer and label encoder.

🛠️ Technology Stack

Machine Learning

Python 3.12
Scikit-learn
XGBoost
Pandas
NumPy
SHAP

Backend

Flask
Gunicorn

Frontend

HTML5
CSS3
Bootstrap 5
Jinja2

DevOps

Docker
Render
GitHub Actions

🚀 Beyond Machine Learning

I also implemented additional application functionality:

Interactive mental-health assessment
SHAP visualization
Counselling booking interface
Crisis assistance information
Docker-based deployment
Automated uptime monitoring

The goal was to turn the ML experiment into an actual end-to-end web application.

📚 What I Learned

This project reinforced several important lessons:

1. Accuracy isn't everything
A model can have good accuracy and still be unsuitable for real-world use without considering context, limitations and safety.

2. Explainability matters
SHAP helped make the model's predictions easier to inspect.

3. Deployment changes everything
Moving from a notebook to Flask + Docker + Gunicorn introduced an entirely different set of engineering challenges.

4. Sensitive domains require extra caution
Mental-health applications should never present an ML prediction as a definitive medical diagnosis.

🔗 Source Code

The complete project is available on GitHub:

Click Here

The repository also includes the Flask application, trained model artifacts, notebook, dataset, Docker configuration and requirements.

If you're learning Machine Learning, Flask, Explainable AI or ML deployment, I'd love to hear your feedback.

Building Better Error Handling in Node.js

Soumyajit Mukherjee — Fri, 14 Aug 2026 10:56:43 +0000

Error handling is one of those topics developers often ignore until production starts failing.

A good error-handling strategy makes an application easier to debug, monitor, and maintain.

The Problem With Random try/catch Blocks

You might see code like:

try {
  await doSomething();
} catch (error) {
  console.log(error);
}

This prevents an immediate crash, but it doesn't necessarily solve the problem.

What should happen next?

Should the API return 500?

Should the error be logged?

Should the request be retried?

Should the user receive a friendly message?

Centralized Error Handling

Express applications can use centralized middleware:

app.use((err, req, res, next) => {
  console.error(err);


  res.status(500).json({
    message: "Something went wrong"
  });
});

Application code can then pass errors to the middleware.

Separate Operational and Programming Errors

Not every error means the same thing.

An invalid request:

400 Bad Request

is very different from:

Database connection unexpectedly failed

The first may be expected.

The second might require immediate investigation.

Don't Leak Sensitive Information

Avoid returning:

{
  "error": "MongoServerError: password authentication failed..."
}

to users.

Internal details belong in secure logs.

Users generally need a useful but safe message.

Logging Matters

A production system should record useful context:

timestamp
request ID
endpoint
user/session context where appropriate
error type
stack trace

A request ID is particularly useful when tracing one request through multiple services.

Final Thoughts

Good error handling isn't about hiding errors.

It's about making errors understandable, observable, and safe.

Understanding Database Indexes Without the Jargon

Soumyajit Mukherjee — Fri, 14 Aug 2026 10:47:49 +0000

Database indexes are one of the simplest ways to improve query performance.

They can also become one of the easiest ways to waste resources if used incorrectly.

What Is an Index?

Imagine a 500-page book.

If you want to find every mention of "MongoDB", you could read every page.

Or you could use the index at the back of the book.

A database index works similarly.

Instead of scanning every record, the database can use an optimized data structure to locate matching records faster.

Example

Suppose you frequently search users by email:

db.users.findOne({
  email: "alex@example.com"
});

Creating an index on email can make this query much more efficient:

db.users.createIndex({
  email: 1
});

Why Not Index Everything?

Indexes have costs.

When data changes, indexes may also need to be updated.

That means more:

Storage
Memory usage
Write overhead
Maintenance

Therefore, indexes should be created around actual query patterns.

Compound Indexes

Sometimes queries use multiple fields:

db.orders.find({
  userId: "123",
  status: "completed"
});

A compound index could help:

db.orders.createIndex({
  userId: 1,
  status: 1
});

The correct index depends on how the application queries the database.

Measure Before Optimizing

Don't blindly create indexes.

First identify slow queries using database profiling and query execution plans.

Optimization should be based on evidence.

Final Thoughts

Indexes are not magic performance switches.

They are tools that trade additional storage and write overhead for faster reads.

Understanding that trade-off is an important database skill.

Redis Explained: Why Developers Keep Putting It in Their Stack

Soumyajit Mukherjee — Fri, 14 Aug 2026 10:36:47 +0000

Redis is often described as an in-memory database, but its usefulness goes far beyond simply storing key-value pairs.

It is commonly used for:

Caching
Sessions
Rate limiting
Queues
Pub/Sub
Temporary data
Distributed locks

Why Is Redis Fast?

Traditional databases usually need to access persistent storage.

Redis primarily operates in memory.

For example:

await redis.set("user:123", JSON.stringify(user));

Later:

const user = await redis.get("user:123");

Because the data is stored in memory, operations can be extremely fast.

Redis as a Cache

Suppose your application repeatedly requests a product:

GET /products/123

Without caching:

Application → Database → Application → User

With caching:

Application → Redis
                ↓
              Cache Hit

The database doesn't need to process every request.

Cache Expiration

Cached data should often expire.

await redis.set(
  "product:123",
  JSON.stringify(product),
  { EX: 300 }
);

This stores the value for five minutes.

Expiration prevents stale data from remaining indefinitely.

Redis for Rate Limiting

Imagine an API allowing 100 requests per minute.

Redis can track request counts:

rate-limit:user123 = 87

Once the count exceeds the limit, the application can reject additional requests.

Don't Put Everything in Redis

Redis shouldn't automatically replace your primary database.

A relational or document database is usually responsible for durable application data.

Redis is often better suited for fast, temporary, or coordination-related data.

Final Thoughts

Redis is valuable because it solves several performance and distributed-system problems with a relatively simple interface.

Learning Redis is especially useful for backend developers working on production systems.

Why API Versioning Matters More Than You Think

Soumyajit Mukherjee — Fri, 14 Aug 2026 09:55:09 +0000

APIs eventually change.

A field gets renamed. A response structure changes. Authentication is redesigned. A new feature requires breaking an existing contract.

The problem isn't changing the API.

The problem is changing it without breaking existing clients.

The Problem With Unversioned APIs

Imagine your API initially returns:

{
  "name": "John",
  "email": "john@example.com"
}

Later, you decide to return:

{
  "fullName": "John",
  "emailAddress": "john@example.com"
}

Your frontend might immediately break.

If multiple mobile applications, third-party integrations, and websites consume the API, the problem becomes much larger.

URL Versioning

One simple approach is:

/api/v1/users
/api/v2/users

The original clients continue using v1.

New applications can use v2.

For example:

app.get("/api/v1/users", getUsersV1);
app.get("/api/v2/users", getUsersV2);

Header-Based Versioning

Another approach is to specify the version through headers.

Accept: application/vnd.example.v2+json

This keeps URLs cleaner but requires more careful client configuration.

When Should You Create a New Version?

Not every change requires a new API version.

Adding a new optional field usually doesn't require one.

Changing:

{
  "username": "alex"
}

into:

{
  "username": {
    "value": "alex"
  }
}

probably does.

Breaking changes generally deserve a new version.

Versioning Is Also Communication

API versions communicate expectations.

When developers see:

/api/v1/

they immediately know that changing the contract could affect existing consumers.

Final Thoughts

API versioning is an investment in stability.

You may not need it when building your first small application, but understanding it early will make you a better backend developer.

Understanding Event-Driven Architecture in Modern Applications

Soumyajit Mukherjee — Fri, 14 Aug 2026 09:17:04 +0000

Event-driven architecture is one of the most useful patterns for building applications that need to react to events instead of executing everything in a strict request-response sequence.

Instead of thinking:

User does something → Server performs everything → Response

we can think:

User does something → Event is created → Interested services react to it

What Is an Event?

An event represents something that happened.

For example:

{
  type: "USER_REGISTERED",
  userId: "12345",
  timestamp: Date.now()
}

Other parts of the application can listen for this event and perform their own tasks.

For example:

Email service sends a welcome email.
Analytics service records the registration.
Notification service creates a notification.
Recommendation service creates initial recommendations.

The registration service doesn't necessarily need to know how all of these tasks work.

Why Use Event-Driven Architecture?

The biggest advantage is decoupling.

A traditional implementation might look like:

await createUser();
await sendEmail();
await updateAnalytics();
await createNotification();

If the email service becomes slow, the entire operation can become slow.

With events:

await createUser();


publishEvent({
  type: "USER_REGISTERED",
  userId: user.id
});

Other services can process the event independently.

Where Is It Useful?

Event-driven systems are particularly useful for:

Payment processing
E-commerce
Notifications
Analytics
Microservices
IoT systems
Background processing
Real-time applications

The Trade-Off

Event-driven architecture isn't automatically better.

It introduces additional complexity:

Event delivery failures
Duplicate events
Ordering problems
Debugging difficulties
Event schema management

For a small CRUD application, a simple architecture may be much easier.

Final Thoughts

Event-driven architecture is less about using a specific technology and more about changing how application components communicate.

Once your application grows beyond a simple monolith, understanding events, queues, consumers, producers, and asynchronous processing becomes extremely valuable.

Swagger Isn't Just API Documentation

Soumyajit Mukherjee — Sun, 09 Aug 2026 09:54:10 +0000

If you've worked with REST APIs, you've probably encountered Swagger.

Many developers initially think:

Swagger = API documentation

That's not completely wrong, but it's incomplete.

Swagger is an ecosystem of tools built around the OpenAPI Specification (OAS) that can help with API design, documentation, testing, validation, code generation, and collaboration.

OpenAPI vs Swagger

Before looking at the tools, understand this distinction:

OpenAPI is the specification used to describe an API.

Swagger is a collection of tools that work with OpenAPI definitions.

An OpenAPI document can describe:

API endpoints
HTTP methods
Parameters
Request bodies
Responses
Authentication
Data schemas

Once you have that definition, different tools can consume it.

The Swagger Toolkit

Swagger UI

Swagger UI turns an OpenAPI definition into interactive documentation.

Instead of giving developers a YAML file, you can give them a browser-based interface where they can explore endpoints and, depending on configuration, execute requests.

Great for:

API documentation
Development testing
Developer onboarding

Swagger Editor

Swagger Editor allows developers to create and edit OpenAPI definitions.

It's particularly useful for API-first development because you can design the contract before implementing the API.

Swagger Codegen

Code generation can eliminate repetitive work.

Swagger Codegen can generate client libraries and server-side boilerplate from an OpenAPI definition for supported languages and frameworks.

SwaggerHub

SwaggerHub provides a collaborative environment for API design and management.

It becomes especially useful when multiple developers or teams need to work with shared API definitions.

Swagger Validator

Validation helps catch problems in OpenAPI definitions.

This is useful for maintaining API quality and integrating API specification checks into development workflows.

Swagger Inspector

Inspector helps developers explore and test APIs and can assist with creating OpenAPI definitions from existing API traffic.

It's useful when working with APIs that were built without proper documentation.

Real-World Example

Imagine you're building an e-commerce backend.

You have:

GET    /products
POST   /products
GET    /products/{id}
PUT    /products/{id}
DELETE /products/{id}
POST   /orders
GET    /orders/{id}

Instead of maintaining a separate document describing every endpoint, you create an OpenAPI definition.

That definition can then become:

Documentation → Swagger UI

Design environment → Swagger Editor

Generated code → Swagger Codegen

Team collaboration → SwaggerHub

Specification validation → Validator

This is why OpenAPI becomes much more powerful than simply writing API documentation manually.

Where Is Swagger Useful?

Swagger/OpenAPI is commonly useful for:

✅ REST API documentation
✅ API-first development
✅ API testing
✅ Client SDK generation
✅ Server boilerplate generation
✅ Frontend/backend collaboration
✅ API contract management
✅ Developer onboarding
✅ Automated validation
✅ Large API ecosystems

The Bigger Picture

A good API development workflow might look like:

Design API

↓

Define OpenAPI contract

↓

Review contract

↓

Implement API

↓

Generate documentation

↓

Test endpoints

↓

Validate specification

↓

Publish API

This creates a shared contract between the people building and consuming the API.

Final Thought

If you're learning backend development, don't stop at:

"I know how to create REST endpoints."

Learn how to design, document, test, and communicate those endpoints professionally.

OpenAPI + Swagger is a great toolset for doing exactly that.