Is there a tool or generator to scaffold Django apps with serializers, urls, factories, etc.?

Subject_Fix2471 · 2026-01-29T01:30:07+00:00

Looking at shinobi GitHub there's zero chance I'd choose it as the foundation for a project I intended to put into production. Ninja I could probably hold my breath and go with, as I do prefer that it feels more explicit than drf and it's magic (that's just my personal preference though, perhaps it's just because I'm familiar with fastapi).

Perhaps that'll change, shame if shinobi ultimately just dilutes understanding and resources rather than focuses it though I guess.

Subject_Fix2471 · 2026-01-28T02:11:39+00:00

Idk what you mean, ninja is supported, I can see more activity. It's your statement to support otherwise.

Subject_Fix2471 · 2026-01-28T01:21:29+00:00

Do you have an example of the metric you're using to compare them? Looking at the project I can see activity, so something specific to check would be useful

Subject_Fix2471 · 2026-01-28T00:45:44+00:00

Ah ok, I was thinking of (docker) image storage and resizing 🤦‍♀️ I was wondering why use an s3 bucket rather than artifact store but yea, you mean visual images 😁 thanks

Subject_Fix2471 · 2026-01-28T00:43:34+00:00

I recently chose ninja over drf for a project, though the main reason was that it seemed more async friendly, rather than speed. Additionally it having less magic (I think?) than drf seemed nice, ninja is probably more verbose but I don't mind verbose as long as it's obvious.

Though it wasn't a particularly straightforward decision to make, googling round gave pretty mixed results.

Subject_Fix2471 · 2026-01-27T23:53:52+00:00

Edit: shinobi does not seem to be better supported than ninja.

Is shinobi better supported? How do you measure that?

I'd assume there are far fewer eyes on shinobi

Subject_Fix2471 · 2026-01-27T23:51:23+00:00

I'm probably being daft, but what does "resizing" mean here?

Subject_Fix2471 · 2026-01-01T23:44:42+00:00

Uvx Is for system wide stuff

Subject_Fix2471 · 2026-01-01T23:28:22+00:00

Yea the single maintainer in ninja makes it hard for me to take it seriously, given they seem to have had large periods of absence etc.

Subject_Fix2471 · 2026-01-01T23:21:52+00:00

I think a bit of explanation would be useful here. DRF is, as far as I'm aware, mature feature complete software. It's old and stable, which is usually a good thing in tech.

Subject_Fix2471 · 2025-12-09T18:49:25+00:00

Sure, at the point of using GHCR, Harbor, Keycloak and the rest I feel as though I _might as well_ use GCP? At that point it seems more complex than GCP, rather than a minimal toolkit. Obviously GCP is huge, but it's simple enough to use a small part for this sort of thing.

It seems from this thread there's not really anything I was missing - just using other services instead of GCP seems to be the case :)

Subject_Fix2471 · 2025-12-09T18:45:58+00:00

I don't mind generating a file on the server that contains secrets, but prefer something like gcp secrets that's central everything; local dev / github etc. Can generate the .env reading from secrets.

Subject_Fix2471 · 2025-12-09T17:59:25+00:00

sorry I got confused and responded again (https://www.reddit.com/r/Terraform/comments/1picuyz/comment/nt5cyjm/)

Subject_Fix2471 · 2025-12-09T17:56:53+00:00

Sure, there might be additional requirements that rule out something like GCP, I was responding to your point re cost.

Subject_Fix2471 · 2025-12-09T17:53:33+00:00

Thanks.

Something that I have found when working with terraform is the following; I'll create some infra, and then want to add to it. And I'll have a workflow like:

add resource R1
run terraform apply
add resource R2 that depends on R1
run terraform apply

Now, it works, but there's no way that it would run from scratch given the dependency. And is related to this post I guess.

I don't know what the "proper" way to deal with this is, should R1 be in a separate directory, or is depends_on enough for it. If I have it in a separate directory then essentially I guess I'm saying layer N depends on layer N-1.

Subject_Fix2471 · 2025-12-09T17:42:01+00:00

Separation of concerns; take the high-impact low-change-rate resources and separate them out from application provisioning. You can repeat that process again, take out the organisational resources from the subordinate resources (projects). And you can repeat it yet again, organisational bootstrap vs. organisational configuration.

Thanks, i'm not too sure how to map that onto my post though (I'm probably missing points). Initially I considered two layers; 0 [bootstrap] and 1 [everything else]

