search

goodrobots / maverick-web

web based frontend for maverick
MIT License
13 stars 7 forks source link

Refactor api clients setup #148

Closed fnoop closed 4 years ago

fnoop commented 4 years ago

Currently the api definitions are hardcoded in src/plugins/maverick/clients.json. This is not good for several reasons:

Maybe create a mechanism for connecting to window.location by default, and then use browser storage for additional?

fnoop commented 4 years ago

Listen for -api broadcasts #150

fnoop commented 4 years ago

Refactored to remove the hardcoded .json files, in favour of a single default client which is created using the defaults of Maverick FC -api instance (port 6800).

However this is just a sample/default client which will not always work - eg. if just a dev instance of Maverick which will run SITL -api on a different port. So once the default client is created and stored in vuex, there should be a UI interface that can edit the details of all defined clients, so port/hostname can easily be changed.

We could then store this in local storage, but that only persists within a single browser and per domain name accessed. @SamuelDudley Perhaps we could persist the api definitions back through the -api and store it locally there, and it can be retrieved as soon as the -api is connected to. That way we can find -api through broadcast and connect to it, and then -api can upload a list of defined/saved api client instances back to -web. We could also persist this back to all connected -apis, so effectively replicating the client config and creating a mesh of sorts?

SamuelDudley commented 4 years ago

Is it necessary to create replication of client config if we have broadcast on all -api instances?

SamuelDudley commented 4 years ago

Perhaps im mixing up two things here:

  1. How does -web find -api backends to allow a connect to take place?
  2. How do we persists -web user options/preferences across multiple -web sessions (and multiple -api backends0 ?

I'm hoping 1. can be solved with zeroconf as that would help with name collision, etc. If zeroconf is not available from the browser we can make an independent service that runs on maverick (once per maverick instance and exposes the details of all -api instances it can find via zeroconf. e.g. a common web location that all -api instances are exposed by. The port of this process would be common to all maverick installs (by default) making automated discovery out-of-the-box possible. This assumes we cannot simply zeroconf from the browser.

I see 2. as more of a user management issue e.g. for the user logged into -web, what are the preferences? dark mode, light mode, what -api's do they want connected and visible, etc, etc... (possibly we have the equivalent of named user work-spaces to allow multiple configurations per user). So yes, these details could be stored and replicated across all -api instances that the user has an account on. It would require that some sort of user settings storage is needed in -api and a method to transmit these back to -web (jwt?).

fnoop commented 4 years ago

Fortunately zerconf (mdns) can be done in the browser. There are lots of projects, these are just two of the first i came across: https://github.com/agnat/node_mdns https://github.com/tkurki/dnssd.js

fnoop commented 4 years ago

Add a new component for api connections. Try using a vuetify data iterator to display all connections (will be very suitable with multiple connections). Each unit should show the connection, state of the connection, and either an expansion or dialog to edit the connection details.

fnoop commented 4 years ago

Also create a 'core' vuex module. A lot of the core stuff is currently in store/index.js, should be broken out into a core module to correspond with plugins/core

SamuelDudley commented 4 years ago

@fnoop From my comment above:

I see 2. as more of a user management issue e.g. for the user logged into -web, what are the preferences? dark mode, light mode, what -api's do they want connected and visible, etc, etc... (possibly we have the equivalent of named user work-spaces to allow multiple configurations per user). So yes, these details could be stored and replicated across all -api instances that the user has an account on. It would require that some sort of user settings storage is needed in -api and a method to transmit these back to -web (jwt?).

Can I confirm that you are after a way to store and retrieve preferences from the -api database? If so are you okay with -api dumping a big json object back to the browser in response to a user query or do we want to define a settings schema and have everything in its own graphql field?

fnoop commented 4 years ago

Is it necessary to create replication of client config if we have broadcast on all -api instances?

This is an interesting question. Broadcasting -api means that the clients can easily pick up nearby vehicles, and can add each one with the click of a button.

It does however mean that they'll have to re-setup the config for each -web instance on each browser, and as we start to add more -web config that will be a bit of a pain. It's the same for current GCSs - their config is local to that one instance of the GCS.

But then if you replicate the client config across -apis then it will be 'viral', so if you wanted different groups of vehicles with different config that would have to be managed - eg. each vehicle could belong to a different 'swarm' and config would only replicate within that swarm?

fnoop commented 4 years ago

Can I confirm that you are after a way to store and retrieve preferences from the -api database? If so are you okay with -api dumping a big json object back to the browser in response to a user query or do we want to define a settings schema and have everything in its own graphql field?

So to start with I've added persistence to vuex storage. This saves the state of vuex to the browser localStorage so it's reloaded each time -web is reloaded in that browser. There's a 'reducer' in the persistence that restricts it to certain vuex modules (core, cockpit, planner) to start with as other vuex modules don't make sense to persist (and vuex plugins like vuex-router-sync don't like it).

Suggest we use it for a bit and then think about persisting the config back to -api.

fnoop commented 4 years ago

New api/client model now mostly in place and looks good. Still need to: