Home → Documentation → Reference → FAQ
Extended architecture FAQ. For first-hour setup questions, see Getting Started → FAQ.
This document answers the most common questions about Foundgine’s architecture, design decisions, and development philosophy.
Foundgine performs most framework analysis during compilation rather than runtime.
This includes:
This significantly reduces runtime work while improving startup performance and Native AOT compatibility.
Reflection introduces:
Generated code provides the same information without requiring runtime discovery.
Foundation defines contracts.
Runtime implements behavior.
Keeping them separate provides:
Foundation should never know Runtime exists.
Metadata rarely changes while an application is running.
Generating metadata once during compilation avoids repeated runtime analysis and enables immutable, singleton metadata objects.
Immutable metadata is:
Runtime never needs to modify metadata.
Planning determines what should happen.
Execution determines when it happens.
Separating these responsibilities simplifies Runtime and improves determinism.
Planning understands application semantics.
SQL understands database syntax.
Keeping them independent allows:
Generated materializers:
Materialization becomes simple generated code.
GraphQL is a transport.
Its responsibilities are:
SQL belongs to the SQL project.
Keeping transport and execution separate makes Runtime reusable.
The same execution engine should support:
Only the request translation changes.
Execution remains identical.
Dependency Injection allows Runtime to depend upon interfaces rather than generated implementations.
For example:
Runtime
↓
IMetadataProvider
↓
GeneratedMetadataProvider
This improves testing and extensibility.
Static classes tightly couple Runtime to generated code.
Generated implementations registered through interfaces allow:
Roslyn is a compile-time technology.
Runtime should execute plans—not analyze source code.
Keeping Roslyn isolated within the Generator reduces complexity and improves portability.
Native AOT aligns naturally with Foundgine’s architecture.
Compile-time generation eliminates the need for:
The resulting framework performs well in both JIT and AOT environments.
Yes.
Planning is database-independent.
Only SQL serialization changes.
Future providers may include:
Yes.
Runtime is transport agnostic.
Future transports may include:
Stable generated identifiers provide:
Identifiers are allocated during compilation.
Foundation contains:
It intentionally excludes:
Runtime owns:
Runtime should never:
The Generator performs compile-time work:
Generated code becomes Runtime’s input.
Foundgine differs from many data frameworks by emphasizing:
The framework is designed so Runtime executes precomputed artifacts rather than discovering application structure during execution.
Foundgine’s design choices consistently favor compile-time computation, immutable models, clear architectural boundaries, and reusable execution components.
Understanding these principles makes the rest of the framework significantly easier to understand and extend.
| ← Previous: ADRs | Next: Glossary → |