After (quite) a summer break, here comes the 4th article of the 5-episode blog post series on Polis, written by Guido Berhörster, member of staff at my company Fre(i)e Software GmbH.
Have fun with the read on Guido's work on Polis,
Mike
Table of Contents of the Blog Post Series
- Introduction
- Initial evaluation and adaptation
- Issues extending Polis and adjusting our goals
- Creating (a) new frontend(s) for Polis (this article)
- Current status and roadmap
4. Creating (a) new frontend(s) for Polis
Why a new frontend was needed...
Our initial experiences of working with Polis, the effort required to implement more invasive changes and the desire of iterating changes more rapidly ultimately lead to the decision to create a new foundation for frontend development that would be independent of but compatible with the upstream project.
Our primary objective was thus not to develop another frontend but rather to make frontend development more flexible and to facilitate experimentation and rapid prototyping of different frontends by providing abstraction layers and building blocks.
This also implied developing a corresponding backend since the Polis backend is tightly coupled to the frontend and is neither intended to be used by third-party projects nor supporting cross-domain requests due to the expectation of being embedded as an iframe on third-party websites.
The long-term plan for achieving our objectives is to provide three abstraction layers for building frontends:
- a stable cross-domain HTTP API
- a low-level JavaScript library for interacting with the HTTP API
- a high-level library of WebComponents as a framework-neutral way of rapidly building frontends
The Particiapp Project
Under the umbrella of the Particiapp project we have so far developed two new components:
- the Particiapi server which provides the HTTP API
- the example frontend project which currently contains both the client library and an experimental example frontend built with it
Both the participation frontend and backend are fully compatible and require an existing Polis installation and can be run alongside the upstream frontend. More specifically, the administration frontend and common backend are required to administrate conversations and send out notifications and the statistics processing server is required for processing the voting results.
Particiapi server
For the backend the Python language and the Flask framework were chosen as a technological basis mainly due to developer mindshare, a large community and ecosystem and the smaller dependency chain and maintenance overhead compared to Node.js/npm. Instead of integrating specific identity providers we adopted the OpenID Connect standard as an abstraction layer for authentication which allows delegating authentication either to a self-hosted identity provider or a large number of existing external identity providers.
Particiapp Example Frontend
The experimental example frontend serves both as a test bed for the client library and as a tool for better understanding the needs of frontend designers. It also features a completely redesigned user interface and results visualization in line with our goals. Branded variants are currently used for evaluation and testing by the stakeholders.
In order to simplify evaluation, development, testing and deployment a Docker Compose configuration is made available which contains all necessary components for running Polis with our experimental example frontend. In addition, a development environment is provided which includes a preconfigured OpenID Connect identity provider (KeyCloak), SMTP-Server with web interface (MailDev), and a database frontend (PgAdmin). The new frontend can also be tested using our public demo server.