During the last sprint, Rebecca and I had the task of exploring technology stacks for the new website.
Knowing that the new website will be data-driven and open source when possible, we decided to try Ruby on Rails as a light-weight server side framework. Here are a few highlights of the process and our learnings.
In terms of the data that we would fetch, we decided to experiment using the Members’ Names Data Platform. We started with a prototype to find the MP of a constituency using postcodes. The same week, some discussions took place with the Enquiry Service of the House of Lords and the Enquiry Service of the House of Commons to find out the type of enquiries the public had about members. As a result, Ganesh Senthi, our product manager, suggested we looked into a search by members’ areas of interest (e.g. housing, education or even geographical places). That way, the search would produce a list of members of both Houses with an interest in that particular area. Here are some screenshots of the working app.
We wanted to experiment with the concept of “website as an API”, so our app handles JSON responses as well, when you append ‘.json’ to the result page.
In terms of data, we also used Rails in a non-traditional way: our app does not have a database. Instead, we cache the data into a Redis server.
Another concept we really wanted to explore was automated testing, both in the forms of unit tests and feature tests. Unit tests make sure that the methods of your model are doing what they are supposed to do. Feature tests, on the other hand, ensure that all the user journeys on the web app have the desired outcome.
Automated testing is very useful when refactoring or changing the codebase: as a developer, you do not have to manually go through your app to make sure everything is still working – the tests will tell you.
Automated testing is not a magical silver bullet that will solve all your issues. For instance, if our application requires data provided from an API, we need to fake the data in the response. This fake data will be used in our tests. However, this could potentially cause issues with our application if the API changes the data returned in the future, although the tests will continue to pass.
But test driven development (TDD) does bring benefits to the codebase making it more readable, more S.O.L.I.D. and it also helps to write small classes and methods focused on doing one thing, this is known as the Single Responsibility Principle (SRP). Also, when running the tests from the terminal, they are in plain English so they could in principle be read by anyone. Here is what we see when we run our tests.
Plans for the future
- We have started working closely with the Continuous Delivery Pipeline Team. Steve Wade suggested that we start running our application inside Docker containers moving forward. He is going to write a post about this in the coming weeks.
- We also started talking with our colleague Samu Lang from Data and Search Team and the website will be created in close collaboration with his team moving forward as we try to experiment with more data formats and working along them as they go through their alpha phase too.
- The APIs that we have used so far are completely open and but we want to experiment with APIs that require authorisation to access.
You can find the link to the repo of our app below and if you have any feedback, thoughts or questions, please feel free to contact us at firstname.lastname@example.org.