CiviForm is built on the Play Framework in Java, and backed by a PostgreSQL database. We use Guice to do dependency injection and follow the Strategy Pattern. The front end uses J2Html Java library to render HTML (server-side). For client-side interactions we use TypeScript without using any frameworks (see Frontend development for more info). For applicant authentication we support a few different OIDC/SAML identity providers. For infrastructure we use terraform.
Instead of the default templating language for Play (Twirl), CiviForm uses the J2Html Java library to render HTML (server-side).
All view classes should extend
BaseHtmlView, which has some helpful common tag helper methods. Its
makeCsrfTokenInputTagmust be added to all CiviForm forms.
Viewclasses are generally organized by which role(s) they are viewable by (e.g., app/view/admin/ for pages viewable by Admins, app/views/applicant/ for pages viewable by Applicants). Each of these roles also has its own
Layoutclass that extends
BaseHtmlLayoutfor rendering page content in the context of that role.
For the Azure deployment of CiviForm, we have opted to use Azure App Service. We decided that App Service would be the best choice because it has a lot of out-of-the-box functionality for maintaining and scaling apps that makes it easier to use. Azure App Service handles a lot of the work of managing the production environment for developers behind the scenes and lets developers focus on building their application. An example of this is that Azure App Services has a built-in load balancer. The downside is that this approach offers less flexibility. It’s much less customizable than other services, but that doesn’t feel as important for this use case.