5 ms·

I've always been a fan of Model Driven Development (MDD), which is by today's standards an ancient paradigm. You define the core data model (resources), propert

I've always been a fan of Model Driven Development (MDD), which is by today's standards an ancient paradigm. You define the core data model (resources), properties (attributes), and actions, and auto-generate the UI/API. It was more popular back when OOP first met Web Development. It seems to have fallen to the wayside with manually constructed "fat controllers" being the dominant way to organize web apps today. I have my own framework in MDD style. For a long time I've told people "I can code at the speed of thought." My apps are 80% the data model, 20% the UI, with the middle layer almost entirely generated. Tools like GraphQL, Supabase, and auto-admins kind of go in the same direction.

rrr_oh_man 1y ago
Related thought: "Companies ship their org chart" (https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law)
- all2 1y ago
  Can you expand on this?
notpushkin 1y ago
This is cool, though you would definitely make changes to make UI look decent, and a lot of changes on top of that to make it something that’s a joy to use. For API though, it should probably just work - but then again, there’s tons of stuff like Django REST Framework which, while also a bit dated, works really well in 95% of cases (and lets you handle the other 5%). Yet here I am, writing CRUD endpoints by hand in Node.js...
- rorylaitila 1y ago
  Yep I agree, that "20%" UI is mostly custom view-models to give the right UX. MDD is great for development, but users' brains don't exactly fit the model perfectly, particularly for read views. For write functions however, the views just post almost entirely to the generated API.
KolmogorovComp 1y ago
I've always felt MDD falls short very quickly, because for non-trivial project you often want to show information related to more than one table, and so you have to fallback to writing the controller code manually anyway.
- radlad 1y ago
  Your models/resources do not need to have a 1:1 mapping to your data store.
- rorylaitila 1y ago
  Yep, it can fall down if you force it everywhere. Read views are typically where custom "view models" are needed. For example on my current project with ~30 tables/models (https://humancrm.io https://humancrm.io), there are only a couple custom user views, and a couple custom write functions to simplify the UI flow. The rest of the API is generated from the data models. I take a pragmatic approach and don't force everything into MDD if there is a clear need.

rrr_oh_man 1y ago

Related thought: "Companies ship their org chart" (https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law)

all2 1y ago
Can you expand on this?

notpushkin 1y ago

This is cool, though you would definitely make changes to make UI look decent, and a lot of changes on top of that to make it something that’s a joy to use. For API though, it should probably just work - but then again, there’s tons of stuff like Django REST Framework which, while also a bit dated, works really well in 95% of cases (and lets you handle the other 5%). Yet here I am, writing CRUD endpoints by hand in Node.js...

rorylaitila 1y ago
Yep I agree, that "20%" UI is mostly custom view-models to give the right UX. MDD is great for development, but users' brains don't exactly fit the model perfectly, particularly for read views. For write functions however, the views just post almost entirely to the generated API.

KolmogorovComp 1y ago

I've always felt MDD falls short very quickly, because for non-trivial project you often want to show information related to more than one table, and so you have to fallback to writing the controller code manually anyway.

radlad 1y ago
Your models/resources do not need to have a 1:1 mapping to your data store.
rorylaitila 1y ago
Yep, it can fall down if you force it everywhere. Read views are typically where custom "view models" are needed. For example on my current project with ~30 tables/models (https://humancrm.io https://humancrm.io), there are only a couple custom user views, and a couple custom write functions to simplify the UI flow. The rest of the API is generated from the data models. I take a pragmatic approach and don't force everything into MDD if there is a clear need.