4 ms·

Less state changes the better. Managing state is the number one enemy on software.

bluefirebrand 3y ago
I agree wholeheartedly. I don't understand why everyone insists on repackaging the same data over and over. Store it in one format in the database. Read from the database and transform it. Package that into a TO object and send it over the wire. Receive the TO object and repackage it into your local context Take the local context and repackage a bunch of parts of it into each view model as necessary. Everyone just wants to bundle up data and throw it over a wall instead of working together to engineer end to end.
- aleksiy123 3y ago
  Because you don't want couple your data model with your public contract. it allows you to change them independently. When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable. Repackaging the data at every level means you only have to change the transformation at one of those levels. For small projects this isn't a big deal. But if you are working on a large project with multiple teams you have public contracts at multiple levels. You don't want to wade through 10 layers and 10 teams of changes because you change the way you store and compute some attribute.
  - bluefirebrand 3y ago
    If you are working on a large project with multiple teams and you change something like that you better version it or make sure it's backwards compatible anyways. Otherwise you're going to break something downstream and you're still going wade through all of those layers, and now it's less obvious what broke because everyone is re-bundling your data into their own formats. And I am not advocating for dumping your DB rows directly onto the wire for the frontend to fumble. I am just saying it's silly to write a frontend and backend in a super modular, decoupled way when they are actually just a single service.
    - aleksiy123 3y ago
      Not if the public view on the data doesn't change. Just the storage. That's sorta the point. To not have to version if you just change the underlying storage model. For example let's say for whatever reason we were storing a duration as an int. But instead we decided to migrate it to start time and end time. Do we need to force that change on everyone downstream and add a new major version API? Or can we just compute the old duration from the new attributes in the transformation. Even in your example do we really need to change the frontend in this case? For small projects the extra boiler plate probably doesn't out weigh the benefits but for large projects it absolutely does.
      - nerdchum 3y ago
        I disagree completely. If the data structure needs to be changed it needs to be changed at the beginning of the system typically the front end. And downstream code needs to be fixed to accommodate that. Otherwise youve created 20 different state machines for each part of the system stacked on top of each each other each expecting a different data structure and returning a different data structure. So changing anything after the system is sufficiently complex is an exercise in masochism and development will slow to a crawl to avoid breaking one of the 20 downstream black boxes. There should only be a single data structure contract that all teams follow. There needs to be a SINGLE data structure passed through the system originating at the beginning of the system. The data structure can be added to by code along the pipeline but never changed.
        aleksiy123 3y ago
        Am I understanding that you think that there should be just one data structure which is shared between all teams which is a superset of all fields that it could have and people just add data to those fields? So at any given point you don't even know what data is present or not present depending on which point in the pipeline it has passed or not? At this point you may as well just use a object or dictionary. The type doesn't give you any idea about the actual shape of the data.

I agree wholeheartedly. I don't understand why everyone insists on repackaging the same data over and over. Store it in one format in the database. Read from the database and transform it. Package that into a TO object and send it over the wire. Receive the TO object and repackage it into your local context Take the local context and repackage a bunch of parts of it into each view model as necessary. Everyone just wants to bundle up data and throw it over a wall instead of working together to engineer end to end.

aleksiy123 3y ago
Because you don't want couple your data model with your public contract. it allows you to change them independently. When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable. Repackaging the data at every level means you only have to change the transformation at one of those levels. For small projects this isn't a big deal. But if you are working on a large project with multiple teams you have public contracts at multiple levels. You don't want to wade through 10 layers and 10 teams of changes because you change the way you store and compute some attribute.
- bluefirebrand 3y ago
  If you are working on a large project with multiple teams and you change something like that you better version it or make sure it's backwards compatible anyways. Otherwise you're going to break something downstream and you're still going wade through all of those layers, and now it's less obvious what broke because everyone is re-bundling your data into their own formats. And I am not advocating for dumping your DB rows directly onto the wire for the frontend to fumble. I am just saying it's silly to write a frontend and backend in a super modular, decoupled way when they are actually just a single service.
  - aleksiy123 3y ago
    Not if the public view on the data doesn't change. Just the storage. That's sorta the point. To not have to version if you just change the underlying storage model. For example let's say for whatever reason we were storing a duration as an int. But instead we decided to migrate it to start time and end time. Do we need to force that change on everyone downstream and add a new major version API? Or can we just compute the old duration from the new attributes in the transformation. Even in your example do we really need to change the frontend in this case? For small projects the extra boiler plate probably doesn't out weigh the benefits but for large projects it absolutely does.
    - nerdchum 3y ago
      I disagree completely. If the data structure needs to be changed it needs to be changed at the beginning of the system typically the front end. And downstream code needs to be fixed to accommodate that. Otherwise youve created 20 different state machines for each part of the system stacked on top of each each other each expecting a different data structure and returning a different data structure. So changing anything after the system is sufficiently complex is an exercise in masochism and development will slow to a crawl to avoid breaking one of the 20 downstream black boxes. There should only be a single data structure contract that all teams follow. There needs to be a SINGLE data structure passed through the system originating at the beginning of the system. The data structure can be added to by code along the pipeline but never changed.
      - aleksiy123 3y ago
        Am I understanding that you think that there should be just one data structure which is shared between all teams which is a superset of all fields that it could have and people just add data to those fields? So at any given point you don't even know what data is present or not present depending on which point in the pipeline it has passed or not? At this point you may as well just use a object or dictionary. The type doesn't give you any idea about the actual shape of the data.