Building a Fully Generic GET Engine — A Scalable Approach to Dynamic Querying

Malki L. — Wed, 10 Dec 2025 11:02:17 +0000

Quick Links:

Introduction
The Problem: Too Many Entities, Too Much Repeated Logic
The Core Idea: Describe the Resource — Don’t Hardcode It
How the Generic GET Flow Works
Before vs After
Why This Architecture Is Powerful?
Conclusion

Introduction

In fast-growing systems, the simplest operation — fetching data — slowly becomes one of the hardest to maintain.

Every new entity requires its own GET endpoint, its own filters, its own search logic, and its own controller–service–repository chain. After a few months, the codebase becomes filled with duplicate logic and inconsistent behaviors across resources.

During our Infrastructure work, we faced exactly this challenge.
Our solution was to design a Generic GET Engine — a single dynamic pipeline capable of handling GET operations for any resource, without writing any new controllers or queries.

🛑 The Problem: Too Many Entities, Too Much Repeated Logic

Originally, each entity implemented GET differently:

Events had one filtering model
Processes had another
Some supported search, others didn’t
Some used pagination, others didn't
Every new resource required writing controllers, queries, validations, and tests

This resulted in:

❌ Duplication
❌ Inconsistency
❌ Slow development
❌ Harder debugging

The system needed one unified solution.

✨ The Core Idea: Describe the Resource, Don’t Hardcode It

Instead of writing resource-specific logic, we introduced a central Resource Registry.
Each resource is defined once, using metadata that tells the system how it should behave.

Example — Registering a Resource

registry.register({
  name: 'event',
  entity: Event,
  alias: 'e',
  searchable: ['name'],
});

This simple definition allows the GET engine to:

Identify the resource dynamically
Know which entity to query
Know which fields support full-text search
Build the correct SQL automatically

From this point on, the system can generate and execute queries for event without any manual code.

⚙️ How the Generic GET Flow Works

1. Request

Client sends:

GET /api/event?search=meeting&sort=createdAt:desc&limit=20&page=1

The engine parses parameters like:

search
filter
sort
pagination

2. Resolve Resource

The system identifies the resource from the URL and loads its config:

const config = registry.get(resourceName);
return baseRepository.findAll(config, queryOptions);

This dynamic lookup is the heart of the engine — nothing is hardcoded anymore.

3. Build Query

The Query Builder constructs SQL based on the registry + incoming options.

Example snippet:
if (search) {
  qb.where(`similarity(${alias}.name, :search) > 0.2`, { search });
}

The engine can generate:

Full-text search (e.g., Trigram similarity)
Filters (ranges, equals, lists)
Sorting
Pagination
Field selection

All automatically.

4. Execute

The Base Repository executes the query and returns a uniform structured response.

return qb.getMany();

This completes the flow — without writing any entity-specific logic.

📊 Before vs After

Feature	Before (Manual Logic)	After (Generic GET Engine)
GET Logic	Each entity had its own GET logic	One generic GET engine for all resources
Consistency	Queries and search were inconsistent	Unified search, filtering, sorting, pagination
New Resource	Required manual coding of controllers and queries	Requires only: `registry.register({ ... });`
Duplication	High	Zero duplication

Why This Architecture Is Powerful?

✔️ Saves Time: Dozens of repetitive controller/service/query files are eliminated.
✔️ Scales Easily: Adding new entities is trivial.
✔️ Consistency Across the System: Every endpoint behaves the same: same search, sorting, filters, pagination logic.
✔️ Extendable: Add a feature once → all resources get it.
✔️ Cleaner Codebase: Infrastructure is centralized, not scattered.

💡 Conclusion

The Generic GET Engine transformed our system from a patchwork of duplicated logic into a clean, extensible, and scalable architecture.

By shifting from "write GET logic per entity" to "describe the entity once", we created a foundation that supports rapid development and long-term maintainability.

This approach is ideal for any team working with large domain models or dynamic resource sets. Instead of writing endless boilerplate code — you build one smart engine.

Forem: Malki L.