DEV Community: Akintunde Morakinyo

One Design Fits All—Until It Doesn’t

Akintunde Morakinyo — Sun, 06 Sep 2026 11:18:18 +0000

Building reusable software without trapping every feature inside the same abstraction

Most abstractions begin with a reasonable observation: we are repeating ourselves.

Imagine an application with separate services for products, customers, categories, and orders. Each service performs similar operations:

GetAll()
Save()
Search()

Implementing these methods separately creates duplication. If the API convention changes, every service may need to be updated.

A shared contract gives these services a consistent structure:

interface ICRUDService<T> {
  GetAll(): Promise<T[]>;
  Save(models: T[]): Promise<T[]>;
  Search(query: SearchParam): Promise<T[]>;
}

PageCRUDService implements the ICRUDService contract by providing the common behaviour:

function PageCRUDService<T>(
  route: string,
): ICRUDService<T> {
  return {
    GetAll: () =>
      apiClient.get<T[]>(`${route}/GetAll`),

    Save: (models) =>
      apiClient.post<T[]>(`${route}/Save`, models),

    Search: (query) =>
      apiClient.post<T[]>(`${route}/Search`, query),
  };
}

Creating a service becomes straightforward:

const ProductService =
  PageCRUDService<Product>("/Product");

This is a useful abstraction. It reduces duplication, establishes a consistent API contract, and gives us one place to change shared behaviour.

The Value of a Shared Contract

Suppose every GetAll endpoint initially returns an array:

GetAll(): Promise<T[]>

Later, the API introduces server-side paging:

interface PagedResult<T> {
  Data: T[];
  TotalRecords: number;
  Skipped: number;
  Limit: number;
}

The shared contract changes to:

GetAll(
  skip?: number,
  limit?: number,
): Promise<PagedResult<T>>;

The implementation changes in one place:

GetAll: (skip = 0, limit = 50) =>
  apiClient.get<PagedResult<T>>(
    `${route}/GetAll/${skip}/${limit}`,
  )

Product, customer, category, and order services do not each need a separate rewrite. They receive the new behaviour through the shared abstraction.

That is where a generic design provides real value: it centralises stable knowledge about how the application communicates with its API.

But reusable designs rarely remain simple forever.

What Happens When One Service Becomes Different?

Suppose the product service later requires operations other services do not need:

GetLowStockProducts()
UploadProductImages()
GetProductsByCategory()

One option is to keep expanding the common interface:

interface ICRUDService<T> {
  GetAll(): Promise<PagedResult<T>>;
  Save(models: T[]): Promise<T[]>;

  GetLowStockProducts?(): Promise<T[]>;
  UploadImages?(): Promise<void>;
  ApproveOrder?(): Promise<void>;
}

This may work technically, but the abstraction has started losing its meaning.

Product operations become visible to customer services. Order operations become visible to category services. Most specialised methods become optional because they do not apply to most consumers.

The shared interface is no longer describing common behaviour. It is becoming a container for every possible behaviour.

Extend Through Composition

A cleaner approach is to compose the standard service with specialised behaviour:

function ProductService() {
  const crud =
    PageCRUDService<Product>("/Product");

  return {
    ...crud,

    GetLowStockProducts: () =>
      apiClient.get<Product[]>(
        "/Product/GetLowStockProducts",
      ),
  };
}

ProductService retains the standard operations defined by ICRUDService<Product> while adding its own specialised method.

Other services remain focused:

const CategoryService =
  PageCRUDService<Category>("/Category");

This leads to an important principle:

A shared abstraction should contain what its consumers genuinely have in common—not everything any consumer might eventually need.

Generic UI Components Have the Same Problem

Consider management pages that share a familiar workflow:

Display records in a table
Search and filter records
Open a Create or Edit dialog
Save changes
Delete records

A generic management component can remove considerable duplication:

<ManagementPage
  Title="Categories"
  Fields={categoryFields}
  Service={CategoryService}
/>

This approach works well for straightforward pages such as categories, roles, permissions, and warehouses.

Then a more complex page arrives.

A product page may require:

Multiple categories
Multiple images
A primary image
Product variants
Warehouse-specific prices
Stock history
Conditional validation
A multi-step creation process

The generic component can be expanded:

<ManagementPage
  EnableImages
  EnableVariants
  ValidateBeforeSave={validateProduct}
  RenderExtraSection={renderStockDetails}
/>

Some configuration is healthy. The danger begins when every requirement introduces another flag, callback, or special condition.

Eventually, the generic component may contain code like this:

if (entityName === "Product") {
  // Product-specific behaviour
}

if (entityName === "Order") {
  // Order-specific behaviour
}

At that point, the abstraction knows too much about its consumers. It becomes a central location where unrelated business rules are mixed together.

Should the Shared Abstraction Change?

That depends on whether the new requirement is common or specific.

If every service now returns paged results, update ICRUDService and PageCRUDService. That is a genuine change to the shared contract.

If only products require image management, that behaviour should not automatically become part of every service or management page.

A useful test is:

If this particular feature did not exist, would the requirement still belong in the shared abstraction?