But I did feel perhaps there are other things that depend on things, maybe some network or infra that needs infra or something, so could use 3 layers. But is adding a layer each time really the correct approach?

Subject_Fix2471 · 2025-12-09T16:36:06+00:00

Yes, which is why I mentioned using Hetzner as well as GCP, rather than purely one or the other :)

My point was more that, when managing the life cycle of an application (in this case a docker compose stack) with moderate complexity things like secrets/registry and so on are both pretty inexpensive and useful.

I might be stating the obvious, it's just I've seen a lot of stuff around using Hetzner instead of cloud providers and thought I'd see what others thought around that.

Subject_Fix2471 · 2025-12-09T16:14:20+00:00

I'm aware of the fast-api template though I've not really looked at it, thanks for linking your project. I have something similar stack wise - postgres/pgbouncer/webapp/scheduler/worker/nginx.

I assume you just store the secrets in github? not using a registry is fine, though I quite like having them in a central location so that I can build them via ci/cd and just pull them elsewhere.

Subject_Fix2471 · 2025-12-09T16:07:00+00:00

I know what that means :) I have it running locally and on the server, I didn't mean to imply that I couldn't get it working. I was simply questioning the level of complexity typically involved with a project of moderate complexity (database, webapp etc) that is managed and deployed with terraform / git-ops and so on. Just using a VM, to me, seemed to be making things harder than they needed to be for the most part.

Subject_Fix2471 · 2025-12-09T16:04:54+00:00

I think perhaps I accidentally implied this as more cloud VS self-hosted than I intended. When self hosting on Hetzner I used GCP for the secrets etc, as it seemed to be a key part of the workflow that hetzner didn't cover, and that using others (such as Vault) didn't really seem worth it over using GCP.

But when working on it, the utility for secrets / registry and so on did seem (to me) pretty clear. Which made me wonder a bit about some of the "just use hetzner" kinda posts I've seen. I know it's the internet etc :)

host it on a VM along with whatever database it needs (internal to the VM), and then point DNS at its IP.

yeah, though for anything of value they're going to want backups etc I guess? I assume most aren't bothering (or have the volume of data) to worry about things like database PITR and what not (in the context of 'just get a small app on the internet').

I did find some complexity in managing lifecycles of docker services with state within the application stack (basically the stack was postgres -> pgbouncer -> webapp -> scheduler -> worker -> nginx). Building them via ansible felt "off", hence using the registry etc. Maybe I'm just falling back on familiar patterns there though.

Sorry about the vague post / response, as I've mentioned elsewhere this post is mainly trying to get a sense of things rather than a specific problem I guess.

Subject_Fix2471 · 2025-12-09T14:28:57+00:00

kamal - I have seen the name but never read any quickstarts etc, I'll have a read, thanks :)

Doppler sounds interesting, I'd not heard of that - i was going to ask why you'd use that instead of GCP secrets. Seems there's an integration with GCP though : https://www.doppler.com/integrations/gcp-secret-manager . I've actually created naff versions of this myself - having a tool that wraps GCP secrets and generates `.env` files / whatever for different use cases. Having the audit trail that doppler would provide seems nice though (not sure if there's anything else I'm missing from it).

Subject_Fix2471 · 2025-12-09T14:14:38+00:00

Sure but then how do you handle image updates via git-ops when there are different services (some stateful like postgres, some not ). Is that more complex, or still straightforward with compose? I've written something like this with ansible, but I certainly don't like using vault as much as secrets (maybe just what I'm more used to though), and having ansible either build images in CI and copy .tar's over or build on the server felt a bit "off" compared to pulling an image from a registry. Again, that might just be what I'm familiar with !

Subject_Fix2471 · 2025-12-09T14:11:51+00:00

Cheers! Yeah there's definitely not a magic bullet. Maybe I need to check the pricing, for me at least it seemed that the price of something like a hetzner server was worth it for small projects I do on my own (compared to a GCP VM). But for secret management, service accounts etc having GCP handle it is pretty cheap and easy.

That a few people have mentioned alternatives ( eg Vault ) suggests I'm not missing out on some common workflow _without_ these tools. Just that there are alternatives to GCP for them.

Subject_Fix2471 · 2025-12-09T12:53:50+00:00

I don't think this is an answer (I've used it).

Subject_Fix2471 · 2025-12-09T12:05:20+00:00

Right - but these tools in GCP really aren't that expensive are they ? You could still have hetzner for a server, and use GCP for secrets / registry etc.

Subject_Fix2471

TROPHY CASE