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

171–180 of 226 posts

Re: Django 4.0

#171

Post by mlboss »

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?

Digital ocean also offers managed db(postgres/mysql) starting at $15/month

Re: Django 4.0

#172

Post by mateo411 »

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…

This seems like an architecture issue, rather than a framework issue. At some point you need to split these 400K and 40 devs out into different applications. Different application should not be able to access each other's database, but rather communicate through an API.

I'm not saying that you need micro services, but you should find a way to split this up into a few applications with well defined interfaces between the applications.

Re: Django 4.0

#174

Post by I_complete_me »

matsemann wrote: post #66
nisegami wrote: post #55

Earlier quoted context omitted.

>avoid fat models, use a service layer I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

Another classic is "c string".

As a construction engineer, content with the word "erection" is very common but not very easy to get by the filters.

Re: Django 4.0

#175

Post by pistolpeteDK »

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…

I agree. What we've been doing is - based on advice from somewhere I can't remember - is to always make things easy to remove. So whenever a new app/module/service is added - the "author" has to think about making said thing easy to remove. The result is that new apps/modules/services must have very few connections with the other parts of the code. It does result in a fair amount of "get__settings" on the base classes, but the result is a lot less spaghetti. The thing is, we rarely remove stuff later on - but when we do, it's often only a few methods that needs to be altered in order to disconnect a specific part of the system.

Re: Django 4.0

#176

Post by number6 »

ralmidani wrote: post #117

Django made me fall in love with programming. I built 2 decent-sized side projects with Django. They didn’t gain traction, but I loved using the framework. Then I went through a couple of (depressing) years of using Java/Spring professionally, and recently I made the choice to move to Elixir/Phoenix. It’s going great, and I don’t think I would go back to heavy OOP if I didn’t have to. Some things I really miss from D…

> Making it more clear when you’re going to hit the database (explicit is better than implicit).

You might like https://github.com/dabapps/django-zen-queries

Gives you fine grain control about database queries

Re: Django 4.0

#177

Post by aej »

marcus_cemes wrote: post #92

Does anyone know how Python/Django compares to something like Elixir/Phoenix?

Phoenix has a much smaller footprint than Django. I would put Phoenix closer to Flask in terms of how much work the framework does for you. Phoenix has lots of generators which make hooking into the database layer very easy and bootstrapping new endpoints is also fast in Phoenix. Django makes more decisions for you (authentication, permissions, admin, the ORM to name a few).

In the Phoenix ecosystem you bring each of those pieces in as you please (auth generator, Ecto + other libraries etc). So I would say if your really want to move fast, you will still get further, faster with Django - but the trade-off (as other posts here have alluded to) is that once you need to implement custom features or optimisations you will often fight against Django (or need to wade-through half a dozen classes in some inheritance tree to find the right hook).

Another big difference between Phoenix and Django is that building websocket services in Phoenix is an absolute breeze. The Elixir runtime maps perfectly onto any type of messaging service.

Re: Django 4.0

#178

Post by leephillips »

matsemann wrote: post #66
nisegami wrote: post #55

Earlier quoted context omitted.

>avoid fat models, use a service layer I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

Another classic is "c string".

I learned something new today. And not about strings in C.

Re: Django 4.0

#179

Post by rlawson »

akulbe wrote: post #161
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…

The one that you sold… what made you decide to sell, if it was a money maker for you?

Basically I didn't want to support it. It was a lot of schools and small businesses and so plenty of "I can't login" and when you work with them it's their wifi or something. The company I sold it too had customer support :)

Re: Django 4.0

#180

Post by midrus »

_xnmw wrote: post #160

Anyone have deep experience with both Django and Laravel and can offer a comparison of the two?

I have a lots of experience with Django, and a few months experience with Laravel. I think Django is good at pure backend solutions. When you're not doing the frontend in Django itself but instead doing a separate SPA. Also the admin is a great tool as an internal CMS. Django rest framework is awesome too.

Laravel is a real "full stack" framework, it has a very powerful templating system (one of the best I've seen!) where you can do components instead of just includes. It has a powerful assets bundling pipeline, great integration with alpine, Vue, inertia and the super awesome livewire.

Laravel documentation is TOP.

As I'm not a fan of the SPA approach and still like frontend and building applications, I much prefer Laravel nowadays.

Post reply on HN