[mds-web-socket] extensible entities

[twelch]

This is an initial stab at making the web socket package not so tightly coupled to base MDS VehicleEvent and Telemetry types. It allows any type of JSON to be sent. The Nats EventProcessor sending events on the other end seems to use open-ended generic typing already and the WS server code was simply casting to more specific types. Not clear to me if that gains anything over accepting Json type.

Feedback welcome on approach, and whether other parts that would need this treatment. The WS client seems unused and possibly not in need of migration.

PR Checklist

• simple searchable title - [mds-db] Add PG env var, [config] Fix eslint config
• briefly describe the changes in this PR
• mark as draft if should not be merged
• write tests for all new functionality

[twelch]

A next step on this PR might be allowing the accepted entities to be extended or overridden somehow. Or just removing the entity checking altogether if we assume all senders are to be trusted to send the right thing (thinking out loud)

[twelch]

I made a pass at the ability to override the supported events/entities withing WebSocketServer. Admittedly it's without clarity on where this needs to go, I'm playing around a bit.

Essentially an event-to-entity mapping gets passed in as a function param and it is used to check incoming events and only pass on those that are present in the config. The default mapping is the equivalent to what was previously hard-coded (events, telemetries only).

So if one wanted to override the default mapping with new events/entities, based on how WebSocketServer() is invoked in containers-images/mds-web-sockets/index.ts it would mean the new config would get passed in here, which I'm not sure feels right. A different approach might be to turn WebSocketServer into a class and it can be extended with different configuration. Feedback welcome @avatarneil

WebSocketServer({ event: 'EVENTS', telemetry: 'TELEMETRIES', newEvent: 'NEWENTITY' })

Type signature is
export const WebSocketServer = (eventEntityMap: EventEntityMap = defaultEventEntityMap) => {

With the web-socket types having been expanded to

export const ENTITY_TYPES = ['EVENTS', 'TELEMETRIES'] as const

export type ENTITY_TYPE = typeof ENTITY_TYPES[number]

export type WS_EVENT_TOPIC = 'event' | 'telemetry'

export type EventEntityMap = { [S in WS_EVENT_TOPIC]: ENTITY_TYPE }

[avatarneil]

@twelch Couple of thoughts:
We could use a generic string literal array instead of a map for the types, e.g.

const ENTITY_TYPES = ['event', 'telemetry'] as const
const ENTITY_TYPE = typeof ENTITY_TYPES[number]

This would allow us to pass in a generic at init time for the server, something like

const WebSocketServer = <T extends readonly string[]>(entityTypes: T = EntityTypes) => ...

And then we could define a "temporary" type within the server that indexes that (so we can actually pull out the entries) the same way we do with the defaults. This would allow the configuration to be automagically inferred if the client specifies the entityTypes.

The one thing that's lost with the approach I outlined above, is that we lose the all-caps that is desired for our payload protocol, but to get around that we could just use .toUpperCase() on the entityTypes.

The main benefit IMO is that we can drop all of the loose string typings, and actually have the types be derived from the entityTypes string literal array.

[mdurling]

Looks fine aside from @avatarneil suggestions.

[twelch]

@avatarneil toUppercase isn't quite enough, note 'TELEMETRIES' is not the uppercase of 'telemetry'. Are you proposing I should introduce 'TELEMETRY' and 'EVENT' as a breaking change to WS protocol replacing 'TELEMETRIES' and 'EVENTS'?

Why is uppercase "desired"? Just noting we could avoid the transform altogether potentially.

[avatarneil]

@twelch Ahh, right. Yeah, I think that consolidating down TELEMETRIES into TELEMETRY (or telemetry) worth doing -- docs and the FE will need to be updated. Lowercase is probably fine, having it be uppercase was a totally arbitrary decision I made IIRC

[twelch]

I'm now focused on generalizing the Clients class, which stores subscriptions using hardcoded entity names

[twelch]

@avatarneil this is ready for another review, thanks.

[avatarneil]

LGTM baring the one rename comment @drtyh2o made

[twelch]

Merged latest goodness and made requested changes. Please see last comment @avatarneil and advise on merge timing. Thanks.