Filter tools at the National Government
Since spring 2017, three colleagues from Yuma have worked on a Scrum Team for the National Government. These are Jettro Coenradie, Jeroen Reijn and me (Sander Meinema). The team also includes three self-employed people: 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 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, there is a Content Management System (CMS) where 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 provides 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 filter tool data 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 ministry or public agency website 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 includes a demo of the JavaScript client, which can be used to consult the published filter tools. 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, which lets us quickly put modules 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 that exposes the data via Spring Data REST. The data is stored in 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 integrating the filter tool data into, for instance, a website, we also built a JavaScript client that 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 as many commonly used browser versions as possible. That's why we chose to write the client in vanilla JavaScript and avoid any library dependencies. We actually only built the functionality and delivered 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. 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. The backend is 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 results in action on the national government website. That's how we did it. Do you have more questions, you know how to reach us.
We are your dedicated partner. Reach out to us.
