3 ms·

It is an interesting question. If there really is nothing besides the same sets of fields repeated three times one could have some metadata that is used to gene

by cjfd 3y ago

It is an interesting question. If there really is nothing besides the same sets of fields repeated three times one could have some metadata that is used to generate what is necessary in all three layers. But... very often something special must happen in one of the layers. In the GUI it may be that the layout is not uniform, e.g., some fields appear below each other and some next to each other. Perhaps one field should not appear when some other field has particular value. In the between front end and back end there may be something special when one of the fields happens to be readonly and comes from some different source. In the database there may be something special because the legacy part of the code base also needs to read some fields and it has some special needs. And so on, and so on. It then becomes difficult to have anything besides three layers that mostly repeat fields.

lovasoa 3y ago
Hey Ophir here, I'm the co-author of the post. What you say is on-point, and we should have mentioned it in the post. The way I see it is: at the beginning, everything is repeated three times on the three layers. Then, as time advances, complexity grows, and you start having much more specific requirements that will need one of the layers to differ slightly. The common approach is to just duplicate everything three times at the beginning to be ready for the moment when something needs to diverge. What SQLPage [1] is saying, is: when you start, just think about the database. Make it the single source of truth, and iterate quickly to find out what form the data you work on will need to have. You won't get it right the first time, so it's crucial you don't find yourself having to do the work three times for every change. And then, when you need some frontend-specific feature, make just a react component for it and integrate it in the application. Then, as the app grows, you will progressively write a full frontend for it, and an external backend, but you will never have to re-do the work you have done in the beginning. This has allowed me to make some applications that I wouldn't even have thought I would have the courage to start before. [1] https://sql.ophir.dev https://sql.ophir.dev

by cjfd 3y ago

lovasoa 3y ago

Hey Ophir here, I'm the co-author of the post. What you say is on-point, and we should have mentioned it in the post. The way I see it is: at the beginning, everything is repeated three times on the three layers. Then, as time advances, complexity grows, and you start having much more specific requirements that will need one of the layers to differ slightly. The common approach is to just duplicate everything three times at the beginning to be ready for the moment when something needs to diverge. What SQLPage [1] is saying, is: when you start, just think about the database. Make it the single source of truth, and iterate quickly to find out what form the data you work on will need to have. You won't get it right the first time, so it's crucial you don't find yourself having to do the work three times for every change. And then, when you need some frontend-specific feature, make just a react component for it and integrate it in the application. Then, as the app grows, you will progressively write a full frontend for it, and an external backend, but you will never have to re-do the work you have done in the beginning. This has allowed me to make some applications that I wouldn't even have thought I would have the courage to start before. [1] https://sql.ophir.dev https://sql.ophir.dev