The current implementation for the /actions endpoints is not ideal. There is a lot of duplicated code, and it would likely be beneficial to make the request bodies mirror corresponding websocket messages, especially as we plan to allow many websocket actions to also be sent in through the REST API in the future, as this would allow developers to easily reuse processing code if needed, or easily migrate if their needs to change. I don't think the parallelism is a requirement though.
This proposal is as follows
Merge /actions/* into a single endpoint. This can remain room scoped or be outside the room scope. In the latter case, the room should be included as part of the request body. The action being taken would also need to be specified as part of the request body.
Extract logic into steps, as separate, reusable functions that take strongly typed parameters, which would enforce correct type checking and input validation
Top level logic would handle basic processing, including pulling and parsing data from the request and doing basic validation (are all the required parameters there, does the room exist, etc.)
The next level would handle room specific process (authorization checks, security confirmation, etc.)
The final steps would be action specific processing, such as validating inputs and ultimately taking the action. For actions that are related the processing can be shared
Some interesting ideas worth considering
Give the action command more structure. Consider something like action: "racetime/connect", which tells us what processing module the action is part of, as well as the specific action.
This would require some updates to the existing websocket protocol, but should be limited to racetime integration related pieces
Could this be written as a middleware stack? This would be difficult, because the stack would be determined at runtime, which there isn't great static support for in express (it can be emulated by just calling the correct function, but it doesn't follow the same rules as normal express execution)
Should we continue to support /actions/{action}? I don't know how express would handle that if there are slashes in the path segment, my gut instinct is that it wouldn't match and would 404. We'd end up duplicating a lot of logic in this way in order to achieve type safety though
The current implementation for the
/actionsendpoints is not ideal. There is a lot of duplicated code, and it would likely be beneficial to make the request bodies mirror corresponding websocket messages, especially as we plan to allow many websocket actions to also be sent in through the REST API in the future, as this would allow developers to easily reuse processing code if needed, or easily migrate if their needs to change. I don't think the parallelism is a requirement though.This proposal is as follows
/actions/*into a single endpoint. This can remain room scoped or be outside the room scope. In the latter case, the room should be included as part of the request body. The action being taken would also need to be specified as part of the request body.Some interesting ideas worth considering
action: "racetime/connect", which tells us what processing module the action is part of, as well as the specific action./actions/{action}? I don't know how express would handle that if there are slashes in the path segment, my gut instinct is that it wouldn't match and would 404. We'd end up duplicating a lot of logic in this way in order to achieve type safety though