Lightna follows a frontend architecture that differs from the traditional model where SSR apps handle everything at runtime — including data fetching, heavy logic and constant overhead from universal frameworks. As projects grow, this approach tends to slow down and often leads to heavy caching — including full page caching with complex invalidation logic or outdated data on the site. This increases development complexity and limits flexibility and performance in the long term.
Instead, Lightna decouples rendering and moves all data processing and overhead to background tasks — indexing and compilation (see Coin Concept). The frontend uses preprocessed data that updates continuously in near real-time, usually within 1–2 seconds. This enables sub-5ms rendering, avoids performance degradation, and simplifies frontend development.
This makes the frontend effectively headless — it relies only on indexed data and doesn't depend on the platform codebase.
To minimize bottlenecks during page rendering, Lightna uses a custom session-handling approach:
Lightna meets the following requirements:
The Lightna indexer processes entities in batches, significantly accelerating performance. Background processing is based on a changelog and direct access to the project database, making Lightna fully independent of the application codebase.
The indexer is designed for fast data assembly for representation based on existing database data, ensuring high performance. It is not intended for heavy or slow operations, especially API requests or complex calculations. Such operations should be handled as a separate process that prepares and stores data in the database for the indexer to use.
Object creation is delegated to an internal object manager. Dependencies are compiled, and their instantiation is deferred until first use. This optimizes performance and reduces memory usage.
Lightna avoids using the default Composer autoloader, including package-specific autoload files, as they can become a performance bottleneck. Instead, it generates a more optimized class map. For PSR-4 packages that do not include custom autoload files, Lightna automatically indexes their classes.
Lightna enforces a strict separation between page rendering and actions. Pages are always rendered via GET, while actions are triggered by POST and return JSON. Mixing these leads to poor code quality and a bad user experience.
In favor of extensibility, Lightna core modules avoid using private, self, and
readonly (as it behaves like private) in PHP, as well as private methods in
JavaScript. While this approach is recommended for third-party modules, it remains optional for custom
project modules.
Since Lightna is primarily focused on frontend rendering, its rendering process is simplified thanks to
the Coin Concept. As a result, it has significantly fewer abstraction layers compared to general-purpose
frameworks with high complexity.
This doesn’t mean additional layers won’t be introduced in the future, but our goal is to keep the
architecture simple and efficient.
Lightna is developed with a strong focus on principles that enhance modularity and extendability. The key principles are composition, SRP, and OCP. While not all code fully adheres yet, Lightna is evolving toward a more composable and principle-driven architecture.
At Lightna, we believe that balancing solutions and code quality is essential, especially in the early stages of a project or feature. At this phase, focusing on a solid architectural approach is more valuable than perfect code. A thoughtful structure enables flexibility and scalability, while code quality can be refined over time without major refactoring.
Our versioning strategy follows Semantic Versioning principles with a more flexible approach to minor version bumps.