DEV Community: Akintunde Morakinyo

How I Simplified My Backend Architecture for Business Applications

Akintunde Morakinyo — Sat, 08 Aug 2026 21:36:20 +0000

After more than a decade of building business applications, I noticed something interesting.

Very few projects became difficult because the business rules were complicated.

Most became difficult because of everything surrounding the business rules.

Every new module seemed to require another controller, another service, another repository, another set of CRUD methods, another search endpoint, another authorization check and another audit implementation.

Over time, the application became full of infrastructure code that looked remarkably similar across different modules.

That made me ask a simple question:

Can infrastructure be designed once so developers spend most of their time writing business logic instead of rewriting the same plumbing?

That question completely changed how I approach backend architecture.

Start with the Business

When I build business applications, I try to separate business behaviour from infrastructure.

Infrastructure includes things like:

CRUD
Searching
Pagination
Auditing
Multi-tenancy
Authorization
Notifications

These are necessary, but they are rarely unique to a specific module.

Whether you're building Products, Customers, Orders or Suppliers, those capabilities are usually identical.

Business logic should be where the application becomes different.

Keep the Architecture Small

Instead of adding more layers, I started removing unnecessary ones.

The architecture now looks something like this:

HTTP Request
│
▼
Controller
│
▼
Business Service
│
▼
BaseService
│
▼
IDataService
│
▼
Database

Each layer has one clear responsibility.

Controllers receive requests.

Business services implement business rules.

The base service provides reusable application behaviour.

The data service handles persistence.

That simple separation has proven easier to maintain than having every service implement the same CRUD operations repeatedly.

Group by Business Capability

Another change I made was grouping services around business capabilities rather than around every model.

For example, instead of creating services simply because a model exists, I group related functionality into services such as:

Product Service
Order Service
Inventory Service
Customer Service

Supporting models don't automatically require their own service unless they introduce their own business behaviour.

That keeps the solution easier to navigate and reduces unnecessary abstractions.

Searching Shouldn't Require New Endpoints

Search requirements tend to grow throughout the lifetime of an application.

It often starts with a few simple endpoints and gradually expands into dozens of variations.

Rather than creating a new endpoint every time another filter is needed, I prefer allowing the client to describe the search.

The backend remains responsible for validating those criteria and translating them into efficient database queries.

The API surface stays stable while search capabilities continue to grow.

Make Infrastructure Automatic

Another principle I try to follow is making infrastructure happen automatically whenever possible.

For example:

Tenant filtering
Audit information
Pagination
Index creation
Timestamps

Developers shouldn't need to remember these concerns throughout the application.

The framework should handle them consistently.

That not only reduces repetitive code but also helps prevent subtle bugs caused by inconsistent implementations.

Why Not GraphQL or gRPC?

GraphQL and gRPC are both excellent technologies.

The choice depends on the problem you're solving.

GraphQL shines when clients need fine-grained control over the shape of the data they retrieve.

gRPC excels at high-performance communication between services.

Many business applications, however, primarily need predictable APIs with flexible searching, strong authorization, auditing and maintainable business logic.

In those cases, a well-designed REST architecture with reusable infrastructure often provides everything required while remaining straightforward to develop, test and maintain.

The objective isn't to avoid newer technologies.

It's to choose the simplest architecture that solves the problem well.

Final Thoughts

One lesson I've learned is that complexity rarely arrives all at once.

It accumulates.

A duplicated CRUD method here.

Another search endpoint there.

A new authorization implementation in another module.

Individually, they don't seem significant.

Collectively, they become expensive to maintain.

Good architecture isn't about adding more layers or adopting every new technology.

It's about removing unnecessary repetition so developers can focus on solving business problems.

That's the principle I now try to apply whenever I design a new business application.

What architectural decisions have helped you reduce repetitive code in your own backend applications? I'd be interested to hear the patterns that have worked well for you.

Building an Efficient Authentication Pipeline with ASP.NET Core, Playwright and Token Caching

Akintunde Morakinyo — Sun, 02 Aug 2026 19:16:48 +0000

Authentication is one of the most important parts of any application that integrates with external services. While many modern platforms expose OAuth APIs or SDKs for third-party developers, there are situations where an application needs to interact with an authentication flow that is primarily designed for browser users.

