Coder Legion - Recent posts tagged backenddevelopment

Entity Framework Core Patterns I Actually Use in Production

Wed, 28 Oct 2026 18:49:25 +0000

There is a gap between knowing how Entity Framework Core works and knowing how to use it in a way that holds up under real conditions. The documentation will teach you the first thing. Production will teach you the second, usually by showing you what happens when you get it wrong.

This post is not a tutorial. It is not a comprehensive guide to EF Core features. It is a walkthrough of the specific patterns I apply consistently across every .NET project I build, with the reasoning behind each one. The patterns themselves are not exotic. The discipline of applying them deliberately is what separates a codebase that ages well from one that accumulates quiet performance problems and confusing data states.

If you are past the getting-started stage with EF Core and want to understand how experienced developers think about it in production, this is written for you.

Knowing how EF Core works and knowing how to use it without creating problems at scale are two different skills. Production teaches you the second one.

ASNOTRACKING: THE DEFAULT YOU SHOULD BE QUESTIONING

By default, every entity you query through EF Core gets attached to the change tracker. The change tracker watches that entity for modifications and uses those modifications to generate UPDATE statements when you call SaveChanges. This is the feature that makes EF Core convenient for write operations.

It is also overhead you are paying on every read operation, whether you need it or not.

For a read-only query, attaching entities to the change tracker gives you nothing. The entity is never going to be modified and saved. The tracking is pure cost: memory allocated to hold the snapshot, CPU cycles spent watching for changes, and a change tracker that grows with every query you execute in the same DbContext lifetime.

The pattern I apply is deliberate rather than default. Every query that exists purely to return data gets AsNoTracking. Every query that might lead to an update does not.

// Read-only: tracking adds no value here
var tasks = await _context.Tasks
    .AsNoTracking()
    .Where(t => t.AssignedUserId == userId)
    .ToListAsync();

// Write path: tracking is needed
var task = await _context.Tasks
    .FirstOrDefaultAsync(t => t.Id == id);

if (task != null)
{
    task.StatusId = newStatusId;
    await _context.SaveChangesAsync();
}

The practical impact becomes visible at scale. A dashboard that loads twenty entities without AsNoTracking is allocating tracking overhead for twenty objects the application will never modify. Multiply that across concurrent users and the cost is real.

The habit worth building is this: when you write a query, ask immediately whether the result will ever be written back. If the answer is no, add AsNoTracking before you move on. It is a two-second decision that compounds positively across the entire codebase.

THE N PLUS 1 PROBLEM: WHAT IT IS AND WHY IT KEEPS HAPPENING

The N plus 1 problem is one of the most common performance issues in applications built with ORMs, and it is easy to introduce without realising it because the code that causes it looks completely reasonable.

The pattern goes like this. You query a list of entities. Then, for each entity in that list, you access a navigation property that has not been loaded yet. EF Core executes a separate database query for each entity to load that property. One query to get the list, then one query per item in the list. If the list has fifty items, you have made fifty-one database round trips instead of one or two.

// This looks fine but is dangerous
var projects = await _context.Projects
    .AsNoTracking()
    .ToListAsync();

foreach (var project in projects)
{
    // Each iteration triggers a separate query
    var taskCount = project.Tasks.Count;
}

The fix is to load related data intentionally rather than letting EF Core load it lazily on demand. Include brings related entities into the initial query. Select projects only the fields you need. Both approaches consolidate the data retrieval into a single round trip.

// Explicit loading with Include
var projects = await _context.Projects
    .AsNoTracking()
    .Include(p => p.Tasks)
    .ToListAsync();

// Projection with Select: more efficient when you need specific fields
var projectSummaries = await _context.Projects
    .AsNoTracking()
    .Select(p => new ProjectSummaryDto
    {
        Id = p.Id,
        Name = p.Name,
        TaskCount = p.Tasks.Count
    })
    .ToListAsync();

The projection approach with Select is generally preferable when you are building read models or DTOs, because it gives the database engine the information it needs to execute an optimal query rather than loading full entity graphs and discarding most of the data in application code.

The N plus 1 problem does not look like a bug. It looks like working code. That is why it keeps shipping to production.

The discipline that prevents N plus 1 problems is reviewing every query that accesses navigation properties and asking whether those properties will be loaded by the time they are accessed. If the answer is uncertain, make it certain by being explicit about what gets loaded and when.

SOFT DELETES WITH LOOKUP TABLES

Hard deletes, where a record is physically removed from the database, are rarely the right choice for production data. They break audit trails, they complicate recovery scenarios, and they create referential integrity problems when other records depend on the deleted entity.

Soft deletes, where a record is marked as inactive rather than removed, solve these problems. The record stays in the database. Its relationships remain intact. The deletion is reversible. And you have a complete history of every state the record has passed through.

My approach to soft deletes connects directly to the lookup table convention I use for all status fields. Rather than adding a boolean IsDeleted column, every entity that supports soft deletion has a StatusId that references a shared Statuses lookup table. A status of Active means the record is live. A status of Deleted means it has been soft deleted. A status of Archived means it has been intentionally retired without deletion.

// Statuses lookup table
public class Status
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
}

// Entity with status-based soft delete
public class Task
{
    public int Id { get; set; }
    public string Title { get; set; } = string.Empty;
    public int StatusId { get; set; }
    public Status Status { get; set; } = null!;
}