If the answer is no, the behaviour probably belongs in specialised code or behind an extension point.

Three Ways to Handle a Growing Difference

1. Configure the abstraction

Configuration is appropriate when the difference is small and the standard workflow remains intact:

<ManagementPage
  BeforeSave={validateModel}
  AfterSave={refreshSummary}
/>

2. Compose smaller building blocks

When a page becomes substantially different, it can stop using the complete generic workflow while retaining smaller reusable components:

<PageHeader />
<SearchToolbar />
<DataTable />

<RightSideDialog>
  <ProductForm />
</RightSideDialog>

The page owns its business logic, while the table, search toolbar, and dialog remain reusable.

3. Create a dedicated implementation

If the workflow is fundamentally different, create a dedicated page or service.

This is not a failure of the original abstraction. It means the use cases have diverged.

The mistake would be forcing every feature through the same design merely to preserve architectural uniformity.

The Default, Extension, and Escape Principle

A sustainable abstraction should provide three things.

A useful default

The common case should require very little code.

Controlled extension points

Consumers should be able to customise selected behaviour without rewriting the shared implementation.

An affordable escape route

A complex feature should be able to leave the abstraction without forcing the rest of the application to be rewritten.

This last point is often overlooked.

A design is not truly flexible simply because it accepts many options. It is flexible when a consumer can stop using it without causing architectural damage.

A Little Duplication Can Be Cheaper

Developers are often encouraged to remove duplication immediately. However, duplicated code and duplicated business concepts are not always the same thing.

Two pages may look similar today while representing workflows that will evolve independently tomorrow.

Combining them too early can create a false abstraction—one that initially saves a few lines but later requires conditions, flags, and exceptions to survive.

Sometimes two small and clear implementations are cheaper than one highly configurable generic implementation.

The goal is not to eliminate every repeated line. It is to avoid repeating stable knowledge while keeping changing business behaviour easy to understand.

Final Thought

Reusable architecture is valuable, but uniformity should not become a goal of its own.

A good abstraction standardises what is genuinely common.

A better abstraction provides controlled ways to specialise its behaviour.

A great abstraction also makes it inexpensive to walk away when the use cases are no longer the same.

The goal is not to create one design that fits everything.

The goal is to create useful defaults, honest extension points, and safe escape routes.

A good abstraction saves code today.

A great abstraction leaves room for tomorrow.

Suggested tags: Software Architecture, TypeScript, React, Clean Code, Web Development

Multi-Tenancy Is More Than Adding a TenantId Column

Akintunde Morakinyo — Sun, 30 Aug 2026 18:08:48 +0000

Multi-tenancy often looks straightforward at the beginning.

You have multiple organizations using the same application and database. Add a TenantId to each record, automatically filter queries by the current tenant, and make sure every insert carries the correct tenant.

Problem solved.

At least, that was the assumption I started with while working on multi-tenancy support for SimpleORM.Net, an ORM project I have been building for .NET.

Then I encountered a simple question:

Should the Tenant model itself have a TenantId?

Obviously, it shouldn't.

Then came another question:

What about Country?

If my application contains a list of countries, should every tenant have its own copy of Nigeria, Canada, Germany, the United Kingdom, and every other country?

Again, probably not.

That was when a seemingly simple feature became a much more interesting architectural problem.

The Initial Model

A common approach to multi-tenancy is to make every business record tenant-aware.

Conceptually, our models might look like this:

public class Customer : DBModel
{
    public string Name { get; set; }

    public string TenantId { get; set; }
}

Queries then automatically include the current tenant:

SELECT *
FROM Customer
WHERE TenantId = @CurrentTenant

And when a new customer is saved, the ORM automatically assigns the current tenant.

This is useful because developers don't have to remember tenant filtering every time they write a query.

Without centralized enforcement, it only takes one forgotten condition to create a serious data-isolation problem.

So automatic tenant enforcement makes sense.

But there is a problem with applying that rule universally.

Not Every Model Belongs to a Tenant

Consider these models:

Customer
Order
Invoice
Country
Currency
Tenant

Customer clearly belongs to a tenant.

An Order probably belongs to a tenant.

An Invoice probably belongs to a tenant.

But Country is different.

Nigeria doesn't become a different country because Tenant A and Tenant B are using the system.

The same is true for many reference datasets:

Country
Currency
Language
TimeZone
Industry

These records may legitimately be shared across every tenant.

And then there is the most obvious exception:

Tenant

Making Tenant require a TenantId would mean that a tenant belongs to another tenant.

That is clearly the wrong abstraction.

The mistake is assuming:

Multi-tenant application
        =
Every model is tenant-scoped

Those are two different things.

Tenant Scope Is a Property of the Model

A better mental model is:

                 Application
                      │
              Multi-Tenancy Enabled
                      │
          ┌───────────┴───────────┐
          │                       │
    Tenant-Scoped              Global
       Models                  Models
          │                       │
   Customer                   Country
   Order                      Currency
   Invoice                    Tenant

Multi-tenancy can still be enabled for the application.

But individual models determine whether tenant isolation applies to them.