Recently, while building a mobile application that integrates with an external football management platform, I needed to design an authentication architecture that was both reliable and efficient. Rather than focusing solely on obtaining an access token, the bigger engineering challenge was ensuring that users were not repeatedly authenticated on every request.

This article explains the architecture I adopted and the design decisions behind it.

The Problem

The mobile application communicates with an ASP.NET Core backend, which in turn communicates with an external service requiring authenticated requests.

A naïve implementation would attempt to authenticate every time a user opens the application. Besides introducing unnecessary latency, this approach would repeatedly perform browser automation and create avoidable load on both the application and the external service.

The objective was therefore to design a solution that:

authenticates users only when necessary;
securely stores authentication information;
reuses valid access tokens;
refreshes authentication only after token expiry; and
keeps the mobile client completely unaware of the authentication complexity.

High-Level Architecture

┌───────────────────────┐
│   React Native App    │
└──────────┬────────────┘
           │
           ▼
┌───────────────────────┐
│   ASP.NET Core API    │
└──────────┬────────────┘
           │
           ▼
┌───────────────────────┐
│      MongoDB Cache    │
└──────┬─────────┬──────┘
       │         │
 Token Exists?   │
       │         │
       ▼         ▼
 Return Token  Launch Playwright
                    │
                    ▼
          External Authentication
                    │
                    ▼
           Receive Access Token
                    │
                    ▼
          Store Token + Expiry
                    │
                    ▼
         Return Authenticated User

Authentication Flow

The authentication pipeline follows a simple decision process.

Step 1 – Check Existing User

When a login request reaches the backend, the application first checks whether the user already exists in MongoDB.

Instead of immediately attempting another login, the stored authentication information is inspected.

Step 2 – Validate Token Expiry

Each stored authentication record contains an access token together with its expiration timestamp.

If the token is still valid, the backend simply reuses it.

This avoids unnecessary authentication while significantly reducing response time for returning users.

Step 3 – Authenticate Only When Necessary

If the user is logging in for the first time, or the existing token has expired, the backend performs a fresh authentication using Playwright.

Once authentication succeeds, the new access token and its expiry time are stored for future requests.

Centralising Authentication

One design decision that proved particularly useful was centralising authentication inside the backend.

The React Native application simply submits user credentials once. After successful authentication, the backend becomes responsible for managing the lifecycle of the access token.

This provides several advantages:

a simpler mobile application;
reduced duplication of authentication logic;
easier maintenance; and
the flexibility to change authentication behaviour without updating the client application.

Automatic Token Injection

Once a valid token is available, it is attached to the shared HttpClient before any authenticated requests are made.

This means the remainder of the application can focus entirely on business logic without worrying about manually attaching authentication headers for every request.

Why Cache Authentication?

Caching authentication information offers several practical benefits.

Better Performance

Returning users avoid repeating the authentication process, resulting in noticeably faster login times.

Lower Infrastructure Cost

Browser automation is significantly more resource-intensive than validating a stored token. Reusing valid tokens reduces server workload.

Improved User Experience

Users experience a seamless login flow while the backend transparently manages authentication behind the scenes.

Cleaner Architecture

Separating authentication management from business functionality keeps services easier to test and maintain.

Lessons Learned

Designing authentication is about much more than obtaining an access token.

A robust authentication system should answer questions such as:

When should a user authenticate?
How long should authentication remain valid?
When should cached credentials be reused?
How can authentication complexity be hidden from client applications?
How can token management remain maintainable as the application grows?

By treating authentication as an architectural concern rather than simply a login feature, it becomes possible to build systems that are faster, cleaner and significantly easier to evolve.

Final Thoughts

Every integration presents its own authentication challenges, but the underlying engineering principles remain consistent.

By introducing token caching, validating token expiry before re-authentication, and centralising authentication management within the backend, I was able to create an architecture that is efficient, maintainable and scalable.

The implementation discussed here was developed while building a mobile integration for a football management platform, but the same design principles can be applied to many applications that interact with external authenticated services.

In future articles, I'll explore additional aspects of the project, including designing reusable API clients, integrating a React Native front end with the backend, and structuring applications for long-term maintainability.