The advantage over a boolean IsDeleted column is that the status field carries meaning beyond a binary active or inactive state. You can distinguish between a record that was deleted intentionally, one that was archived, one that is pending review, and one that is in draft, all within the same field, without adding columns or changing the schema.

Adding a new status is a data operation. You insert a row into the Statuses table. No migration required. No enum update. No redeployment. The application picks it up immediately because it is reading status values from the database rather than from a hardcoded list in code.

Filtering deleted records consistently

The operational discipline that makes soft deletes work is consistent filtering. Every query that should return active records needs to filter on status. If you add that filter in some places and forget it in others, deleted records surface unexpectedly and the soft delete pattern breaks down.

// Always filter by active status on read queries
var activeTasks = await _context.Tasks
    .AsNoTracking()
    .Where(t => t.StatusId == StatusIds.Active)
    .ToListAsync();

// Soft delete: update status, do not remove the record
var task = await _context.Tasks
    .FirstOrDefaultAsync(t => t.Id == id);

if (task != null)
{
    task.StatusId = StatusIds.Deleted;
    await _context.SaveChangesAsync();
}

EF Core global query filters are worth considering for applications where the filtered entity is accessed in many places. A global query filter defined on the DbContext applies automatically to every query for that entity type, which eliminates the risk of forgetting the filter in a particular repository method.

REPOSITORY METHODS THAT MATCH REAL USE CASES

The generic repository base covers the standard CRUD operations. In production, most of the interesting work happens in the specific repository interfaces that extend the generic base with query methods that match real application needs.

The principle I apply is that a repository method should represent a meaningful operation in the domain, not a thin wrapper around a LINQ query. The difference is in how the application code reads.

// Thin wrapper: the caller still needs to know too much
var tasks = await _taskRepository.GetAllAsync();
var userTasks = tasks.Where(t => t.AssignedUserId == userId
    && t.StatusId == StatusIds.Active).ToList();

// Domain-meaningful method: intention is clear at the call site
var userTasks = await _taskRepository
    .GetActiveTasksByUserAsync(userId);

The second version is easier to read, easier to test, and easier to optimise. The filtering happens in the repository, close to the database, rather than in application code after a full table scan. And the method name communicates intent in a way that a chain of LINQ operators does not.

This matters more as a codebase grows. A repository with well-named methods becomes a vocabulary for talking about the domain. A repository that returns raw IQueryable and lets callers filter arbitrarily becomes a leaky abstraction that is difficult to reason about and impossible to optimise consistently.

MANAGING DBCONTEXT LIFETIME

DbContext is designed to be a unit of work. It is meant to be created, used for a set of related operations, and disposed. It is not meant to be a long-lived singleton shared across the application.

In an ASP.NET Core application, the standard pattern is to register DbContext as a scoped service, which means one instance per HTTP request. This is correct for most use cases. Each request gets its own context, its own change tracker, and its own transaction boundary. When the request completes, the context is disposed and any uncommitted changes are discarded.

// Program.cs: register DbContext as scoped
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

The problems arise when DbContext escapes the scope it was designed for. Injecting it into a singleton service is the most common mistake. A singleton lives for the lifetime of the application. A scoped DbContext injected into a singleton effectively becomes a singleton itself, with a change tracker that accumulates state across every request the application handles until it is restarted.

If you need database access in a singleton or a background service, use IDbContextFactory to create a short-lived context for each operation, use it, and dispose it immediately. This gives you the database access you need without the lifetime mismatch that causes subtle and difficult-to-diagnose bugs.

THE MINDSET BEHIND THE PATTERNS

What these patterns have in common is that they require you to be deliberate rather than accepting defaults. EF Core defaults are designed to be convenient for getting started. They are not always the right choice for production, and the gap between convenient and correct widens as the application grows and the load increases.

The developers who use EF Core well in production are not the ones who know the most features. They are the ones who ask the right questions before writing each query: is this data going to be modified? What related data does this operation actually need? What happens to this record when it is deleted? How many database round trips is this operation making?

Those questions have good answers. Getting into the habit of asking them before writing the code, rather than after a performance problem surfaces, is what makes the difference.

CLOSING THOUGHT

EF Core is a powerful tool and a forgiving one. It will let you build something that works without understanding any of what is in this post. The cost of that forgiveness shows up later, in query logs, in memory profiles, and in data states that are difficult to explain. The patterns here are not about using EF Core correctly in an academic sense. They are about using it in a way you will not regret six months into a production system.

Why Does a Backend API Become Slow, and How Can We Fix It?

Wed, 21 Oct 2026 03:36:54 +0000

As a backend developer, I spend a lot of time thinking about what happens behind the scenes when someone uses an application. A user clicks a button, submits a form, or requests some information, and the backend has to process that request and return a response.

Everything looks simple when an application is small. But as the number of users and the amount of data increase, things can change quickly. An API that used to respond almost instantly may suddenly take several seconds to return the same information.

So, what actually makes a backend API slow, and how can we fix it?

The Problem: An API That Takes Too Long to Respond

Imagine you're building an e-commerce application using Java and Spring Boot. The application has an API that returns a list of products.

At first, the API works perfectly. It fetches product information from the database and returns the result to the frontend.

But after the application grows, users begin to complain that the product page takes too long to load.

There could be several reasons behind this problem:

The database is executing inefficient queries.
The API is retrieving more data than the frontend needs.
The application is making unnecessary database calls.
Multiple operations are being performed when they are not required.
The server is struggling to handle too many requests at once.

