Falco + NiceGui

[Mte90]

I used Falco as bootstrap and did that changes:

• Removed tailwind, compressor, sentrysdk, django-allauth, jupyter, htmx and other stuff I don't need
• Organized the settings in various files with django-split-settings
  • 
• Added django-unfold as theme for the superuser administration
  • with patch for fastdev feat(blocks): callback boxed/django-fastdev#52
• Created inside the core app a model folder with the one I need, without using the falco cli
• Integrated nicegui with django-nice and various tickets https://github.com/rexsum420/django-nice/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen and a PR feat(fixes): doc and endpoints rexsum420/django-nice#7

Now I have Django as superadmin that is the backend for everything but NiceGui in another instance that frontend (with django-nice automatically sync fields changes to a Django model) and in the nicegui backend calls Django models and stuff. I was able to implement the login (in the screen after the access).
I removed tailwind integration in Django as I don't pages in django as everything is managed by unfold.

This is the complete folder structure:

So why use Falco if I am not using a lot of stuff?
Well the startup phase included everything and a lot of stuff, the CRUD stuff is managed by unfold as I need only the superuser there and for me is enough to have the various models.
Maybe can be an idea to have a light falco boilerplate on creating the app like for my user case, as if there was more Django stuff probably I would keep that as can be useful if simplify the development.

[Tobi-De]

Thanks for sharing this, @Mte90 !
I didn’t know about half the tools you used. Django-unfold is really nice, especially since writing HTML and CSS isn’t the most exciting part of my day. It’s a great representation of what I want to achieve with CRUD in Falco: I’d like to have an easy way get something this clean in term of UI but with all the code easily accessible and easy to modify.
I’m not a fan of customizing Django Admin and exposing it as the app’s frontend, which is why I’ll likely skip Django-unfold.

The CRUD feature came from an idea at my workplace, where we have a solid workflow based on similar concepts to speed up new app development. I’ve already improved the CRUD part in Falco to make it more consistent with Django’s conventions and easier to customize, but I haven’t released it yet since it still needs proper docs, tests, and so on.

Regarding split settings, I haven’t had a chance to respond properly to your issue, but my view boils down to this: while I like organization, Django settings are the one place where I prefer not to over-organize. I started writting django projects with cookiecutter-django and its separate files approach (default, prod, dev), but I found it can lead to confusion. Personally, I think a single settings file is enough since Django settings are straightforward—a simple key-value structure really. Trying to make them more than that hasn’t brought me any real benefits.

[Mte90]

In my opinion split the settings ia qquality life improvements because you don't have to look on a big file and search inside it.

About the rest is understable :-)