This documentation is for a version that has reached its End Of Life. Such versions are no longer supported and don't receive security updates. Consider updating to a newer version.
Architecture¶
Ibexa DXP architecture is based on the philosophy to use APIs that is maintained in the long term. This makes upgrades easier and provides lossless couplings between all parts of the architecture, at the same time improving the migration capabilities of the system.
The structure of an Ibexa DXP app is based on the Symfony framework but content management functions rely on the public PHP API. Other applications integrate with Ibexa DXP via REST API, which also relies on the public PHP API.
The architecture of Ibexa DXP is layered and uses clearly defined APIs between the layers.
| Layer | Description |
|---|---|
| Back office | Back office contains all the necessary parts to run the Ibexa DXP back office interface. |
| HTTP Cache) | Symfony HTTP cache is used to manage content "view" cache with an expiration model. In addition it is extended by using FOSHttpCache to add several advanced features. |
| Controllers | Controllers created by you to read information from a Request object, create and return a Response objects. |
| Twig templates | Set of custom and built-in Twig templates. User interfaces are developed with the Twig template engine and query the public PHP API directly. |
| REST API v2 | The REST API v2 enables you to interact with an Ibexa DXP installation through the HTTP protocol, following a REST interaction model. |
| GraphQL | GraphQL for Ibexa DXP exposes the domain model using the repository, based on content type groups, content types and field definitions. |
| Public PHP API | Public PHP API exposes the repository which enables you to create, read, update, manage and delete all objects available in Ibexa DXP. |
| Business Logic | The business logic is defined in the kernel. This business logic is exposed to applications via an API. It is used to organize development of the user interface layer. |
| SPI | Service Provider Interface which defines contracts for implementing various parts of the system, including persistence layer (SPI\Persistence), custom field types, custom limitations, and more. |
| Persistence cache | The implementation of SPI\Persistence that decorates the main backend implementation. |
| Search | Search API that allows both full-text search and querying the content. |
| SQL Storage Engine | Legacy search engine is SQL-based and uses Doctrine's database connection. |
| Solr Storage Engine | Transparent drop-in replacement for the SQL-based Legacy search engine. |
| IO | The IO API is organized around two types of handlers, both used by the IOService. |
| IO Handler | The IO Handler manipulates metadata, making up for the potential inconsistency of network-based filesystems. |
| Recommendation | Recommendation API. |
| Personalization server | Personalization server allows displaying recommendations on the website. |