Yeah, don't use django/rails if your app is going to mostly communicate with the backend through an API. Use flask or other smaller framework. The only advantage of using django or rails would be the builtin auth (and admin)
In fact don't even waste time with relational DBs unless you need to, especially if you're still prototyping the solution. (Or just use the json field in PostgreSQL if you prefer)
>only advantage of using django or rails would be the builtin auth (and admin)
Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc.
One can paraphrase Greenspun's tenth law and make it about this: Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".
Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".
But they don't, do they? I've worked on plenty of back-end code that just needed simple routing, rendering, auth, and DB transactions. No need for a big batteries-included framework for that sort of thing. For that matter, I've worked on back-end code that wasn't DB-backed, at least not in the normal sense of talking to something like Postgres or Maria where a standard framework was going to be useful. I've also worked on back-end code that was fundamentally providing an API, with or without some basic routing and server-side rendering instead of just downloading static front-end assets.
In short, there is pretty much no functionality that is completely universal about back-end code for web sites these days, except for the basic server mechanics and underlying protocols. We build all kinds of systems using browser-based technologies, and you just have to look at your requirements and choose a set of tools that will get each job done.
> Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc.
I am familiar with Django, thanks. I've also worked with "rest-heavy" services in Django and it wasn't very advantageous as opposed to using a lightweight framework.
> Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework"
Except that your "full-framework" functionality is in the frontend, hence you don't need it on the backend.
You might also be trying to turn your "full-framework" car into a boat, instead of building a boat from an engine, with the results you might expect from it.
In fact don't even waste time with relational DBs unless you need to, especially if you're still prototyping the solution. (Or just use the json field in PostgreSQL if you prefer)