Request, response types, values, Validators should be exported by back-end, maximally

[sanjarcode]

• Yesterday, I wrote some Ruby (Rails) code just because request keys that were decided for an API differed from the column name (which Rails defaults to for request keys).

• This mapping code was non-trivial, since one has to not reset something if the request doesn't have the key (think undefined vs null in JS). - Also, the form used on the frontend had a set of generic validators, for showing wrongly entered values. I had to add a custom validator if value was 'oneOf' a given array of fixed values.

---

• at a discussion during the backend code review, the lead backend engineer suggested the changes were cosmetic, perhaps useless. So the team leads got together and decided to use ENUMS on the frontend whose name matched the decided keys but values would match the BE column names exactly. The PR, branch is now useless.

---

I thought this was a stupid way to code, atleast if you own both the server and client app.

• The backend has the strongest validation of all, since it ingests data.
• the frontend validations depend directly on backend validations. Of course, how the UI can be decided in the frontend code.

---

So, if the backend could just generate a "type" file with

1. key names
2. value type
3. Possible values
4. Validators to be used by the front-end (if calculable directly, i.e. can be checked without database lookup, atleast)

This would solve a lot of communication tasks, and cosmetic mappings.

[sanjarcode]

TypeScript is a tool that solves one part of this problem - a real programming language to enforce and specify types and values.

Unsolved:

• The exportability from the backend, of such file.
• excluding directly incalculable validators.
• how to do this if request and response are too "serialised" (different) from actual models/columns