Open Lenra from outside clients

[Nesqwik]

Outside client system can be a huge boost to Lenra. This allow any dev to use React/Flutter/Angular or any client that can handle websocket to build an app using Lenra. Lenra then behave like a back-end listener action with realtime data system.

I want to be able to create my own websocket and connect it to the Lenra system.
I want to be able to connect my front-end component to a back-end "view" with "props" to parameter it.
My back-end View will connect to a chunk of data using a Query and format the data as i need to.
I want to be able to run back-end listener from a front-end click.
My listener will update data then my view connected to the back-end data should update realtime.

[taorepoara]

I think we should focus first on our built-in client and make the possibility of using an outside client for the end of the beta. @Nesqwik can you document your PoC here (or if it's already done add a link to it) ?

[Nesqwik]

Sure i'll finish the doc and link it :)

[Nesqwik]

Lenra View system

Requirements :

In order to work, this View system require some other feature to be implemented first.

• The dev must be able to register the user using some sort of OAuth API.
• The manifest and the app should be rework to let the dev handle the routing of calls.
• The Query system should allow some references to metadata in it (like @params.id, @user.id …)

The Goal :

Open the view system to allow devs to use external UI library. The view system will keep the ws listeners call secure. The dev will provide multiple Routes. Each entrypoints will specify a Widget name, an Input query, a props, a View type and a route path.

The manifest

Let’s take the Counter app as example.

module.exports = () => {
  return {
    routes: {
      "/counters": {
        name: "countersJson",
        query: {
          "$find": {
            "_datastore": "Counter"
          }
        },
        view: 'json'
      },
      "/counters/:id": {
        name: "counterJson",
        query: {
          "$find": {
            "_datastore": "Counter",
            "_id": "@id"
          }
        },
        view: 'json'
      },
      "/lenra": {
        name: "main",
        view: "lenra"
      },
    },
  }
}

Here, the dev can define any number of routes that point a widget :

• The name property (required) points to the name of the widget
• The view property (optional, default to Lenra for backward compatibility) define what kind of View is provided. Values are json or lenra)
• The query property (optional) allow to ask for data directly on the entrypoint
• The props property (optional) pass the props to the widgets.
• The key is the route name
  • The route have parameters using :name (/item/:id for example)
  • All the properties in a route are extracted and passed into the props.
• The “/lenra” route can be is the default route called by the lenra UI system (for now)

The widgets

The view: "lenra" widgets are left untouched.

The new view: "json" is basically a json object with one special feature

module.exports = (data, props) => {
    const counter = data[0];
    if (!counter) return {};

    return {
        _id: counter._id,
        value: counter.value,
        increment: {
            type: "listener",
            action: "increment",
            props: { _id: counter._id }
        },
        decrement: {
            type: "listener",
            action: "decrement",
            props: { _id: counter._id }
        },
        delete: {
            type: "listener",
            action: "deleteCounter",
            props: { _id: counter._id },
        }
    }
}

This widget will return a Json object containing the counter value and ID. It will also define some listener call (increment, decrement and delete) contain all the necessary information to run the listener with the same name.

// This listener
{
  type: "listener",
  action: "increment",
	props: { _id: counter._id }
}
// Is transformed into this code
{
  code: "..."
}

The listener call object will transformed into a simple code (basically the hash of all the properties) This code can be then send by the client into the websocket to call the associated listener.

• This code will ensure that your listener is secured and cannot be called by any user that don’t have the right to perform this action.
• This means you don’t have to check for permission !

Additionnal work that can be added

After this system is enable, we can add some features to it.

• A client-side route system for the Lenra View that will connect to the corresponding route

[taorepoara]

I think that the view type should be at the top of the structure like this:

module.exports = () => {
  return {
    lenra:
      routes: {
        "/": {
          name: "main"
        }
      }
    },
    json:
      routes: {
        "/counters": {
          name: "countersJson",
          query: {
            "$find": {
              "_datastore": "Counter"
            }
          }
        },
        "/counters/:id": {
          name: "counterJson",
          query: {
            "$find": {
              "_datastore": "Counter",
              "_id": "@id"
            }
          }
        }
      }
    }
  }
}

This structure permit a better view separation and seems simpler to me.

[Nesqwik]

Thats one way to do it, i'm not against it.

If we have no other data to put under the lenra/json key, we could remove the "routes" key and put the routes directly under "lenra" or "json" key.

[taorepoara]

Yes, that would be better indeed.

We have to answer those questions to know if there is anything else:

• How do we manage CRON: https://github.com/lenra-io/Lenra/discussions/137
• How do we manage the opening app UI (logo app name...)
• How do we manage the components api version of the app
• How do we manage webhooks: https://github.com/lenra-io/Lenra/discussions/128
• Any other quest ?