The first mistake would be to start changing the code without understanding the actual cause.

Before optimizing an API, we need to identify where the time is being spent.

Step 1: Measure the API Performance

The first thing I would do is measure the response time.

Instead of guessing, I would check application logs, database query execution times, and performance metrics to understand whether the delay comes from the database, application logic, or another part of the system.

For example, if an API takes 1,500 milliseconds to respond, I would investigate how much time is spent executing the database query and how much is spent processing the result.

This gives us a starting point.

In a Spring Boot application, tools such as Spring Boot Actuator and Micrometer can help expose useful application metrics. Database query logging and profiling can also help identify expensive operations.

The goal is simple: find the bottleneck before trying to fix it.

Step 2: Improve Database Queries

One common problem is retrieving unnecessary data.

Suppose the frontend only needs a product's name, price, and image URL. There is no reason to fetch every column from the database if the application doesn't need them.

A basic SQL query might look like this:

SELECT *
FROM products;

A more focused query would be:

SELECT name, price, image_url
FROM products;

This can reduce the amount of data transferred and processed, particularly when the table contains many columns or large fields.

Indexes can also improve performance when queries frequently filter or search by specific columns. However, indexes should be chosen based on actual query patterns because unnecessary indexes increase storage use and can slow down writes.

Small database improvements can make a noticeable difference when an API is called frequently.

Step 3: Avoid Unnecessary Database Calls

Another issue I would investigate is whether the application is making too many database queries.

For example, imagine an API returns 100 products. If the application executes one query to fetch the products and then another query for each product's category, it could make 101 queries instead of a smaller number of well-designed queries.

This is a common example of the N+1 query problem.

With Java and Spring Data JPA, the solution might involve a carefully designed fetch strategy, a projection, or a query that retrieves the required information together.

The right approach depends on the relationships between the entities and the data the endpoint actually needs.

I would also avoid blindly using eager loading everywhere, because loading too much related data can create a different performance problem.

Step 4: Return Only the Data the Client Needs

A backend API should have a clear responsibility: provide the information the client needs to complete a task.

Returning thousands of records in a single response is rarely a good choice when the user only needs to view a small portion of them.

Pagination can help.

For example, a Spring Data repository can support paginated queries:

Page<Product> findAll(Pageable pageable);

A service or controller can then request a specific page rather than loading every product at once.

For larger datasets, cursor-based pagination may be more suitable than offset-based pagination, depending on the use case.

The important thing is to make sure the API remains efficient as the dataset grows.

Step 5: Use Caching When It Makes Sense

Sometimes the same information is requested repeatedly even though it rarely changes.

Product categories, public configuration, and other relatively stable data may be good candidates for caching.

Spring provides caching support through annotations such as @Cacheable.

For example:

@Cacheable("productCategories")
public List<Category> getCategories() {
    return categoryRepository.findAll();
}

After the first successful lookup, subsequent calls can reuse the cached result, depending on the configured cache provider and cache rules.

However, caching is not a solution for every slow API. We need to consider expiration, invalidation, memory usage, and whether users might receive outdated information.

For frequently changing or sensitive data, caching requires additional care.

Step 6: Test the Changes

After making improvements, I would test the API again using the same conditions as before.

I would compare:

Average response time.
Higher-percentile latency, such as p95.
Database query count and execution time.
Error rates.
Resource usage under concurrent requests.

A change that makes one request faster but causes errors under heavy traffic is not a successful optimization.

Performance testing tools can help simulate multiple users and reveal problems that may not appear during ordinary development.

I would also keep automated tests in place to ensure that performance improvements don't accidentally change the API's expected behavior.

What I Learned From This Approach

The biggest lesson is that backend performance is not just about writing shorter code or choosing a faster programming language.

A well-designed API depends on several things working together: efficient database queries, sensible data retrieval, appropriate caching, reliable application logic, and good monitoring.

Java and Spring Boot provide useful tools for building APIs, but the framework cannot automatically make every design decision efficient.

As developers, we still need to understand what the application is doing and why a particular operation is taking too long.

I would rather spend time identifying the actual bottleneck than introduce unnecessary complexity in the name of optimization.

Final Thoughts

Building a backend API that works is one challenge. Keeping it reliable and responsive as the application grows is another.

When an API becomes slow, I think the best approach is to measure first, identify the problem, make a focused change, and test the result.

Good backend development is not only about making an application work today. It's about making sure it continues to work well as more users depend on it.

I'm interested in how other Java developers approach API performance. When you notice a slow endpoint in your application, what's the first thing you investigate: database queries, application logic, or something else?

My Journey as a Java Developer: Learning, Building, and Solving Problems Through Code

Sat, 10 Oct 2026 14:52:56 +0000

Software development is more than writing code. It is about understanding problems, finding practical solutions, and building applications that make people's work easier. As a Java Developer, I enjoy exploring how software works behind the scenes, improving my programming skills, and turning ideas into useful applications.

My journey in development is driven by curiosity, continuous learning, and the desire to become better at what I do every day.

Why I Chose Java Development

Java is one of the technologies that interests me because of its versatility, object-oriented approach, and ability to support reliable and scalable applications. From backend systems to enterprise-level software, Java provides a strong foundation for building applications that can grow and adapt to different requirements.

What I enjoy most is the process of understanding how a problem works and figuring out how to solve it through code. Sometimes the solution is simple, while other times it requires breaking the problem into smaller parts, testing different approaches, and learning from mistakes.

