Mixing Exponential and a framework #

This page is for teams that want Exponential for content and a framework for something else. Four patterns cover most projects. Each keeps one rule: content is written through Exponential's content API, so versions, caches, permissions and search stay consistent.

Contents #

1. Pattern 1: Exponential as the content back end
2. Pattern 2: a framework service called from Exponential
3. Pattern 3: Exponential inside Symfony
4. Pattern 4: libraries inside an extension
5. Users across both sides
6. One domain, two applications
7. Rules

Pattern 1: Exponential as the content back end #

The framework application (Laravel, Django, Rails, a Node.js front end) renders pages and reads content from Exponential's REST API with an integration user's API key or an OAuth2 client; editors work in Exponential's administration (Headless and decoupled front ends). Purge the framework's cache on publish with a content/cache listener or a workflow event that calls the framework.

Pattern 2: a framework service called from Exponential #

A service written in another framework (billing, a recommendation engine, a search index) is called from an Exponential extension: a class wraps the HTTP calls, an expqueue job makes them in the background, and a workflow event or listener enqueues the job after publishing (Queues). The service calls back through the REST API or expservices when it must change content.

Pattern 3: Exponential inside Symfony #

The legacy bridge loads the Exponential 6 kernel inside a Symfony platform installation: Symfony controllers and Twig for the public site, the legacy administration for editors, one database (The Symfony legacy bridge). This is the only pattern with one process for both, and the one with the most moving parts to upgrade.

Pattern 4: libraries inside an extension #

Many framework components are ordinary Composer libraries (HTTP clients, validators, Markdown parsers, mailers). Require them in your extension's composer.json; autoload.php loads Composer's autoloader, so your classes can use them. Keep framework-specific runtime pieces (a container, a router, an ORM connection) out of the kernel's request path.

Users across both sides #

Exponential keeps its own users (content objects) and sessions (Authentication). Options when both sides need the same people:

• The framework side acts as one integration user through the REST API, with its own role.
• The framework side asks users to authorize it through Exponential's OAuth2 server (OAuth and API keys).
• Exponential checks credentials against another system through a login handler of your own (User login handler).

Plan this early; there is no ready-made single sign-on between Exponential and a framework application.

One domain, two applications #

A reverse proxy can route paths to two applications (/shop/ to a framework, everything else to Exponential). Then: list the proxy in TrustedProxies[], keep cookie names distinct ([Session] SessionNamePrefix), and make sure Exponential's URL aliases never claim the other application's paths (Behind a reverse proxy).

Rules #

• Content is written through the content API (eZContentFunctions, REST, expservices), never by SQL into content tables.
• Each side owns its own tables; share data through APIs, not foreign keys.
• Use remote IDs to refer to content from the other side; numeric IDs differ between installations.
• Test the integration on every release of either side.

Related pages #

• When to choose Exponential
• Remote services with expservices
• The platform products
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.