I think it might be interesting to provide some examples without the need to upload a schema, since I assume most people playing with it won't have one ready right off the bat.
It looks like all the data interfaces add this, which will (a) happily swallow typos, and (b) give you no warning that you might be pushing extra (i.e. private) data to the remote.
I understand that some people like the flexibility it provides, but it would be nice for that to be an option. There's no way I'd use the generated types with that, and the tool has a lot less value if I still have to go in and modify its output by hand.
This is a really good point. The generated SDK is configured to allow a super-set of the API request body to hit the backend, which could expose unnecessary data fields if passed in by client code.
It comes because we’re a bit pragmatic: if a user doesn’t specify their full data structure in their OpenAPI specification, and we can’t generate a strict type, we allow an arbitrary structure to reach the backend. In our experience the hard bit isn’t really writing the SDK, it’s making and maintaining a good OpenAPI spec (hence part of the commercial product we’re moving towards is the ability to generate a strict OpenAPI specification directly from handler code / traffic analysis in a backend server). Your concern is totally valid, and this is something we will make configurable.
I think it might be interesting to provide some examples without the need to upload a schema, since I assume most people playing with it won't have one ready right off the bat.