For me, programming is not just about making something work. It is about understanding why it works and finding ways to make it better.

My Approach to Writing Code

I believe that good software starts with clear thinking and well structured code. Writing code that works is important, but writing code that other developers can understand, maintain, and improve is equally valuable.

As I continue developing my skills, I focus on several important areas:

Java programming: Understanding core concepts and applying them to practical problems.
Object-oriented programming: Using classes, objects, encapsulation, inheritance, and polymorphism to organize code effectively.
Backend development: Learning how application logic, databases, and APIs work together to deliver useful functionality.
Problem-solving: Breaking complex challenges into manageable tasks and exploring efficient solutions.
Clean code: Writing readable, maintainable code that makes future improvements easier.

These areas help me build a stronger foundation and approach development tasks with more confidence.

Learning Beyond the Basics

Technology continues to evolve, and I believe developers should remain curious and open to learning. There is always something new to explore, whether it is a better programming technique, a different architectural approach, or a tool that improves the development process.

I enjoy experimenting with code, exploring new concepts, and learning from both successful projects and mistakes. Debugging is also an important part of this process. When something does not work as expected, I try to understand the root cause instead of simply looking for a quick fix.

Every bug can teach you something, and every project gives you an opportunity to improve.

I also recognize the importance of understanding the fundamentals before depending too heavily on frameworks or tools. Strong fundamentals make it easier to learn new technologies and adapt to different project requirements.

Building Reliable and Scalable Applications

One of my main interests is developing applications that are reliable, efficient, and easy to maintain. A good application should solve the immediate problem while also being flexible enough to support future changes.

This requires more than writing individual methods or classes. It involves thinking about application structure, data handling, error management, performance, and how different components communicate with each other.

As a Java Developer, I want to keep strengthening my understanding of backend architecture, database integration, REST APIs, testing, and software design principles. These skills are valuable for building applications that can handle real-world requirements.

I believe the best way to improve is to put knowledge into practice. Reading documentation and studying examples are useful, but building projects helps turn theoretical concepts into practical experience.

Challenges Are Part of the Process

Every developer faces challenges. Sometimes a problem seems straightforward until you start implementing the solution. Other times, an unexpected error forces you to rethink your approach.

I see these situations as opportunities to develop better problem-solving habits. Instead of giving up when something becomes difficult, I try to investigate the issue, test possible solutions, and understand what went wrong.

This mindset helps me become more patient and systematic when approaching technical problems.

Becoming a better developer is not about knowing everything. It is about being willing to learn, adapt, and keep improving.

Growing With the Developer Community

Software development is a continuous learning journey, and the developer community plays an important role in that process. Developers learn from sharing experiences, discussing different approaches, and helping one another overcome challenges.

I enjoy connecting with people who are passionate about technology, exploring their ideas, and learning how they approach software engineering problems.

I also believe that sharing knowledge is a useful way to reinforce what we learn. Explaining a concept, documenting a solution, or discussing a coding challenge can help both the writer and the reader gain a better understanding.

Through platforms like CoderLegion, I hope to share my experiences, exchange ideas, and connect with other developers who enjoy building useful things with technology.

My Goals as a Java Developer

My goal is to continue growing as a software developer by strengthening my Java knowledge, improving my problem-solving abilities, and gaining more practical experience in building real-world applications.

I want to explore better software design practices, understand scalable backend systems, and develop solutions that are useful, reliable, and maintainable.

I know that becoming a skilled developer takes time, practice, and consistency. There will always be new technologies to learn and new challenges to solve, and that is part of what makes this field interesting to me.

Final Thoughts

My journey as a Java Developer is built around learning, experimenting, solving problems, and creating better software. I enjoy the challenge of turning ideas into working applications and discovering new ways to write efficient, maintainable code.

I do not believe growth happens overnight. It comes from consistent effort, practical experience, curiosity, and the willingness to learn from mistakes.

I look forward to continuing this journey, building meaningful projects, sharing what I learn, and connecting with developers who share the same passion for technology.

Always learning, always building, and always looking for a better way to solve problems.

Building Reliable Backend Applications with C# and .NET

Tue, 06 Oct 2026 02:40:20 +0000

Backend development is more than writing code that works. For me, it is about building systems that are reliable, maintainable, secure, and capable of supporting real business needs.

My main experience is with C#, .NET, ASP.NET Core, SQL Server, and Entity Framework. I enjoy working on backend systems where there are real requirements to understand, databases to design, APIs to build, and performance problems to solve.

Turning Business Requirements into Backend Solutions

A typical project starts with understanding what the business actually needs. Before writing code, I try to understand the workflow, the data involved, and how different parts of the application will communicate.

Once the requirements are clear, I focus on creating a backend structure that is easy to maintain and can grow with the application.

This usually involves:

Designing backend architecture
Developing APIs with ASP.NET Core
Working with SQL Server databases
Creating data models with Entity Framework
Implementing authentication and authorization
Writing business logic in C#
Improving database queries and application performance
Debugging and maintaining existing applications

Working with Databases

A backend application is only as good as the data layer behind it.

I have worked extensively with SQL Server and Entity Framework, including database design, relationships, queries, stored procedures, migrations, and performance optimization.

One thing I have learned is that database performance should not be treated as an afterthought. A poorly designed query or database structure can affect the entire application.

Efficient database design and optimized queries can make a huge difference in application performance.

Building Secure APIs

