Rebuilding from the ground up with IFREMER

For many years now Camptocamp has been a partner of IFREMER on the Sextant project: a widely-used catalog of marine data with advanced visualization features. The catalog itself is built upon GeoNetwork, but we were also given the opportunity to work on related software, one of them being the Surval sensor data client.

Surval is a collection of web applications used to give access to a large amount of scientific data collected in marine areas. One of these application is used to show quantitative data in the form of graphs for a specific location.

Custom-made API

All the data is accessed through a custom-made API (which shares some similarities with the SOS standard) in three main steps:

Query the full list of available sensors
Query a specific sensor metadata (including name, location, available measurements…)
Query measurement values for a sensor and a specific parameter (which are then displayed on a graph)

This application was developed more than two years ago and in 2018 Camptocamp was given the responsibility of its maintenance.

What happened next is a very common scenario in the world of software engineering. The codebase had been written with a monolithic structure which made maintenance work exponentially costly. Even more so, as the user base of the application expanded, IFREMER gathered a growing set of suggestions and improvements, each of them taking more time than the last for the same reason.

As time went on the team at Camptocamp felt that the project had passed the turning point where maintenance work is simply more expensive than rewriting the whole thing from scratch. Consequently, IFREMER was offered the choice to dedicate some development time to proceed with the rewrite, in hope of drastically reducing the cost of maintenance and evolutions.

Such a decision is never easy to take but Camptocamp and IFREMER agreed and a complete rewrite of the application began.

This work took place during the summer of 2020 and went relatively fast, since some code could be salvaged from the now-legacy application. An added benefit was that some bugs that waited to be fixed did not exist at all in the new application; furthermore, some planned evolutions could be integrated as well for virtually no additional cost.

The application was originally built using the Vue.js framework, but it did not really leverage its main advantage: components that are easy to write and test. The architecture went from a massive, untested, do-everything component to a set of smaller components with clear responsibilities. The excellent Vue testing utilities were used to write unit tests, which proved less of a hassle than with other frameworks.

Lastly, one of the motivations of rewriting the application was that it would allow for a drastic improvement of performance, as the user is sometimes shown several hundreds of graphs on the same page. Implementing a smart, continuous loading system made the experience much smoother than before.

We at Camptocamp consider this to be a success as the rewrite was a moderate investment and is already making maintenance and evolutions significantly easier. Tests were added and the application now has a much more readable structure, making it future-proof and more understandable.

To dive into things a little further, Camptocamp wrote a technical article regarding the integration of OpenLayers with Vue.js: https://dev.to/jahow/integrating-an-openlayers-map-in-vue-js-a-step-by-step-guide-2n1p