Wasp has used superjson for serializing RPC payloads since #1090.
Superjson is great, but it makes the JSON payloads less user-friendly (which isn't a big deal most of the time but becomes pretty annoying when you start writing API tests).
The included metadata is necessary for the client to properly (de)serialize the payload (which was the whole point of including superjson :)).
However, since Wasp generates the code for both the client and the server, there's no need to transfer the metadata over the wire - we can generate the serialization layer on both the server and the client (e.g., with Zod).
This will simplify our payloads, thus making the API easier to test using different HTTP clients (curl, Postman, etc.).
Wasp has used
superjson
for serializing RPC payloads since #1090.Superjson is great, but it makes the JSON payloads less user-friendly (which isn't a big deal most of the time but becomes pretty annoying when you start writing API tests).
For example, instead of:
The payload becomes:
The included metadata is necessary for the client to properly (de)serialize the payload (which was the whole point of including
superjson
:)).However, since Wasp generates the code for both the client and the server, there's no need to transfer the metadata over the wire - we can generate the serialization layer on both the server and the client (e.g., with Zod).
This will simplify our payloads, thus making the API easier to test using different HTTP clients (curl, Postman, etc.).
When designing the new serialization layer, consider the points outlined in https://github.com/wasp-lang/wasp/issues/143#issuecomment-1409301893 and #1070.