Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 4.0

djangoproject.com

Post reply on HN
Print view View original

101–110 of 226 posts

Re: Django 4.0

#101

Post by robjan »

anoojb wrote: post #100
rlawson wrote: post #45

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’ve found managed databases to be quite expensive at places like Azure and AWS. Especially compared to just installing pgsql on raw compute. What managed databases do you recommend that adequately meet price/performance needs of indie developers?

I've used ElephantSQL before. As long as you write efficient queries (especially avoiding N+1) and choose the right data centre it's usually reasonable for a small project.

Re: Django 4.0

#103

Post by ehutch79 »

rlawson wrote: post #82
raihansaputra wrote: post #69

Earlier quoted context omitted.

Do you have any recommended readings/resources to help with data modelling? Especially regarding reservation/scheduling and inventory management?

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…

The most difficult part of inventory management is convincing employees that telling the system that 40000 units moved when only 38732 units moved is a problem

Re: Django 4.0

#104

Post by int0x2e »

anoojb wrote: post #100
rlawson wrote: post #45

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’ve found managed databases to be quite expensive at places like Azure and AWS. Especially compared to just installing pgsql on raw compute. What managed databases do you recommend that adequately meet price/performance needs of indie developers?

PaaS and managed services let you trade money for time and effort - patch management, backups, security, config optimization, simplified scale-out/availability/etc. all take time, effort and skill to get right and keep running well over time. With RDS/Aurora/AzureSql/CosmosDb (and the like) you get to focus on your app/service/product instead. It all ends up being a question of how much your time (and being able to focus) are worth to you. If this is an actual business and not a hobby, and assuming market rates for your time - I believe the managed service offering ends up the cheaper option overall.

Re: Django 4.0

#105

Post by bitexploder »

Alex3917 wrote: post #88
rlawson wrote: post #45

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…

> function based views Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here: https://github.com/Alex3917/django_for_startups/blob/main/dj... If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting t…

Class views are fine. Even just a TemplateView saves some effort, but it comes with learning some Django magic about the life cycle of the view to load data in and out and what methods to implement. I still recommend it. You don’t have to fully embrace it and it lets you avoid repeating a lot of code.

Re: Django 4.0

#106

Post by Nextgrid »

clepto wrote: post #75
windexh8er wrote: post #44

Earlier quoted context omitted.

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask? I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).

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?

Re: Django 4.0

#107

Post by nickjj »

slig wrote: post #90
nickjj wrote: post #47

If anyone is interested I updated my example Docker Django app to use Django 4.0 at: https://github.com/nickjj/docker-django-example It pulls together Django, Docker Compose, Postgres, Redis, Celery, Webpack and TailwindCSS. It's all set up for both development and production. It's also been updated to use Django 4's new built in Redis cache back-end instead of the django-redis package.

Thank you very much! I've been running my own clobbed together version of a Django + Webpack configuration, and I'm very interested in learning from your code how you manage to run only one container with both Django and Webpack on dev mode.

No problem.

I have things split out where the Webpack dev server runs in its own container only in development. It uses the Docker Compose override pattern to skip it in production along with Docker's multi-stage builds to ensure production assets get built and digested with collectstatic when DEBUG is set to false.

I gave a talk this year at DockerCon on a whole bunch of patterns I use with Docker Compose and my Dockerfile to get dev / prod parity without duplication and overall best practices.

The video and blog post of that is at: https://nickjanetakis.com/blog/best-practices-around-product...

It walks through a live demo (0 slides) going over a Flask example app but it's 100% the same for Django.

Re: Django 4.0

#108

Post by Radim »

legutierr wrote: post #58
Radim wrote: post #26

Earlier quoted context omitted.

I sometimes get these almost angry emails about Gensim, my open source library. How come I'm not responding faster, merging PRs, fixing issues? For this critical popular project??! Meanwhile, sponsorships are at 13% of the (not terribly ambitious) goal of $6k/month [0]. Yeah, that's why. [0] https://github.com/sponsors/piskvorky

Do you ever respond to these emails telling them that they can hire you to attend to their issue? If my business depended heavily on an open-source component that needed a bug fix, more often than not I would pay the person to spend their time to resolve it. Often it is easier to get a business to pay a consulting fee for a specific thing rather than make a donation that goes into a general funding pool for a project…

Yes, I do. But it turns out that their issue is pretty much always only tangentially related to Gensim (or any other open source library / technology). They're solving a business problem. That's what brings them money, with which they pay me, and I acknowledge that.

This leaves me with two choices:

1. Help narrowly, with the Gensim part only. Pros: easy for me. Cons: doesn't truly help the customer; feels dirty.

2. Help solve their actual business problem. Even if it means not using ML at all (a very common outcome), or suggesting a different architecture.

In my experience, most companies are so lost as to what to expect from ML, or how to get there, that I didn't feel comfortable with the "narrow" help. Lipstick on a pig.

So I went the full consulting route for a few years. But that felt too draining so I dropped it and created a product instead.

Re: Django 4.0

#109

Post by stavros »

matsemann wrote: post #56
rlawson wrote: post #45

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…

Yes, but nothing is stopping you from typing and organizing everything, right? I agree that it's not the default, which isn't ideal, but you can do it fairly easily (and keep it enforced).

Re: Django 4.0

#110

Post by theptip »

matsemann wrote: post #56
rlawson wrote: post #45

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…

Strongly agreed on these pain points. One tool I have been using recently to help is django-seal, which locks the QuerySet so you can’t run extra queries. This should really be part of the ORM, fail-unsafe is a bad option for performance critical code.

Combined with the Repository pattern from DDD, you can have all your model fetches go through a separate class that does the necessary select-/prefetch-related calls, then seals. (Or just override your model's Manager to do this).

And we have a coding standard guideline to discourage using queryset operators in business logic, as you note it breaks encapsulation and makes your code really hard to refactor later. This is hard to enforce though…

I think Django’s ORM is if anything too convenient - it’s great for the first 100kloc but then as you say, you need to overlay some discipline to prevent things from blowing up, and the framework is all about removing friction which makes this hard.

Post reply on HN