I can’t think of a single time where my backend was literally just a crud api over entities. These toys fall apart beyond a hello world app.
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.
This is absolutely true. The magical "write a model, get an app" approach is so tempting. But it's focusing on the wrong problem - optimizing for the initial tutorial experience, not the lifecycle of a production app.
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.
Hi perrygeo, Manifest dev here, I totally agree with you: quick starts can be harmful in the middle/long term so most of the times I would probably accept to invest more time in the beginning building something flexible.
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.
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.
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.
Rather that dismiss this Proof-of-Concept as a “toy”, I think it’s useful to step back and ask whether all of those things (validation, authorization, authentication, auditing) require lots and lots of code to express, or if they could also fit into a single YAML file approach.
Is there a benefit of Mongo for that over just Postgres with JSONB columns? You're still storing JSON in Postgres but you'd get the relational aspects too for things like users having many forms, billing and account relationships etc.
No benefits that I can think of at the database layer. Postgres's addition of JSONB columns represents the best of both worlds. Funny to think that all of that noise about nosql replacing rdbms was essentially nullified by the addition of one column type.
Easier horizontal scaling and organizational inertia would be the main reasons to use mongo over a jsonb column. I wouldn’t introduce it to a psql shop if they are already great at running psql.
I frequently tell people that Go is my least favorite language for reasons like this and the response is often some form of the no true Scotsman fallacy.
I have to disagree with this, clearly visible under my profile. In general I try to stay clear of any vaccine debates, in general because of being labeled in certain ways I don’t identify myself with at all.
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.