There should be a backend to the GUI to store preferences. This should be based on a key value store and can eventually be backed by Atomix (that can be the subject of a separate issue in time).
Although there are no individual users for the application at the moment it is envisaged that Kubernetes will provide a user service (probably aligned to the RBAC service).
To allow maximum flexibility the Preferences service can be deployed in the onos-gui image as a Go application. It does not need to have gRPC as an interface (as this would require a grpc-web proxy). Instead the Front end can communicate to this backend through web sockets. The Web Socket payload can be defined in a protobuf (so that code can be generated on both sides through protoc.
This backend can be used in future to support LION, RBAC, authentication etc.
There should be a backend to the GUI to store preferences. This should be based on a key value store and can eventually be backed by Atomix (that can be the subject of a separate issue in time).
Although there are no individual users for the application at the moment it is envisaged that Kubernetes will provide a user service (probably aligned to the RBAC service).
To allow maximum flexibility the Preferences service can be deployed in the onos-gui image as a Go application. It does not need to have gRPC as an interface (as this would require a grpc-web proxy). Instead the Front end can communicate to this backend through web sockets. The Web Socket payload can be defined in a protobuf (so that code can be generated on both sides through protoc.
This backend can be used in future to support LION, RBAC, authentication etc.