Designing and generating

Paprika does two jobs for two kinds of people. Designing templates is done by designers, in the editor, a few at a time, by hand. Generating documents from them is done by software, through the API, sometimes thousands at a time, unattended. The two have different users, different loads and different risks, so they are separate parts of Paprika over one engine.

The generation service

The generation service holds the template registry: every published template and its versions. A version never changes once published, so a document made from version 3 today is made the same way next year. It checks the values sent against the version’s fields, renders documents synchronously or as queued jobs and batches, and tells your systems by webhook when work is done.

Its work is split between the API, which takes requests and answers them, and workers, which render queued work. Workers share themselves fairly between the organisations using the service, so one organisation’s batch of a hundred thousand doesn’t hold up another’s single document.

The editor

The editor is where templates are designed. Everything it shows is rendered by the same engine the generation service uses (one engine), and its preview of an unpublished template is what a document from it would be.

From one to the other

Publishing is the bridge: the editor sends the template to the registry as its next version. From then on, integrators render that version by its template id, with latest or a version number. A designer can go on changing the template in the editor; nothing changes for the API until the next publish.

This split is also why a template and its values are separate: the template is the designer’s, the values the integrator’s. The template’s fields are the contract between them (values).

Organisations, kept apart

Each organisation is a tenant with its own templates, fonts, brand kits, outputs and keys. One Paprika serves many, as a managed service, or one, installed by an organisation for itself (running Paprika). Tenants are kept apart by their keys and, a second time, by the database itself (security).