4 ms·
It's never just adding a field to a structure. That data is going to be there for a reason, and someone is going to write the code to do whatever that is. And
by Silhouette 5y ago
It's never just adding a field to a structure. That data is going to be there for a reason, and someone is going to write the code to do whatever that is.
And to parse the data arriving in a request from the front end.
And to validate the parsed value.
And to perform the necessary security checks. Wait, shouldn't they have been done already?
Where do we keep the validation logic in this design, anyway?
Hang on, what type is this field? Is there a native way to represent that in this back-end language, or some convention we've adopted? Did the parser already handle that?
It's never just adding a field to a structure.
- pseudalopex 5y agoThe scenario was a front end developer making a small back end change or vice versa. In such cases the rest of the code to be written will be in the part they're familiar with. Sometimes the field isn't part of the request. Or maybe part of the minimal training was wrapping ValueError in BadRequest. Or maybe part of the minimal training was we have an exception handler do it automatically. Often there aren't any new security checks. Sometimes field types are documented. Sometimes you have an integer in the database and need the same value as an integer in the front end. Most of the issues you brought up don't go away if you use JavaScript everywhere. Learning a little of another language is comparatively simple.