151–160 of 226 posts
Earlier quoted context omitted.
> migrations engine is pretty poor I find this to be an odd take. The Django migrations engine is probably its strongest feature.
Any change you make has to be atomic, or it is unable to detect the change, and you have to rely on manual migrations.
Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize acc…
Did you ever have to use Vue or other reactive frameworks with Django? Do you use DRF at all or just mostly Django?
Earlier quoted context omitted.
> migrations engine is pretty poor I find this to be an odd take. The Django migrations engine is probably its strongest feature.
There is at least one way that migrating a + b is different than migrate a + migrate b, in ways that you can then only incrementally migrate your project rather than building from scratch. It’s mainly in post migrate actions, and specifically for me adding a group for permissions.
Earlier quoted context omitted.
The reservation app was super simple so no real guidance there I'd recommend really getting familiar with the Django ORM so that you understand how it generates the schema and how to tweak it to get what you want. As far as inventory management - I looked at several opensource projects and tried to understand their schema and use cases. Not just Django ones but other languages like PHP - PartKeepr for example. Invent…
Congrats on making a return on your investment! may I ask how you went about locating a buyer for the screener app?
Where are we on the whole Django versus Rails debate? (Not cannonfodder, I am genuinely curious)
If you need anything related to ML or the sciences, go Python.
Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize acc…
I think CBVs get a lot of unnecessary hate. DetailView, ListView, DeleteView, etc save so much time and repetition for basic CRUD pages. Once things get complicated and you start having to override too many methods, it's often best to write the post(), get(), put(), etc methods explicitly. At that point you are still writing CBVs but it's much more organized.
Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize acc…
It's great for getting things up and running. And can last a long time. But now that we're 40 devs or so working in the same 400k LOC codebase, I'd prefer Java/Spring (or really, Kotlin). So hard to maintain django in the long run, need to be really strict, or one ends up with each app spaghettied with other apps. Doing queries where you filter deep on other apps' models, and since it's only done as kwargs with no ty…
This is what I always found in Django projects with the notable exception of the one that had only one giant app.
I started to believe that one project doesn't get along with multiple apps (kind of microservices) in the mind of the average developer. Only one app Rails style is probably easier to grasp and manage.
Earlier quoted context omitted.
At least for my team we went with FastAPI because we have other tools for everything else, and FastAPI is incredibly simple for new members to pick up. We tend to say that we made a “FastAPI application” but in reality FastAPI is only powering the REST interface for interacting with the platform. We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task process…
> We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together. Just wondering, why have you not gone with Django directly if you’ve essentially ended up reimplementing your own version of it?
The pulling in of other tools happened naturally over time. Perhaps we reinvented the wheel and Django may have saved some time or effort, but ultimately in the end we gained a very deep knowledge of the system we have and the things that make it work, and how those individual pieces might be usable in other projects/scenarios.
A large driver was honestly just that we had no organizational experience in Django, and so there was no one that even would have looked at it and said “Hey we’re just recreating what Django already does”.