No validation, no authorization, no authentication, no property level permission, no events, no auditing… the list of what is actually needed for a real application goes on.
No validation, no authorization, no authentication, no property level permission, no events, no auditing… the list of what is actually needed for a real application goes on.
That initial scaffolding takes, what, an hour or two? Getting that down to a minute or two is not a high priority, considering 99.9% of the lifecycle of the app is dominated afterwards by what that structure allows. Coding yourself into a corner on purpose, just to save a few minutes on launch, is a strange tradeoff.
I know because I've made that tradeoff dozens of times and cursed myself every time. I built a web framework that did auto UI based on Django models, postgres and jquery. It was active 2010-2014 and I built dozens of production apps with it. That initial "wow" factor of going from a model in your head to a full user interface is very compelling! I did live demos with clients where we'd code up a model and launch a site in real time. Cool, right! The problem was the structure only fit certain types of applications and as we stretched it into adjacent domains, we had to break it down and effectively "eject" from the framework, making each instance a custom app - which is what we should have started anyways.
If it's there as an option it means eventually it will be used and there's usually no easy way to go back...
The unsettling part is wondering if you made the right choice at that point which usually is a non-problem but the point of a framework is to establish convention and order.
However, you are talking here as a senior/expert developer - as you were already coding in 2010 ;) - but junior devs OR frontend devs may not be able to create that Django+DB+API app so easily. That is an important point to consider.
This is a proof of concept only so it sticks to a simple CRUD set of endpoints.
Some of the features that you evoke are already on the pipe (Auth, permissions ABAC/RBAC...) but obviously it will still have limitations for more complex use cases...
I am thinking about a nice hook system to add this kind of logic somewhere else like on edge functions or external APIs. The point is to keep things simple and allow more use-cases without too much trade-off. Hard choices.
I'm curious how you see the project evolving as you add those things. How do you see it differentiating itself from rails or django?