Currently the diverging naming conventions of our frontend code and the API payloads is bridged by littering Types.fs with [<JsonProperty>] pragmas. This approach is error-prone and fails to leverage the full available API surface of NewtonSoft. One future aim should be to refactor the serialization pipeline in Json.fs to reduce this error by automatically translating the most common mapping, i.e. messageId to message_id, as well as kind to type as we have been to avoid keyword conflicts, automatically.
Currently the diverging naming conventions of our frontend code and the API payloads is bridged by littering Types.fs with
[<JsonProperty>]pragmas. This approach is error-prone and fails to leverage the full available API surface of NewtonSoft. One future aim should be to refactor the serialization pipeline in Json.fs to reduce this error by automatically translating the most common mapping, i.e.messageIdtomessage_id, as well askindtotypeas we have been to avoid keyword conflicts, automatically.