Filter tools at the National Government
Since spring 2017, three colleagues of Luminis Amsterdam are working in a Scrum Team for the National Governement. These are Jettro Coenradie, Jeroen Reijn and me (Sander Meinema). There are just as many self-employed people on the team too, namely Tom Jonkman, Roos Labberton and Farley Samson. The Product Owner Gerrit Berkouwer and his substitute Harold Steenwinkel are of the Ministry of General Affairs. In July 2017 our team got the opportunity to build the very first Content Tool: Filter Tools.
Citizens can filter information with this system, so they only get relevant information tailored for their personal situation. There was a strict deadline though because the current system was going to be switched off. Before the end of the year, the solution needed to be in production and in use. This meant for us that we had to develop the entire solution within four months. We accepted this challenge and together we pulled it off!
The Filter Tools system consists of roughly four components. First of all, there is a Content Management System (CMS) in which editors can write information in so-called content blocks. In addition, they can also formulate questions with answer options. Then they can link the answer options to content blocks. This allows citizens to fill out a questionnaire and in that way only receive the relevant content for her or his personal situation. In the first instance, this system is used to provide citizens with the necessary information for life events. For example, what do you have to do when you start living on yourself or if you’re getting married?
The second component is an API. If the editor has finished entering all the content, questions and links of a filtering tool, she or he can publish it. This makes the data from the filter tool publicly available through an open REST API. Through the API the data can be queried with “curl”, Postman or any another HTTP client. The data is returned as JSON.
The third component is a client written in vanilla JavaScript with some basic styling. A website of a ministry or a public agency can easily access the content and questionnaire through this client. It only needs to embed the client in its own website. There are various configuration options for customizing and the styling can be extended or overwritten so that it fits into the look of the rest of the website.
For developers that would like to use the API or the JavaScript client on their website we also created a documentation website. We described the technical use of the API and how to implement the client on your own website. This is the fourth component of the product. The documentation website also contains a demo of the JavaScript client with which the published filter tools can be consulted. Take a look at https://www.contenttoolsrijksoverheid.nl/
Because we had to build the entire system from the ground up in a limited amount of time, we opted for common frameworks with which we could quickly take big steps. ‘Common’ such that the components remain maintainable by ops. ‘Quickly big steps’ because some frameworks take a lot of work off our hands. For example, we have a lot of experience with the Spring Framework, enabling us to quickly put modules from it to good use. Furthermore, for the CMS we used React in combination with redux-form, react-bootstrap, and flexbox, which offered us the opportunity to quickly create something beautiful.
The API is a Spring Boot application which exposes the data via Spring Data REST. The data is stored in a MongoDB. We used Spring REST Docs to document the API. For this, we only needed to write JUnit tests. Thus, we have at the same time unit test coverage and automatically generated technical documentation. We only needed to place these on our website.
To simplify the integration of the filter tool data on for instance a website, we’ve also build a JavaScript client which connects to the API. A consumer of the data from the API can also develop its own client, for example, a chatbot, in another language than JavaScript, or with different functionality. Our challenge was to make it as widely applicable as possible. Our aim was to support all commonly used (versions of) browsers as possible. That’s why we chose to write the client in vanilla JavaScript and don’t use any dependencies on libraries. We actually only built the functionality and delivered a basic styling. We used many ‘classes’, so that the appearance and a bit of the interaction can be adjusted as desired. We used a Model-View-Controller pattern for this. If the model is modified, the view will be rendered again. We have taken this idea from React. We came up with this because we applied React in the CMS.
A lot of data is entered into the CMS. When changes are made, you want those to be immediately visible. For example, if links are made or if the order changes this must be made clear. We did this by storing the data in a Redux store. I have written a blog about this before. The front-end consists of React components that render the data from it. The backend also consists of a Spring Boot application. We also used Spring Security to block various attack vectors. We have thought carefully about blocking code injection, XSS, CSRF, and Man-in-the-Middle.
You can see the result in action on the website of the national government. That’s how we did it. Do you have more questions, you know how to reach us. 😉
