4 ms·
An approach I've done in the past for projects that are publicly API-based: Django handles the database migrations and user accounts/models/etc - and you get t
by Klonoar 3y ago
An approach I've done in the past for projects that are publicly API-based:
Django handles the database migrations and user accounts/models/etc - and you get the useful admin to boot, which is just incredible if you ever need to open up the data layer to someone else.
Then just write the API interface in Go/Rust/your language of choice. It decouples the DB modeling from the API layer, but in practice... I've just not run into significant issues with it. I'm sure it could be an issue though, so YMMV.
- Keats 3y agoInteresting, I was thinking of the exact same thing. Glad to see it works!
- Klonoar 3y agoSidenote - thank you for Zola!
- mixmastamyk 3y agoIt's not a bad idea, but the tradeoff is usually you'll have to define your models twice. For whatever reason, that tends to happen anyway, so not that big a drawback in practice.
- Klonoar 3y agoEh, in my case I prefer writing raw SQL for the API side of things - it's more apparent what's going on in code that I actually tend to wind up debugging down the road. As a result I don't really feel like I'm writing models twice - I model then code, then just read it directly, if that makes sense. You are ultimately still right, I think - just a personal nuance I guess.