How we build UI from MSSQL's sys.parameters

Shoot me an email at angus@flank.cloud
If you’ve ever seen the API for a React component and the columns of MSSQL’s sys.parameters, you’ll notice a lot of overlap.
To put an input box in a React app, you need to tell the component library:
Which component you want (e.g. datepicker, input, checkbox)
What the label is going to be
Any specifications for input control (e.g. min/max).
Turns out a lot of this information exists in sys.parameters in MSSQL:
user_type_id- Which component (i.e.BIT→ checkbox) ✅name- Label ✅max_length,precision,scale- Input control ✅
This gives you enough information to turn a stored procedure like this…

…. into a user interface like this:

The page title comes from sys.objects. And the decision to render two datepickers (instead of, say, two input boxes) comes from sys.parameters.
Is simple frontend work “toil”?
Google SRE defines “toil” as work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.
If we’re building simple CRUD apps over and over again, aren’t we just wiring up database fields to frontend components? Doesn’t that check all the boxes of “toil”?
Curious to hear any thoughts.


