| description |
|---|
Ibexa DXP architecture is structured in multiple layers connected by APIs. |
[[= product_name =]] 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 [[= product_name =]] app is based on the Symfony framework but content management functions rely on the public PHP API. Other applications integrate with [[= product_name =]] via REST API, which also relies on the public PHP API.
The architecture of [[= product_name =]] is layered and uses clearly defined APIs between the layers.
| Layer | Description |
|---|---|
| Back office | Back office contains all the necessary parts to run the [[= product_name =]] 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 [[= product_name =]] installation through the HTTP protocol, following a REST interaction model. |
| GraphQL | GraphQL for [[= product_name =]] 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 [[= product_name =]]. |
| 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. |