This changes the responsibility of the ORM.

Instead of asking:

Is multi-tenancy enabled?

It needs to ask:

Is multi-tenancy enabled, and is this particular model tenant-scoped?

That small distinction makes the architecture considerably more flexible.

Where Should This Information Live?

Once I reached this point, another design decision appeared.

How should a model declare that it is global?

There are several possibilities.

Option 1: Marker Interface

For example:

public class Country : DBModel, IGlobalModel
{
}

The ORM could check whether a model implements IGlobalModel.

This works, but an interface normally communicates behaviour or a contract.

In this case, we aren't really introducing behaviour.

We're describing metadata about how the model should be persisted.

Option 2: Configuration

Another approach is configuration:

options.MultiTenancy
    .Exclude<Country>()
    .Exclude<Currency>()
    .Exclude<Tenant>();

This provides excellent flexibility.

It is particularly useful when an application needs to change ORM behaviour without modifying the model.

However, it also means that understanding the behaviour of Country requires finding the application's ORM configuration.

Looking at the model alone doesn't tell you whether it is tenant-scoped.

Option 3: Model Metadata

The third approach is to make tenant scope part of the model's metadata.

Conceptually:

[GlobalModel]
public class Country : DBModel
{
}

or:

[TenantScoped(false)]
public class Country : DBModel
{
}

Now the intent travels with the model.

Wherever Country is used, the ORM can inspect its metadata and know that tenant enforcement should not apply.

For an ORM, I find this particularly attractive because tenant behaviour becomes part of the model definition in the same way that keys, uniqueness, table mappings and other persistence rules are model metadata.

Enforcement Still Belongs in the ORM

Allowing global models should not mean pushing tenant filtering back to application developers.

That would defeat one of the major advantages of ORM-level multi-tenancy.

The application should still be able to write something conceptually as simple as:

await repository.Select<Customer>();

The ORM determines that Customer is tenant-scoped and effectively produces:

SELECT *
FROM Customer
WHERE TenantId = @CurrentTenant

But:

await repository.Select<Country>();

produces:

SELECT *
FROM Country

The same rule needs to apply consistently to:

SELECT
INSERT
UPDATE
DELETE
COUNT
SEARCH

That consistency matters.

If SELECT applies tenant isolation but UPDATE doesn't, the architecture is still unsafe.

Saving Records Requires the Same Decision

The distinction becomes equally important during writes.

For a tenant-scoped model:

var customer = new Customer
{
    Name = "ABC Limited"
};

await repository.Save(customer);

The infrastructure can attach the active tenant automatically.

But for:

var country = new Country
{
    Name = "Nigeria"
};

await repository.Save(country);

there should be no requirement for tenant information.

This means tenant enforcement shouldn't simply be buried inside a generic Save<T>() method as:

MultiTenancyEnabled?
    → Require Tenant

It should behave more like:

MultiTenancyEnabled?
        │
        ▼
Is T tenant-scoped?
    │          │
   Yes         No
    │          │
Apply       Continue
Tenant      Normally

The difference looks small in code.

Architecturally, it is significant.

Shared Data Introduces Another Question

Once global models exist, another interesting scenario becomes possible.

What if some records of a model are global while others are tenant-specific?

Products are a good example.

Imagine a platform provides standard products that every tenant can use, but tenants can also create their own products.

Now the query might need to represent:

TenantId = CurrentTenant
OR
TenantId IS NULL

That is a different problem from a completely global model such as Country.

So there are potentially three concepts:

Tenant-Scoped Model
Every record belongs to one tenant.

Global Model
Records belong to no tenant and are available to everyone.

Shared Model
Global records may coexist with tenant-specific records.

I would resist implementing all three simply because they are possible.

An important part of architecture is knowing when not to generalize.

If the current requirement only needs tenant-scoped and global models, those are the concepts the system should implement.

The design should leave room for shared records later without forcing that complexity into today's API.

The Bigger Lesson

The interesting part of this problem wasn't adding another attribute or another condition to a query.

It was discovering that the original abstraction was slightly wrong.

The first abstraction was:

The application is multi-tenant, therefore its data is tenant-scoped.

The better abstraction became:

The application supports multi-tenancy, while individual models define their tenancy behaviour.

That distinction prevents strange models such as:

Tenant → TenantId
Country → TenantId
Currency → TenantId

while preserving automatic isolation where it actually matters.

This is something I repeatedly encounter when designing reusable infrastructure.

The first version of an abstraction often describes the most common case.

The difficult part is discovering whether that common case is actually a universal rule.

Final Thoughts

Adding TenantId is easy.

Designing where tenant boundaries belong is the harder problem.

A good multi-tenancy implementation needs to answer at least three questions:

Which models belong to tenants?
Which models are global?
Where is tenant isolation enforced?

For SimpleORM.Net, the direction is to keep enforcement inside the ORM while allowing model metadata to determine whether a particular model participates in tenant isolation.

That keeps application code simple without pretending that every piece of data has the same ownership model.

And sometimes that is the difference between adding multi-tenancy as a feature and actually designing for multi-tenancy.

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.