Add initial support for the Folksonomy Engine API

[teolemon]

What

Add initial support for the Folksonomy Engine API (READ/WRITE), which will enable writing and reading custom information on products (like storing taste, franchises, whatever is possible…)

For more general info on the folksonomy engine

• https://github.com/openfoodfacts/folksonomy_api
• https://wiki.openfoodfacts.org/Folksonomy_Engine
• https://wiki.openfoodfacts.org/Folksonomy_Engine_Features
  https://api.folksonomy.openfoodfacts.org/docs

SDK auto-generation

We can autogenerate a SDK from https://api.folksonomy.openfoodfacts.org/openapi.json
https://medium.com/@rtlsilva/generating-dart-rest-api-client-libraries-using-openapi-generator-9b3dc517e68c

Routes

Beta Give feedback

1. / - GET - Hello
2. /auth - POST - Authentication
3. /auth_by_cookie - POST - Authentication
4. /products/stats - GET - Product Stats
5. /products - GET - Product List
6. /product/{product} - GET - Product Tags List
7. /product/{product}/{k} - GET - Product Tag
8. /product/{product}/{k} - DELETE - Product Tag Delete
9. /product/{product}/{k}/versions - GET - Product Tag List Versions
10. /product PUT Product Tag Update
11. /product POST Product Tag Add
12. /keys GET Keys List
13. /ping GET Pong

Screenshot

Part of

• Open Products Facts, New APIs

[teolemon]

https://pub.dev/packages/openapi_generator

[monsieurtanuki]

@teolemon I've just tried to use openapi-generator for Folksonomy.
Actually it generates a whole tree structure (here I asked to generate in api/folksonomy):

Like a self-contained package. And I don't know how we could integrate that generated code into the existing project.

• would we be better off starting a new dart project from scratch dedicated to folksonomy?
• was the initial idea just to have the generator generate, then to steal the generated code as a once-in-a-lifetime start?
• by the way for some reason the generated code is not null safe

[monsieurtanuki]

Other aspect to consider: the rest of the off-dart library is based on "json serializable".
Using both "json serializable" and "openapi generator" on the same project may bring confusion.

Another remark: if folksonomy is actually included in the same project, we'd be better off with another dedicated file (folksonomy.dart) rather than openfoodfacts.dart and class OpenFoodAPIClient.

[teolemon]

I have no issue making it a separate package. How good is the auto-generated code @monsieurtanuki ?
Also, if it's good, we could completely automate generation using GitHub Actions @M123-dev

[monsieurtanuki]

Hi @teolemon!
Just to be sure: when you say a separate package you mean a separate project/library, or a separate folder inside off-dart?

Anyway, regardless, I can start locally a new project from scratch playing with openapi generator on folksonomy.

So far I could not play with the generated code that much because the code was not null safe compliant, which blocked compilation at an early stage. In a new project I'll have more freedom, regarding either the code generation parameters or the null safe status of the whole project.

Beyond the raw generated code, we'll probably have to add some fat.

Regarding an automated code generation, for the moment I copied the api json file to a local file, and then ran the generation. If we don't access the api json from an URL repeating the same process on the same local input file will result in the same generated files.

Work in progress...

[M123-dev]

We should somehow be able to generate it automatically, the only question is how good the generated code is. Especially something like null-safety is very important and as @monsieurtanuki pointed out there are some problems regarding that.

But yes I also don't think it makes sense to add this to the already big OpenFoodAPIClient. I would suggest that we create a separate package like openfoodfacts-folksonomy-dart and then we can go ahead and reference it from off-dart.

Somethink like platform dependet packages do it:

• shared_preferences
  • shared_preferences_android
  • shared_preferences_ios

[teolemon]

Currently enjoying the aftermath of my 3rd dose of vaccine 😖
@M123-dev @monsieurtanuki Should I create a separate repo ? is openfoodfacts-folksonomy-dart as suggested by @M123-dev ok ?

[M123-dev]

Get well @teolemon, hope you feel better soon, let's just wait and see what @monsieurtanuki thinks of the idea and then we'll see.

[monsieurtanuki]

Hi guys! I hope @teolemon you feel better by now.

I've just coded folksonomy client in dart (cf. #332). It was so painful to use openapi generator that I tried to code it myself, and it was so easy that I continued.

I don't know that much about folksonomy and I don't know how relevant it would be to make a separate project, regarding the developers that would use it.

What I can say is:

• it looks like folksonomy is designed to be very simple ("tag a custom key/value to a barcode")
• I don't see how it should evolve dramatically - if the experiment around a custom key is successful it's probably going to be part of a new project
• I mean, the code and its evolution looks easy to maintain, and btw it's what we're doing with off-dart - just maintain the field list (e.g. of Product) and let json serializable generate the painful coding
• if we embed folksonomy in off-dart we probably give it more visibility
• it's less maintenance

Less projects, less maintenance.
Less maintenance, less trouble.
Less trouble... less trouble.

[monsieurtanuki]

What's left after #332 are the methods around users and their private data, and the write methods.
Btw the TEST env does not seem to work for folksonomy; I tried api.folksonomy.openfoodfacts.net but with no success.

[M123-dev]

I asked in the slack channel