Modern applications often depend heavily on APIs. I focus on creating APIs that are organized, predictable, and secure.

From handling requests and validation to authentication, authorization, error handling, and database communication, every layer needs to work together properly.

I also believe that an API should be designed with the consumers in mind. Clear responses, consistent error handling, and proper validation make applications much easier to maintain.

Performance and Problem Solving

Backend development often involves finding problems that are not immediately obvious.

An application may work correctly but become slow when the amount of data increases. A database query may work with a few records but become inefficient with thousands or millions of records.

That is where debugging and performance analysis become important.

I enjoy investigating these types of problems, finding the root cause, and improving the implementation rather than simply applying a temporary fix.

Maintaining Existing Applications

Not every project starts from scratch.

A large part of backend development can involve working with existing applications, understanding someone else's code, fixing bugs, improving functionality, and gradually making the system better.

This requires patience and the ability to understand existing architecture before making changes.

Good backend development is not always about rewriting code. Sometimes the best solution is improving what already exists.

Continuous Learning

Technology keeps changing, so there is always something new to learn.

Even while working primarily with C# and .NET, I continue exploring better development practices, modern backend architecture, API design, database optimization, and new tools that can improve the development process.

For me, programming is a continuous process of learning, building, debugging, and improving.

I enjoy taking a business requirement, breaking it down into smaller technical problems, and eventually turning those ideas into a backend system that people can actually use.

Always learning. Always building. Always looking for a better way to solve the problem.

AI - Powered Automatic Email Sending System for File Uploads

Wed, 09 Sep 2026 08:24:15 +0000

Introduction

In many organizations and educational environments, users frequently upload documents and then need to manually prepare and send emails containing information about those files.

This repetitive process can be time-consuming and inefficient.

To address this, I developed an AI-powered automatic email sending system that combines file uploads, document text extraction, AI-generated email content, and automated email delivery into a single workflow.

The project demonstrates how AI APIs can be integrated into a traditional PHP web application to automate document-based communication.

Project Overview

The system provides a web-based interface where users can upload documents.

Once a file is uploaded, the application:

Validates the uploaded file.
Extracts text from the document.
Sends the extracted content to an AI API.
Generates professional email content using AI.
Automatically sends the email using PHPMailer.
Displays success or error notifications to the user.

This creates a streamlined workflow:

Document Upload
      ↓
File Validation
      ↓
Text Extraction
      ↓
AI Processing
      ↓
Email Generation
      ↓
Automated Email Sending
      ↓
User Notification

Key Features

Smart File Upload Handling

The application provides a simple and responsive interface for uploading documents.

Before processing, uploaded files are validated to ensure that only supported and valid files are handled.

AI-Generated Email Content

Instead of manually writing an email for every uploaded document, the system uses an AI API to analyze the extracted document content and generate a professional email message.

This reduces repetitive work while maintaining consistent communication.

Automated Email Sending

After generating the email content, the system automatically sends the email to the intended recipient using PHPMailer.

This removes the need for users to manually copy the generated content and send the email themselves.

Multi-Format Document Processing

The system supports text extraction from multiple document formats, including:

PDF documents
Microsoft Word documents
Presentation files

The extracted text is then passed to the AI processing stage.

User-Friendly Notifications

Toast notifications and session-based alerts provide feedback to users throughout the workflow.

Users can easily identify whether an upload or email operation was successful or encountered an error.

Technologies Used

Backend

PHP
PHPMailer
AI API Integration

Document Processing

Smalot PDF Parser
PHPWord
PHP Presentation Reader

Frontend

HTML
CSS
JavaScript

System Workflow

The overall process can be represented as follows:

User
 │
 ▼
Upload Document
 │
 ▼
File Validation
 │
 ▼
Document Text Extraction
 │
 ▼
AI API Processing
 │
 ▼
Generate Email Content
 │
 ▼
PHPMailer
 │
 ▼
Send Email
 │
 ▼
Success / Error Notification

The main objective is to automate the communication process without requiring the user to manually read the uploaded document, write an email, and send it.

Why This Project Matters

Manual email preparation can become a bottleneck when organizations regularly process documents.

For example, consider an educational platform where lecturers upload course materials or reports and need to notify students or administrators whenever a document is uploaded.

Instead of:

Upload → Read Document → Write Email → Send Email

the process can be automated as:

Upload → AI Processing → Email Sent

This can help to:

Improve productivity
Reduce repetitive manual tasks
Improve communication consistency
Integrate AI into existing applications
Automate document-based workflows

Challenges Faced

Building the system involved several technical challenges.

Handling Different File Formats

Different document formats require different approaches for extracting their content.

Separate document-processing libraries were integrated to handle PDFs, Word documents, and presentation files.

Extracting Usable Text

Extracted document content is not always perfectly structured.

The system therefore needs to process the extracted content before sending it to the AI API.

AI Integration

Integrating AI-generated content into an automated backend workflow required handling API requests, responses, errors, and generated content appropriately.

Automated Email Delivery

Email delivery introduced additional considerations such as SMTP configuration, error handling, and secure handling of email credentials.

User Experience

Since multiple operations take place during the workflow, providing clear feedback to the user was important.

Toast notifications and session-based messages were implemented to make the process easier to understand.

Future Improvements

There are several features planned for future versions:

Support for additional file formats
AI-generated email subject suggestions
Email scheduling
Recipient management dashboard
Upload history tracking
Enhanced security and validation
Multi-user authentication
Processing and email delivery logs

