There is no shortage of frameworks for building data-driven applications.
There are ORMs.
There are GraphQL servers.
There are repositories.
There are query builders.
There are API frameworks.
There are database drivers.
All of them solve real problems.
So why would another system be necessary?
The motivation behind Foundgine starts with a different problem:
modern applications are very good at describing requests, but the meaning of those requests is often lost before execution.
Start with a simple request
Imagine an application with these relationships:
Customer
└── Accounts
└── Transactions
A client asks:
query {
customers {
name
accounts {
number
transactions {
amount
}
}
}
}
At the API level, this is simple.
The client is saying:
Give me customers, their accounts, and the transactions belonging to those accounts.
The difficult part is everything that happens next.
The application has to determine:
which entities are involved
how they are related
which fields are valid
which relationships can be traversed
what authorization applies
how filtering and ordering should work
how the data should be fetched
how many database operations are required
how the result should be reconstructed
This is where application architecture tends to become complicated.
The traditional path
A typical implementation might look like:
GraphQL request
↓
Resolver
↓
Service
↓
Repository
↓
ORM
↓
SQL
↓
Database
Each layer makes sense.
But there is an important architectural consequence.
The original request gets broken apart.
The resolver knows part of it.
The service knows another part.
The repository knows how to query the data.
The ORM knows how to translate objects into SQL.
The database finally executes the result.
There is often no single representation of:
"This is what the application is asking for."
That becomes increasingly important when requests become more complex.
Relationships expose the problem
Consider:
customers {
accounts {
transactions {
amount
}
}
}
A naive implementation can easily turn into:
Query customers
↓
For each customer:
Query accounts
↓
For each account:
Query transactions
The infamous N+1 problem appears.
The solution is well known.
Use batching.
Use eager loading.
Use joins.
Use DataLoader.
Use projections.
Use custom SQL.
Use ORM-specific optimizations.
These are all valid solutions.
But they are mostly execution-level solutions.
The deeper question is:
Where does the system represent the original intent?
That is the question Foundgine explores.
Foundgine starts one step earlier
Instead of immediately converting a request into framework-specific execution code, Foundgine introduces an intermediate representation.
Conceptually:
Request
↓
Intent
↓
Metadata
↓
Semantics
↓
Plan
↓
Execution
The important part is the plan.
The plan represents the requested operation before it becomes SQL.
For the previous example, the system can reason about something like:
Customer
├── Name
└── Accounts
├── Number
└── Transactions
└── Amount
That structure contains meaning.
It says what data is required and how the data is related.
It does not yet say:
"Use this particular SQL query."
That decision belongs later.
Intent versus execution
This distinction is the central idea.
Consider a relational database.
The final execution might be something like:
SELECT
c.name,
a.number,
t.amount
FROM customer c
LEFT JOIN account a
ON a.customer_id = c.id
LEFT JOIN transaction t
ON t.account_id = a.id;
That SQL is useful.
But it is not the original intent.
It is one possible implementation of the intent.
Foundgine attempts to preserve the distinction:
INTENT
│
▼
Execution Plan
│
┌─────────┴─────────┐
▼ ▼
SQL Other
Provider Provider
This is what makes the architecture different.
The platform does not need to assume that the frontend is GraphQL or that the backend is SQL.
So what exactly is Foundgine?
Foundgine is a platform for turning application intent into executable plans.
Its core concerns are:
Metadata
What entities, fields, and relationships exist?
Intent
What is the application asking for?
Semantics
Is that request valid and allowed?
Planning
What should execution look like?
Execution
How does a provider execute the resulting plan?
This produces a separation like:
What?
↓
Intent
What does it mean?
↓
Semantics
How should it run?
↓
Plan
Run it
↓
Execution
That separation is the foundation.
What Foundgine is not
It is equally important to define what Foundgine is not.
It is not an ORM
Foundgine does not attempt to replace Entity Framework or similar tools.
An ORM maps application objects to database structures.
Foundgine is concerned with a different boundary:
Application intent
↓
Execution plan
An ORM can potentially be part of the execution infrastructure.
It is not a GraphQL server
GraphQL can be an input mechanism.
But Foundgine does not require GraphQL to define its core model.
The architecture is intended to allow other forms of intent to enter the system.
For example:
GraphQL
REST
Application API
JSON Intent
Generated code
│
▼
Foundgine
It is not a SQL replacement
SQL remains extremely powerful.
Foundgine does not try to hide SQL behind another query language.
Instead, SQL can be the final execution representation produced from a higher-level plan.
It is not a repository generator
Repositories typically answer questions such as:
GetCustomer()
GetCustomers()
GetCustomerAccounts()
Foundgine is interested in a different model:
What does this request require?
The distinction becomes increasingly useful when requests are dynamic.
Why introduce another abstraction?
An abstraction is only useful when it solves a problem that otherwise becomes expensive.
The argument for Foundgine is that planning is already happening in many applications.
It is simply happening implicitly.
Developers manually decide:
which joins to use
which queries to issue
which fields to project
how relationships are loaded
how authorization affects the query
how mutations depend on one another
how results are reconstructed
Foundgine attempts to make that planning explicit and reusable.
Instead of every application repeatedly implementing:
Request
↓
Interpretation
↓
Validation
↓
Query construction
↓
Optimization
↓
Execution
the platform provides a place for those responsibilities to live.
The evolution behind the idea
The idea did not begin with a desire to build another framework.
It emerged from a more practical observation:
As applications become more data-driven, the boundary between API, business semantics, and data access becomes increasingly complicated.
GraphQL makes this particularly visible.
A GraphQL query can describe a surprisingly large amount of intent:
customers {
name
accounts {
balance
transactions {
amount
}
}
}
Trying to map that directly to resolvers and application code can result in a growing amount of framework-specific logic.
The natural next step is to ask:
What if the query became a plan instead?
From that question comes the broader architecture:
Frontend
↓
Intent
↓
Semantic model
↓
Planner
↓
Execution plan
↓
Provider
GraphQL becomes one way of expressing intent rather than the foundation of the entire system.
The interesting part is the boundary
The value of Foundgine is therefore not primarily about writing less SQL.
It is about creating a clean boundary between:
what the application wants
and
how infrastructure makes it happen.
That boundary can potentially provide capabilities such as:
query planning
relationship traversal
authorization-aware planning
mutation dependency planning
provider-specific optimization
predictable execution
testable intermediate plans
alternative execution providers
The important word is potentially.
Foundgine is deliberately a foundation rather than a claim that every problem has already been solved.
A different way to think about data access
The traditional mental model is:
API → Code → Database
Foundgine proposes:
API
↓
Intent
↓
Meaning
↓
Plan
↓
Execution
↓
Database
The database still matters.
The API still matters.
The application code still matters.
The difference is that the system now has an explicit representation of the work between them.
That is the core motivation behind Foundgine.
Not another ORM.
Not another GraphQL framework.
Not another database abstraction.
A foundation for making application intent explicit, turning that intent into an execution plan, and allowing infrastructure to determine how the plan should run.
That is the problem Foundgine is designed to explore.
Top comments (0)