Frais et Local: How we developed the French Ministry of Agriculture’s app

To explain how, we’re going to talk through a project we worked on with the French Ministry of Agriculture to develop an app called Frais et Local (Fresh and Local), to locate nearby farmers selling their produce.

The goal was to provide a single point of entry for consumers looking for local farm produce as well as providing increased visibility for the farmers involved.

At first glance, developing the visible part—the front end—appears to be straightforward. With a few hours of JavaScript and the use of a library like Mapbox-gl, you can create a map that displays points, refocuses on the desired area, and supports geolocation.

From this we then created a homepage, added legal notices, applied a bit of “paint” (CSS), and finally imported and enabled data management with the Opendatasoft platform.

However, it doesn’t take long to come up against the first challenge, namely that today’s users expect a high level of interactivity on their interfaces. For instance, they might expect a form field that can accept both an address and a geolocation, filters that add or remove points on the map, and be able to control the map through list clicks. Above all, they are looking for hyper-fluid transitions that do not require the page to reload and are guided by light animations and tooltips. All these little details quickly add up to lots of lines of code and complications.

To accomplish this, developer communities agree, choose between React, Vue, or Svelte, which we used. But certainly don’t use JavaScript alone. However, it takes some mastery to work with these well-known frameworks, including new syntaxes, new logic, corresponding tooling, compilation steps, and so on. Their complexities have enraged some veteran developers to the point of lamenting the demise of the “old JavaScript”.

So why did we opt for Svelte, the most recent addition to the growing list of JavaScript frameworks? Svelte is much lighter and more efficient than its two competitors, and it also has a very simple mental model and a rather elegant syntax. That means that minimal ramp-up time was needed.

With two developers and basic knowledge of HTML/CSS/JS, we created the first version of Frais et Local in just two weeks. Add two to three weeks to prototype a generic app, which allowed us to learn the subject and have a demo ready quickly for the Ministry’s teams. The app is certainly simple, but it did not necessitate five years of experience with the framework, far from it.

I found the development experience very satisfying. Svelte made the decision to deviate from standard JS (ES6+) and introduce its own syntax variations, which will then be compiled in ES6, allowing for a very light syntax. Svelte also has a philosophy of “facilitating the integration of JavaScript into HTML/CSS,” whereas React, put simply, is more oriented towards “facilitating the integration of HTML into a large JavaScript database.”

Also, switching from mock-up to dynamic interface with Svelte is extremely natural. We began with a static list in HTML and CSS, then added a map and gradually integrated responsiveness and logic with minimal code. This allowed us to stay very close to the model—and thus the user—from the start of development and throughout the project. Svelte is a simple and fluid tool for creating graphical interfaces.

An app is more than just an interface; it must also manage data and allow users to navigate and access information.

If we only use rendering libraries like Svelte or React, it is very tempting to create apps in a single page, with only interactive elements and no navigation (to a new page). These Single Page Apps (SPAs) pose numerous challenges. For example, it is necessary to return to the main page and load the entire app on each visit, close the app via the back button, integrate asynchronous data, and so on.

To overcome this, Svelte is accompanied by SvelteKit, an application framework inspired by NextJS for React and Nuxt for Vue.

To begin with, SvelteKit makes it very simple to integrate the concepts of page and address by simply matching a file tree to URLs. Our navigation banner, which appears on every page, is stored in a file at the root of our project, and the map (located at the address /map) is stored in the map folder. As a developer, this model is extremely useful: one file = one URL, and a forward slash (/) in the URL = a subfolder.

The tree structure is then compiled by SvelteKit to create true “smart” pages, so that when a visitor arrives at a particular point (a url similar to www.fraisetlocal/carte/id), the main page is not reloaded. If the visitor navigates to somewhere else, SvelteKit only executes the code in the carte/[id] folder, retaining the map and navigation banner because the “www.fraisetlocal.fr/carte/ …“” part of the URL has not changed.

This rather complex operation of cutting files and creating “pages,” which is extremely complicated to do by hand, is completely transparent to the developer. It enables us to easily create navigation that is easy to manipulate, follows web standards (address change, return button, etc.), and has multiple levels of nesting, similar to “sub-pages” or “islands.”

The calling of data is also simplified in a page model. Each page corresponds to a new data request. In an SPA, however, it is necessary to track and follow the user’s clicks. SvelteKit includes a special function for recovering this data at the appropriate time. This allows the data to be integrated into the application that is already loaded in the browser—a complicated step because the data arrives asynchronously in components that may or may not be loaded or mounted.

From our perspective as developers, the result is quite impressive, especially when combined with the Opendatasoft platform’s Explore V2 API. Simply include a call to a URL at the top of each file, as follows: https://www.fraislocal.fr/api/v2/

With each navigation, the appropriate data is loaded directly into the Svelte components. With a RESTFUL API and a language that is very close to SQL, it is very simple to navigate from page to page.
Of course, nothing is perfect. This concept of sub-pages implies that it is not always clear which code will be re-executed and which code will not. Furthermore, we were unable to use the preload function described above because the performance drops too dramatically with a dataset of more than 20,000 records (which explains the appearance of a loading spinner in the application).
The end result is still impressive because you get an app with the interface of a mobile app, the navigability of a website, and the ability to be used offline and in full screen with very little effort, all without writing a single line of back-end code and with very few server calls.

Frais et Local is a purely front-end app that uses the ODS platform as a “external” service by means of an API. The platform and the app are hosted separately and were created by separate teams. This type of app is known as a “JAMstack” where:

• JavaScript (ES6+), for all logic,
• API (understood as web) for the data,
• Markup to describe the interface.

JAMstack is a real buzzword in the development world, and there’s a lot written about it, often in over-simplified articles such as: “Learn React and Tailwind and make an app without a back-end” or “38 reasons why this framework is better than all the previous ones”.

However, it is not possible to create a JAMstack App without APIs. The “A” is more important than the “J” or the “M” in the JAMstack. We use two APIs from our partner Jawg—one for vector map backgrounds and the other for location suggestions—in addition to ODS’s Explore V2 API. It would have taken longer and been more difficult, but we could have made Frais et Local without a front-end framework, which would have been impossible if we had to write all of the back-end code for these APIs.

This approach to using the platform as a Backend/Backoffice-as-a-Service allows for some interesting combinations. In addition to ODS and Jawg, we could add other APIs:

• authentication (e.g., Auth0),
• creation of editorial content with a headless CMS (e.g., Strapi),
• a calendar (e.g., Google calendar), payments, sales, etc.

There is an API for everything these days. These JAMstack apps provide an excellent opportunity for everyone to create their own “recipe” for combining all of these APIs.

This is the power of this frontend/backend decoupling. To be clear, the total cost of developing the API and the JAMstack app is not necessarily less than that of a traditional monolithic app. However, once the critical work of streamlining the extremely complex functions behind an API have been completed, very small teams can quickly take over and develop interfaces. Remember, there were only two of us working on the app over the course of two weeks.

Most importantly, free of the burden of back-end work, these small teams can be formed anywhere, not just at Opendatasoft. A development company, other SaaS software, citizens’ collectives, professional associations, communities, businesses, and more. Who knows where the next app will come from, and what new uses of open data will emerge as a result of pushing the use of our APIs through this type of app?

Find out more about Frais et Local and experience it here.