These improvements could make the system more suitable for larger organizational environments.

Source Code

The complete source code is available on GitHub:

GitHub Repository - AI-Powered Automatic Email Sending System

Feel free to explore the project, provide feedback, or contribute improvements.

Conclusion

This project was a practical exploration of how AI can be integrated into existing web applications to automate repetitive workflows.

By combining:

File Uploads + Document Processing + AI + Email Automation

the system provides a practical approach to automating document-based communication.

The project also provided hands-on experience with PHP backend development, document parsing, API integration, automated email delivery, and workflow automation.

I look forward to further improving the project and exploring more ways to integrate AI into practical software solutions.

Also Published On

This article is also available on the following platforms:

LinkedIn: Read on LinkedIn
Medium: Read on Medium
AWS: Read on AWS
DEV Community: Read on DEV Community

Building a Multiplayer Backend with TypeScript and StreetJS

Mon, 31 Aug 2026 12:59:36 +0000

Multiplayer applications are fundamentally different from traditional REST APIs.

In a typical API, a client sends a request:

Client → Server → Response

A multiplayer game needs something closer to:

Player A ─┐
          ├──→ Server ──→ Player A
Player B ─┤              ├→ Player B
Player C ─┘              └→ Player C

Players are constantly sending events, receiving updates, joining rooms, leaving rooms, and reacting to what other players are doing.

That makes the backend architecture extremely important.

This is one of the areas I want StreetJS to make easier.

The WebSocket connection

Instead of repeatedly polling a REST endpoint, players can maintain a persistent connection with the server.

For example:

const socket = new WebSocket(
  'wss://game.example.com'
);

Once connected, the client can send events such as:

{
  "type": "player.move",
  "x": 120,
  "y": 340
}

The server processes the event and broadcasts the relevant state change to other players.

Rooms

A multiplayer backend usually needs the concept of a room.

For example:

Room: game-4821

Player 1
Player 2
Player 3
Player 4

Players joining the same room become part of the same realtime context.

The server can maintain the relationship:

Room
 ├── Player A
 ├── Player B
 ├── Player C
 └── Player D

When Player A performs an action, the server determines which players should receive the event.

This is much more efficient than broadcasting every event to every connected client.

The server should be authoritative

One of the biggest architectural decisions in multiplayer systems is deciding who controls the game state.

The client should not be trusted to decide:

"I won."
"I have 10,000 coins."
"My player is at position X."
"I dealt 5,000 damage."

The server should validate important actions and maintain authoritative state.

A simplified flow looks like:

Player
   ↓
WebSocket Event
   ↓
Validation
   ↓
Game Logic
   ↓
Authoritative State
   ↓
Broadcast
   ↓
Other Players

This becomes especially important when the application involves competition, rankings, virtual items, or anything that could be manipulated by a client.

Where StreetJS fits

StreetJS is designed as a TypeScript-first backend framework for Node.js.

For a multiplayer application, the backend can combine several capabilities:

WebSockets

Persistent connections and realtime events.

Authentication

Identify players before allowing them into protected game sessions.

Validation

Validate incoming events before they reach game logic.

Services

Keep game rules separate from transport logic.

PostgreSQL

Persist users, games, matches, rankings, inventories and other durable data.

Telemetry

Monitor connections, errors and application behavior.

The important part isn't having individual features.

It's having them work together as one backend architecture.

Realtime state vs persistent state

Not everything belongs in the database.

For example, temporary state such as:

Current player position
Current room membership
Active connection
Current match state

may need to live in memory or a dedicated realtime state layer for fast access.

Persistent information such as:

User account
Match history
Leaderboard
Player statistics
Purchases
Achievements

belongs in durable storage.

A good multiplayer architecture needs to clearly separate these two worlds.

Scaling becomes a different problem

A single server can handle a small multiplayer application.

Eventually you may have:

             Load Balancer
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
   Server A   Server B   Server C
       │          │          │
       └──────────┼──────────┘
                  ↓
          Shared State
                  ↓
             PostgreSQL

Now things become more complicated.

What happens when two players in the same room are connected to different servers?

How do servers synchronize events?

What happens when a server crashes?

How do you reconnect a player?

How do you prevent duplicate events?

These aren't just WebSocket problems.

They're distributed-systems problems.

That's what makes multiplayer interesting

Building a multiplayer backend isn't simply:

"Add WebSockets."

It's about designing a system that can handle state, synchronization, consistency, latency, failures and trust.

That's the part I find interesting.

And it's one of the reasons I'm continuing to develop StreetJS.

The goal isn't to hide these problems from developers.

It's to provide solid infrastructure so developers can spend more time building the actual application.

What would you build?

If you were building a multiplayer application with TypeScript today, what would you make?

A multiplayer game?

Collaborative editor?

Real-time trading simulator?

Online classroom?

Competitive quiz?

Something completely different?

I'm interested in hearing what other developers are building and what problems you've encountered with realtime Node.js applications.

StreetJS: https://github.com/hassanmubiru/StreetJS

Documentation: https://hassanmubiru.github.io/StreetJS/

TypeScript #NodeJS #WebSockets #Multiplayer #BackendDevelopment #OpenSource #JavaScript #SoftwareArchitecture

How I Stopped a Race Condition from Creating Free Money in My Wallet System

Sat, 13 Jun 2026 14:56:16 +0000

The Bug That Doesn't Show Up in Testing.
When I set out to build a production-grade wallet system, I expected the hard parts to be the database schema, the transaction logic, or the authentication layer.

