Split Display.pm into API.pm and Frontend.pm, make frontend use the API

[stephanegigandet]

What

Related to the discussion about rearchitecturing Product Opener: #5170

I've been trying to find ways to better separate things in Product Opener: what's relative to the web frontend, to the API, to MongoDB queries, to processing products when we write them etc.

I'm thinking we could try to split Display.pm which is probably the worse module in terms of how everything is mixed together.

We could do it gradually:

• create API.pm and Frontend.pm
• gradually move functions from Display.pm to API.pm and Frontend.pm if there is a clear split
• if there isn't a clear split, refactor the function so that there is one
• gradually remove dependencies to Display.pm in other modules and scripts
• gradually remove MongoDB / product .sto files write and read access from the frontend, and have the frontend use the API instead
• create missing APIs (e.g. user management, products aggregates (list of tags for a facet) etc.)

What do you think?

Part of

• Client/Server structure using API #80

[M123-dev]

@stephanegigandet, as I mentioned in #5170 I think this is a good idea. But how do you imagine the transition time, this process will take a relatively long and possibly lead to many errors and broken things.
Should this repo be continued, should API.pm and Frontend.pm be new repositories or what were you thinking of?

[stephanegigandet]

I think we can do it gradually without breaking anything, we can create new empty modules API.pm and Frontend.pm, and move functions one by one.

[M123-dev]

sounds good

[CharlesNepote]

A great idea IMHO. I think there are many benefits:

• code architecture will be more clear for newcomers
• it will help front-end devs
• it will help to fine-tune the API
• it's a concrete and first step to architecture changes we talked about (languages, etc.)
• as Stéphane already said, it allows moving gradually without breaking things

[M123-dev]

Is there already any progress here

[teolemon]

@stephanegigandet @M123-dev I believe there will be progress tomorrow when this is deployed to .net

[teolemon]

For the record, @VaiTon has started an alternative web frontend: https://openfoodfacts-explorer.vercel.app/

[github-actions]

This issue has been open 90 days with no activity. Can you give it a little love by linking it to a parent issue, adding relevant labels and projets, creating a mockup if applicable, adding code pointers from https://github.com/openfoodfacts/openfoodfacts-server/blob/main/.github/labeler.yml, giving it a priority, editing the original issue to have a more comprehensive description… Thank you very much for your contribution to 🍊 Open Food Facts