[RM] EPIC: RASENMAEHER integrations can supply UI contents via their integration-APIs

[benjamsf]

Epic

We want to make product integration APIs capable of supplying UI contents. So, when RASENMAEHER is booted, we would get respective product UI contents to RMUI, according to the product manifest.

This is will enable integration of new products to RM, at least resolving any UI concerns on this.

Breakdown

• UI feature: Make RM UI load Service related content from their respective integration APIs
• Rmapi feature: Rmapi support for new integration-api supplied api endpoint, /api/v1/guides
• Fpapi feature: Spec for new integration-api endpoint /api/v1/guides, to let product integration api supply UI content of the product to RMUI
• Takrmapi task: Implement new /api/v1/guides to supply UI content to rmui.

Intention

Define UI contents as YML at product integration-api, build them to single "product.json" at integration api build-time using the RUNE library. UI will fetch product list from RMAPI using the api endpoint /api/v1/healthcheck/services so, that on list change (new or modified), it will fetch product-related contents using the api endpoint /api/v1/guides. After fetching, UI will construct product-related views from this JSON & update LocalStorage for translations. Only run this initially and if the product list changes

Team developing RM integration for a product X would specify their UI contents as YML, according to the spec set at fpapi and takrmapi. Into UI dev mode, we leave a way to try writing the UI components as this YML spec directly there, so ultimately you could develop them there and then just move the contents to your new your product-rm-integration-api.

Execution

• 1. @thejhh will develop a library that takes in YML and builds it to JSON, Rune
• 2. @thejhh will develop logic to RMUI that builds React from that JSON.
• 3. Marko does the new rmapi/fpapi endpoint /api/v1/instructions/{language} (or else)
• 4. The spec is reviewed by RM team.
• 5. Marko will implement the spec to rmapi & takrmapi, and make a test fire of it.
• 6. @benjamsf will test & implement how the read of that api endpoint would take place, in RMUI
• 7. Integration & system tests => epic ready to be 🚢 ed

Spec (Keep this up to be the truth)

sequenceDiagram
    actor User
    participant ui
    participant rmapi as RASSE
    participant iapi as Product Integration API
    actor apidev as Integration API dev
    
    apidev->>apidev: Create content as RUNE YAML
    apidev->>apidev: Compile RUNE to JSON
    apidev->>iapi: JSON to API code
    apidev->>iapi: Make JSON dynamic
    User->>ui: Open page with products
    ui->>rmapi: Ask for product list
    rmapi->>rmapi: Check manifest for products
    loop For every product
    rmapi->>iapi: Query metadata
    iapi->>rmapi: Return metadata
    end
    rmapi->>ui: Return all products' metadata
    ui->>User: Render list
    User->>ui: Select product
    ui->>rmapi: Query produt instructions
    rmapi->>iapi: Ask for user specific instructions
    iapi->>iapi: Construct JSON for this user
    iapi->>rmapi: Return personalized JSON
    rmapi->>ui: Return personalized JSON
    ui->>User: Render

Loading

Linked docker-rasenmaeher-integration repo (top level) PR

#98

To be considered

• edit: to be considered-things resolved below

[rambo]

pvarki/python-rasenmaeher-api#104 is the correct sequence.

the API endpoints are already separated. Of course we do not completely change existing implementations, they get marked as deprecated and the new api has a new version number.

Everything user-specific must be dynamically inserted to the JSON the integration API returns by the integration API at runtime.

[benjamsf]

Check, set the flowchart from pvarki/python-rasenmaeher-api#104 to here.

From the UI point of view, shouldn't there be this separation of concerns:

1. ui data that is shared among all types of users, and
2. ui data that is specific in some way, either personally or based on the user role.

In case of 1), ui should ask the product instructions (Instructions as in some content) once and then hold that information in localstorage. No need to load and render x times of y MB of data of what is same to each user. In future, manage the local storage so that if product metadata changes, what
In case of 2) ui probably has to ask these from the api if user tries to access them. This is the case for v1 api /api/v1/instructions as for now.

Aaand these will be matters of how ui wants to handle storaging etc, and how integration api wants to do the thing drawn at the spec

[benjamsf]

discussion at discord
https://discord.com/channels/1047112511603867668/1281929170489966704