Architecture¶
Open Forms is API-first and embraces the separation of concerns lined out by the 5-layers principle of Common Ground.
There, Open Forms as a product consists of two separate codebases:
Open Forms (“the backend”)
Open Forms SDK (“the frontend”)
These codebases complement each other to bring the full functionality of dynamic forms to the end user.
Open Forms¶
Repository: https://github.com/open-formulieren/open-forms/
The backend is essentially what runs on a server. It stores the form-related data in a backing database and performs the majority of the processing. The following features are implemented in the backend:
Administrative interface for content editors, system configuration and submission state introspection.
RESTful API for the SDK and other clients to call to consume or mutate (submission) data
A number of modules implementing specific functionality, often with various plugins to connect with third-party systems centered around a certain functionality
Asynchronous background processing queue, jobs and workers with automatic retry-functionality
A basic but customizable UI wrapper around the SDK to present forms to end-users
Todo
add image that Joeri used for pitch
Logically, Open Forms is made up of a core and various modules which are to a lesser or higher degree coupled with each other.
Core¶
Core functionality is considered functionality that does not or very loosely tie in to particular modules. It is functionality that has meaning on its own without dependencies, but is enriched by modules, such as:
Accounts: administrative user accounts, roles and permissions
Forms: form definitions, forms and form steps
Submissions: filled out forms by end-users, uploaded attachments and processing information
Products: product information offered via forms
General purpose utilities
Modules
Modules focus on specific useful functionalities, often offering choices in which plugin to use to implement said functionality. Usually you can even use a different plugin per form, offering a wide range of flexibility.
Authentication: before a form can be started, often the end-user must authenticate with a particular identity provider
Registrations: once the form is submitted, the data can be sent to a registration backend for further processing
Payments: product-related forms often require payment - this module integrates with payment providers
Appointments: appointments created by end-user can be registered and managed in third party appointment systems
Prefill: once authenticated, form fields can be pre-filled from various third party systems
The core and modules are documented in-depth in the the backend section.
SDK¶
Repository: https://github.com/open-formulieren/open-forms-sdk/
The frontend is responsible for presenting forms to end-users and take them through the process of successfully filling out a form designed by a content editor.
The SDK consumes the API served by the backend and has no knowledge of specific plugins implemented in the backend.
The technical documentation can be found in another section.