▲ | kgeist a day ago | |||||||||||||||||||||||||
1. As shown in the article, exposing the internal model to APIs directly is a security footgun. I've seen sites get hacked because the developer serialized internal objects without any oversight just like in the article and accidentally exposed secrets. 2. Exposing internal models to APIs directly also makes it hard to refactor code because refactoring would change APIs, which would require updating the clients (especially problematic when the clients are owned by other teams). I've seen this firsthand too in a large legacy project, people were afraid to refactor the code because whenever they tried, it broke the clients downstream. So instead of refactoring, they just added various complex hacks to avoid touching the old core code (and of course, their models also mapped directly to the UI). In the end, codebases like that, with no layer separation, become really hard to maintain and full of security problems. All because they thought it was "simpler" to skip writing ~10 lines of extra boilerplate per model to map models to DTOs. Lack of layer separation becomes a problem in the long term. When you're just starting out, it may seem like overengineering, but it isn't | ||||||||||||||||||||||||||
▲ | delusional a day ago | parent [-] | |||||||||||||||||||||||||
> Lack of layer separation becomes a problem in the long term. When you're just starting out, it may seem like overengineering, but it isn't I actually agree, but you're setting of a false dichotomy. I do believe in strong layering at the interfaces, for exactly the reasons you line up. What I don't believe in is what I might call "struct annotation based parsing" at those interfaces. Typically, you don't want to pass DTO's around your code. Usually, you take in that struct, and then immediatly have some code to poke it into the appropriate places in your actual data structures. It's very often much easier to simply take a well structured but more direct and generic interpretation of the input data, and write the code to poke it into the correct places directly. It is not that you should define your inputs separately from your internal data storage. It's that the specification of your input structure shouldn't exist as a struct, it should exist as the consequence of your parsing code. > When you're just starting out, it may seem like overengineering, but it isn't It's a real shame that the internet has driven us to assume everybody is a novice. | ||||||||||||||||||||||||||
|