What I didn't expect was that the most dangerous bug in the system would have nothing to do with wrong code - it would be about timing.

This is the story of a race condition that lets users spend money they don't have, why it's invisible until it hits production, and how Redis turned it into a non-issue.

What a Wallet System Actually Does
Before we get to the bug, a quick picture of the system. A wallet holds a balance. Users can:

Credit - add funds
Debit - spend funds
Transfer - move funds to another user
Reverse - undo a transaction
Every operation reads the current balance, validates it, and writes a new transaction record. Simple enough. The problem hides in that gap between reading and writing.

The Race Condition
Here's the scenario. A user has ₦5,000 in their wallet. They're on a slow connection, so they tap "Pay" twice. Two HTTP requests hit the server within milliseconds of each other. Both are trying to debit ₦3,000.

Without any concurrency protection, this is what happens:

Request A → reads balance: ₦5,000
Request B → reads balance: ₦5,000

Request A → ₦5,000 - ₦3,000 = ₦2,000 ✓ writes transaction
Request B → ₦5,000 - ₦3,000 = ₦2,000 ✓ writes transaction
Both requests read ₦5,000. Both pass the balance check. Both write a successful debit. The user just spent ₦6,000 from a ₦5,000 wallet - and the system called both transactions successful.

This isn't a theoretical edge case. Under any real concurrent load, this happens. And the worst part: it never shows up in testing, because your test runner doesn't fire two real HTTP requests at the same millisecond.

Why a Database Transaction Doesn't Save You
The instinct here is to reach for a database transaction. Wrap the whole thing in BEGIN / COMMIT and let Postgres sort it out.

The problem is that the race happens before the database transaction begins. Both requests read the balance from the database (or worse, from a cache), both pass the validation check in application code, and then both open their database transactions. The damage is already done.

You need a lock at the application layer, before the read even happens.

The Fix: Distributed Locking with Redis
The solution is to ensure that no two operations on the same wallet can run at the same time. Before any balance operation begins, it must claim exclusive access. If another operation already holds the claim, it retries until the lock is free, or gives up after a timeout.

This is a distributed lock, and Redis is the right tool for it. Here's the implementation:

// src/utils/lock.utils.ts
import { randomUUID } from "crypto";
import redisClient from "../services/redis.service";

const LOCK_TTL_MS = 10_000;
const LOCK_RETRY_COUNT = 50;
const LOCK_RETRY_DELAY_MS = 100;

const RELEASE_SCRIPT = `
  if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
  else
    return 0
  end
`;

const acquireLock = async (key: string): Promise<string | null> => {
  const token = randomUUID();
  const result = await redisClient.set(key, token, "PX", LOCK_TTL_MS, "NX");
  return result === "OK" ? token : null;
};

export const withLock = async <T>(userId: string, fn: () => Promise<T>): Promise<T> => {
  const key = `wallet:lock:${userId}`;
  let token: string | null = null;

  for (let attempt = 0; attempt <= LOCK_RETRY_COUNT; attempt++) {
    token = await acquireLock(key);
    if (token) break;
    await new Promise((resolve) => setTimeout(resolve, LOCK_RETRY_DELAY_MS));
  }

  if (!token) throw new Error("Could not acquire lock — resource is busy");

  try {
    return await fn();
  } finally {
    await redisClient.eval(RELEASE_SCRIPT, 1, key, token);
  }
};

Let's break down each decision.

SET key token PX 10000 NX
This is a single atomic Redis command that does three things at once:

NX — only set the key if it does not already exist
PX 10000 — expire the key after 10 seconds
The value is a unique token (UUID), not just 1 or "locked"
The atomicity of SET NX is the core guarantee. There is no gap between "check if key exists" and "set the key" — it's one operation. Two requests racing to acquire the same lock cannot both succeed.

Retry logic
Rather than immediately rejecting a request when the lock is held, the implementation retries up to 50 times with a 100ms delay between each attempt - giving it up to 5 seconds to acquire the lock before giving up. This handles brief overlaps gracefully without dropping legitimate requests.

The TTL
The 10-second expiry is a safety net. If the application crashes mid-operation and fails to release the lock, it will expire automatically. Without this, one crash would lock that user's wallet forever.

The Lua script on release
This is where most implementations get it wrong. A naive release looks like this:

await redisClient.del(key); // ❌ dangerous
Here's why that's broken: imagine a slow operation acquires the lock, but takes longer than 10 seconds. The TTL expires. A second operation acquires the lock. Now the first operation finishes and calls del - it just released the second operation's lock, not its own. The guarantee is broken.

The Lua script fixes this by checking the token before deleting:

if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end

Because Lua scripts execute atomically in Redis, the check-and-delete is a single uninterruptible operation. You can only release a lock you actually own.

The withLock wrapper
Rather than exposing raw acquireLock / releaseLock functions and trusting every caller to use them correctly, the implementation wraps the entire pattern in a higher-order function:

// src/services/wallet.service.ts
export const debitWallet = async (userId: string, amount: number): Promise<Transaction> => {
  return await withLock(userId, async () => {
    const wallet = await prisma.wallet.findUnique({ where: { userId } });

    if (!wallet || wallet.balance.lessThan(amount)) {
      throw new Error("Insufficient balance");
    }

    // create transaction, update balance...
    return transaction;
  });
};

The finally block inside withLock ensures the lock is always released, even if the operation throws. A lock that leaks on error is as bad as no lock at all.

Preventing Deadlocks on Transfers
A transfer touches two wallets - sender and receiver. If two transfers run simultaneously in opposite directions (A→B and B→A), they can deadlock: each holds one lock and waits for the other indefinitely.

The fix is to always acquire locks in the same order, regardless of who is sending to whom. We sort the user IDs before acquiring:

export const withMultiLock = async <T>(userIds: string[], fn: () => Promise<T>): Promise<T> => {
  const sortedIds = [...new Set(userIds)].sort();
  const keys = sortedIds.map((id) => `wallet:lock:${id}`);
  const tokens: string[] = [];

  try {
    for (const key of keys) {
      let token: string | null = null;
      for (let attempt = 0; attempt <= LOCK_RETRY_COUNT; attempt++) {
        token = await acquireLock(key);
        if (token) break;
        await new Promise((resolve) => setTimeout(resolve, LOCK_RETRY_DELAY_MS));
      }
      if (!token) throw new Error("Could not acquire lock — resource is busy");
      tokens.push(token);
    }
    return await fn();
  } finally {
    await Promise.all(keys.map((key, i) => releaseLock(key, tokens[i])));
  }
};

// In transfer service:
const result = await withMultiLock([senderId, receiver.id], async () => {
  // both wallets locked — safe to proceed
});

If A→B and B→A both arrive at the same time, both will sort to [A, B] and try to acquire A's lock first. One wins, the other waits. No deadlock.

The Full System
The distributed lock is one layer in a larger stack. The complete wallet engine includes:

Idempotency - Idempotency-Key header on credit and debit prevents duplicate transactions on network retries, backed by a 24-hour Redis TTL
Webhook delivery with retry - BullMQ queue, 4 attempts, exponential backoff (2s base), per-attempt audit trail
Balance caching - 60-second Redis TTL, invalidated on every write
Token blacklisting - SHA-256 hashed JWTs stored in Redis with matching expiry, making logout actually secure
Cursor-based pagination - transaction history that scales
Full test suite - 103 tests, all mocked, no database required to run.
Built with TypeScript, Express, Prisma, PostgreSQL, and Redis (ioredis). Deployed on Render with a GitHub Actions CI/CD pipeline.

Why This Matters
Race conditions in financial systems are not exotic. They're the default outcome when you don't explicitly prevent them. Most wallet tutorials never mention it. Most wallet implementations in production have it.

The fix isn't complicated - but you have to know to look for it.

If you're building anything that touches money, check your balance reads. If there's no lock between the read and the write, the race condition is already there.

Open for Collaboration
This project is open source and actively welcoming contributors. Whether you want to add a feature, improve test coverage, or spot something that could be done better - PRs are open.

Check out the CONTRIBUTING.md for how to get set up and where to send your changes.

GitHub: https://github.com/tochi27/Wallet_System.git

Live API + Swagger: https://wallet-system-api-16cv.onrender.com/api-docs

From CRUD APIs to Production-Style Backend Architecture: My Video Sharing Platform Project

Fri, 29 May 2026 09:30:58 +0000

Completed a Production-Style Video Sharing Platform Backend API
Over the past few weeks, I've been building a backend system inspired by modern video-sharing platforms using Node.js, Express.js, MongoDB, and Cloudinary.

This project went far beyond CRUD operations and helped me understand how real backend systems are designed.

Features Implemented:
✅ JWT Authentication & Refresh Token Rotation
✅ Secure HTTP-Only Cookie Based Sessions
✅ Video Upload & Cloudinary Integration
✅ Comment System
✅ Like System (Videos, Comments, Tweets)
✅ Subscription System
✅ Playlist Management
✅ Watch History Tracking
✅ Creator Dashboard Analytics
✅ Pagination & Aggregation Pipelines

Key Things I Learned:
Authentication using Access & Refresh Tokens
Designing relationships in MongoDB
MongoDB Aggregation Pipelines ($lookup, $group, $project, $addFields)
Ownership-Based Authorization
Cloudinary Media Management
Cascade Cleanup Logic
Building consistent API response structures

Interesting Debugging Challenges:
Duplicate MongoDB index issues
Populate path errors
Refresh token validation flow
Route mismatches
Aggregation pipeline bugs
Watch history synchronization
Video deletion cleanup across collections

Documentation Created:
Complete API Documentation
Authentication Flow Documentation
️ Database Schema Documentation

What's Next?
Building the React frontend and converting this into a complete full-stack application.

GitHub Repository: https://github.com/SairajJadhav08/Video-Sharing-Platform-API

Rebuilding RouteMatrix: From Generic Tool to Logistics SaaS

Mon, 23 Feb 2026 19:37:36 +0000

A few months ago, I shipped the first version of RouteMatrix.
It worked.

But something felt off.

Instead of blindly iterating on features, I paused and asked a harder question:

What problem am I actually solving?

That question changed everything.

I realized RouteMatrix shouldn’t be a generic trip tool.
It needed to solve real operational pain in logistics.

So I’m rebuilding it from the ground up — as a Tracking Truck SaaS focused on:

Fleet visibility
Trip accountability
Operational clarity for logistics teams

This isn’t a UI refresh.
It’s a full rethink:

New architecture
New data model
New mental model

I’m documenting the rebuild openly — decisions, mistakes, and trade-offs — in public.

If you’re building in logistics, fleet management, or SaaS infrastructure, let’s exchange ideas