[HN Gopher] Django 4.0
___________________________________________________________________
Django 4.0
Author : Spiritus
Score : 414 points
Date : 2021-12-07 09:53 UTC (13 hours ago)
(HTM) web link (www.djangoproject.com)
(TXT) w3m dump (www.djangoproject.com)
| igammarays wrote:
| Anyone have deep experience with both Django and Laravel and can
| offer a comparison of the two?
| midrus wrote:
| 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.
| clement_b wrote:
| I enjoy coding with Django. It's _the_ framework that helped me
| make a smooth move from PHP /Symfony to Python-powered web apps.
| Not that I dislike PHP... just wanted to focus more on Python.
|
| Many thanks to everyone involved in the project!
| _tardigrade wrote:
| nowadays most people use Django to create REST API. I wish Django
| would merge DRF into its codebase.
| dralley wrote:
| At this point I disagree - DRF is a verbose and somewhat dated
| architecture. I wish they would provide something like Django
| Ninja / FastAPI.
|
| Plus it already has decent async support.
|
| https://github.com/vitalik/django-ninja
| mrweasel wrote:
| > nowadays most people use Django to create REST API
|
| I doubt that's true, but yes, having DRF merged in would be
| rather nice.
| PhoenixReborn wrote:
| There are quite a lot of apps that do a JS frontend and
| Django backend these days, I myself have done quite a few.
| mrweasel wrote:
| Absolutely, I just question the premise that "most" Django
| applications are like that.
|
| My best guess, and I have nothing but my own experience to
| back this up, is that for every public facing Django based
| website, there are at least three used internally and at
| least one of those use nothing but the build in admin
| interface as a UI.
| appliku wrote:
| Thank you Django. that's a great news.
|
| 14 years ago someone helped me discover Python and Django.
|
| I started from django official tutorial and never changed the
| framework of choice.
|
| It was my hobby, my career, my tool to put the food on the table.
|
| 12 years later I have started building a way to solve deployment
| question.
|
| started from bunch of scritps. today I have made cost effective
| tool to deploy Django projects and pretty much any python app on
| AWS/Digital Ocean
|
| https://appliku.com/
|
| it is like heroku but uses you own cloud account and not
| expensive at all.
| buro9 wrote:
| Maybe this will be the moment I upgrade.
|
| Let's see what version I'm running: Django 1.5.9
|
| This is going to be very painful isn't it. I wonder how long
| until the bitrot makes it unbuildable and undeployable.
|
| I should clarify, there is no database attached to this and it
| talks to a secure API that is maintained really well. So this is
| just views and templates, where the views talk to the API.
| unixhero wrote:
| Where are we on the whole Django versus Rails debate?
|
| (Not cannonfodder, I am genuinely curious)
| z3ugma wrote:
| As someone who's used both - Rails packaging and environment
| maintenance has been so much less of a headache. Gems and
| Gemfiles and Gemfile.lock vs having to choose a Python package
| maintainer (Pipenv vs Poetry?) and deal with that has been
| worth it to me.
|
| In terms of how they "feel" to develop with? About the same.
| Similar ideals - skinny models, service layers, REST-first but
| you can make it RPC-style if you want...
| barrenko wrote:
| As someone who knows some Python, and "gets" Django / Flask
| basics, what would my timeline look like for switch to Ruby /
| Rails?
|
| Thanks.
| Toutouxc wrote:
| One day of learning the slightly more interesting Ruby
| syntax, one day of learning how each thing is called in the
| other framework, and then a few weeks until your code in
| Ruby stops looking like Python (i.e. you start using the
| fancy Ruby stuff).
| barrenko wrote:
| Appreciate it!
| rowanseymour wrote:
| I think that was a fair criticism a year ago, and it's hard
| to believe it took this long to get a sane dependency
| management system, but now the answer is use poetry every
| time.
| tfehring wrote:
| I can't recommend using Poetry in production - I've had
| massive headaches with it due to https://github.com/python-
| poetry/poetry/issues/697
|
| Basically if you have two dependencies that depend on the
| same package, but depend on different versions or non-
| overlapping ranges of versions, Poetry's only solution is
| "tell the maintainers of your dependencies to update their
| pyproject.toml" - building your package will just fail,
| with no workaround other than to fork the dependencies and
| update pyproject.toml yourself. Yes, in principle that
| sounds like the right way to resolve it, but in practice
| there are lots of Python packages with overly narrow
| dependency version ranges (or that are pinned to a single
| version), the maintainers understandably aren't always that
| responsive, and forking all your dependencies isn't a great
| solution.
| hairofadog wrote:
| A couple of comments here have talked about the benefits of
| "skinny models", but that runs counter to the advice I've
| seen. How come skinny models? Is the idea to put most of the
| business logic... where?
| raihansaputra wrote:
| Some recommends Service layers, but not the total extreme
| extent that the service layer is flexible/transferable
| between frameworks/databases.
|
| https://alexkrupp.typepad.com/sensemaking/2021/06/django-
| for...
|
| https://news.ycombinator.com/item?id=27605052
| [deleted]
| Toutouxc wrote:
| IMO service objects are an OOP-cargo-cult abomination,
| especially the kind named after a verb with a "call" method
| (CreateFooFromBar#call), so the first thing I reach for to
| offload my business logic involving multiple models or just
| lots of logic are PORO domain objects with meaningful non-
| generic method names (a CampaignReservation with
| "#create!", "#persisted?" or "#available?" methods, a
| XlsxClientImport with "#perform" or "#check_format"
| methods).
| samwillis wrote:
| I'm unconvinced by the "skinny models" and "service layer"
| arguments. Django's ORM is an active record style ORM, its
| at its best if you use it that way. If you want to have a
| service layer type architecture, use SqlAlchemy with
| implements the data mapper scheme.
|
| I follow this general rule of thumb, in order:
|
| If it's a complicated business logic touching multiple
| models or external apis, put in in a `utils` module
| (keeping this sensibly organised by model/role/activity
| depending on what you are building, i.e.
| utils.{model_name}.{methods} or utils.{e.g.
| order_processing/email/accounts}.{methods}). You can add a
| shortcut to it as a method on the model if this makes
| sence. (some may argue this is a service layer)
|
| If I'm only doing something once in one place (in one
| view), then keep the logic there.
|
| If it's a custom create method, stick it on the models
| manager class.
|
| If it's something you want to do to a set of objects (from
| a query set), put it on the manager class or a QuerySet
| subclass (to make it chain-able).
|
| If you haven't put it elsewhere put it on the model class,
| as a method or a property if it seems cleaner (don't do
| get_... and set_... use a property)
| regularfry wrote:
| The argument is that Active Record is itself a bad
| pattern that you should not use. And it may be. But it
| might be a long way down the runway before you run into
| the bad effects.
| samwillis wrote:
| Yes, exactly, I agree there are valid arguments against
| active record, partially at scale. However, I believe,
| certainly when starting out on a new project/startup,
| sticking with the standard recommendations and patterns
| provided in the docs for Django and DRF you make life
| much easer for on boarding new people to the project
| later on - they will have seen it all before.
|
| If you get big enough where the standard patterns don't
| work anymore, YAY! you got big, celebrate! Then start
| looking at how to refactor for easer maintainability for
| your specific use case and scale.
| WD-42 wrote:
| If your application doesn't have to do anything other than
| basic webapp stuff, then Rails probably has you covered.
|
| If you need anything related to ML or the sciences, go Python.
| theptip wrote:
| If you are starting a business, use whatever language you
| already know. The benefits of one framework vs. the other are a
| rounding error compared to language fluency. (They are both
| great, in other words.)
|
| If you are learning both language and framework from scratch,
| check the local job market. 5 years ago in the Bay Area there
| were roughly 2x as many Rails job postings as Django, though I
| doubt it is this lopsided now. Also Python is used more broadly
| than Ruby, eg for ML and scientific/numeric work.
| tomduncalf wrote:
| I recently built a fairly simple backend with a GraphQL API
| (fairly basic but bespoke e-commerce functionality, a few
| related models and a few queries/mutations) using Django, and
| then rewrote it in Rails, as a newcomer to them both (I knew
| bits of both languages but nothing really of the frameworks).
|
| The reason I switched is more or less entirely that I hit
| performance issues with the Python Graphene library being
| really slow at returning larger datasets, and couldn't find a
| solution in a reasonable time frame.
|
| My impression was that Django has a much more powerful and
| pleasant ORM - your migrations are derived from your models, so
| if you want to add or remove a field (for example), you update
| the model class then the migration command works out what it
| needs to do to make the database match the models. Rails works
| pretty much the other way - you create explicit migrations to
| add/remove columns, and the database is the source of truth -
| your model classes don't even have explicit accessors in the
| code for the fields you define in the DB. I found the Django
| way more logical, and I found things like many-to-many
| relationships much easier in Django, but the Rails way isn't
| too bad once you get used to it.
|
| Rails is well known for being heavy on the "magic", which is
| quite expressive once you get used to it but I find it hard to
| know where to look if I want to e.g. know what methods a model
| has, whereas Django felt a bit more explicit in this regard.
| Personally, I find Python a more pleasant and easier to read
| language than Ruby, which has so many ways to express the same
| concept in different ways, but I am actually warming to Ruby.
|
| If you're interested in adding type checking, it seemed that
| Python has better and more mature options here.
|
| Ultimately though, for what I wanted (which was to build a
| backend with sensible defaults out of the box and really write
| as little code as possible), I think Rails is a better fit. The
| ecosystem of libraries seems more mature and better documented
| (I hit quite a few issues with Django related libraries which
| took a lot of Googling and some hacks to solve). The Ruby
| GraphQL library is much nicer to work with and much more
| performant.
|
| The amount of code I have to write is generally pleasingly low
| (though I'll admit it's quite spaghettish already, I have been
| learning Ruby as I go and I can totally see how a large
| codebase could become a mess), and it's easy to Google for most
| stuff, and the defaults seem pretty sane. I will say on a
| slight tangent that I recently enabled GitHub Copilot, and am
| finding it surprisingly quite useful in a Ruby project, where I
| often struggle to know/remember the right syntax!
|
| So... that's my experience. Ultimately it came down to a niche-
| ish requirement (performant GraphQL API) to force my hand, but
| I think I'm pleased with the end result. Both are impressive
| frameworks and I don't think generally you could go too far
| wrong, but for me Rails just feels that bit easier and more
| mature for bashing out a solo project.
| bodge5000 wrote:
| I'm biased because out of the two I've only used Django,
| however since learning Django my urge to learn Rails has gone
| down quite a bit. Its still there, and Rails does look
| fantastic, but so does the hundred other frameworks and
| languages on my todo list.
|
| I guess the only takeaway you can get for that is that Django,
| at the very least, works fine, and probably will solve the
| problem you come in with unless you want it solved in a very
| specific way
| alberth wrote:
| Off topic: I wish NIM had a Django-like web framework.
| marcus_cemes wrote:
| Does anyone know how Python/Django compares to something like
| Elixir/Phoenix?
| Daishiman wrote:
| Django has more features, a _much_ larger ecosystem, excellent
| documentation.
|
| Elixir is dramatically more performant and will scale better. A
| lot of people enjoy Elixir more or find it conceptually more
| interesting than Python.
|
| IMO the number of packages and facilities provided by Django
| will outweigh Phoenix's performance for 95% of users.
| dyeje wrote:
| Django, Rails, Phoenix, Laravel, etc are all pretty similar at
| a high level.
| princevegeta89 wrote:
| Phoenix is on a much better performance level compared to the
| other two.
| aej wrote:
| 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.
| b-lee wrote:
| Great to see they have managed to reach their funding target.
| Donated anyway!
| ralmidani wrote:
| 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 Django:
|
| - Models with more centralized validation logic. In Phoenix (and
| somewhat similarly in Rails), you need to edit your migration,
| schema, and changeset. In Django, you edit your model and the
| migration can usually be made automatically with no need for a
| 3rd-party package.
|
| - Django REST Framework. You can get pretty far with an app just
| by leveraging ModelSerializers and ModelViewsets. It's
| ridiculously elegant, simple, and powerful.
|
| - The Admin layer is fantastic and unparalleled.
|
| Some things I wish Django would add/enhance:
|
| - Making it more clear when you're going to hit the database
| (explicit is better than implicit).
|
| - True async up and down the stack. Not a small task within the
| Python ecosystem, but I think for folks who are not already
| invested, looking at Elixir/OTP/Phoenix is too tempting. If you
| don't have kids to transport with you, a Lambo looks much more
| fun than an S-Class Sedan.
| WD-42 wrote:
| > - True async up and down the stack. Not a small task within
| the Python ecosystem, but I think for folks who are not already
| invested, looking at Elixir/OTP/Phoenix is too tempting. If you
| don't have kids to transport with you, a Lambo looks much more
| fun than an S-Class Sedan.
|
| This has been in the works for a few years. Everything in
| Django works with async except the ORM at this point. Which in
| practice, means it's not really async. But hopefully they are
| getting close.
| privacyonsec wrote:
| I'm working on bringing async to Django orm:
| https://github.com/rednaks/django-async-orm
| number6 wrote:
| > 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
| naveen_ wrote:
| Thanks a lot..
| rlawson wrote:
| 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 access to the ORM (avoid fat models, use a service
| layer)
|
| - responsive bootstrap template with crispy forms
|
| - minimal js
|
| - 12 factor type setup - django-environ or similar
|
| - be aware of n+1 select problem (I use django debug toolbar but
| looking into django-zen-queries)
|
| - plop it on heroku, AWS lightsail, Digital Ocean or if
| containerizing use AWS Fargate
|
| - avoid celery unless you are at a scale you need it - use
| django-cron, django-db-queue or similar
|
| - use a managed database and managed email service
|
| I have had zero scalability problems. People say Django is slow
| but it handled 10k active users on a small EC2 instance without
| any issues (static stuff served via cloudfront)
| zdiscov wrote:
| Did you ever have to use Vue or other reactive frameworks with
| Django? Do you use DRF at all or just mostly Django?
| rlawson wrote:
| Plain Django with html templates and some htmx/unpoly for
| fanciness
| uranusjr wrote:
| Hotwire works very well too.
| bencollier49 wrote:
| May I ask what the projects were?
| rlawson wrote:
| Car reservation system for auto dealers (never got traction)
|
| Covid screening application (sold)
|
| Inventory management (initial clients in alcohol beverage
| bottling/distribution)
| raihansaputra wrote:
| Do you have any recommended readings/resources to help with
| data modelling? Especially regarding reservation/scheduling
| and inventory management?
| rlawson wrote:
| 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.
|
| Inventory management is surprisingly complicated to do in
| a generic way.
| raihansaputra wrote:
| Thanks for the pointers! Yeah generalizing inventory
| management is very confusing. I tried looking into Oodo
| but can't get my head around the data modeling. It feels
| like trying to implement double-entry accounting, but the
| money can rot/be broken/gone for other reasons.
| tcrow wrote:
| Congrats on making a return on your investment! may I ask
| how you went about locating a buyer for the screener app?
| rlawson wrote:
| Asked one of the local investors and got steered to
| another company that was in the same business altho much
| bigger. Really just plain luck and I guess having a
| decent network.
| ehutch79 wrote:
| 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
| lifeisstillgood wrote:
| please point us at your side projects - and congratulations
| that's a fantastic outcome
| akulbe wrote:
| The one that you sold... what made you decide to sell, if it
| was a money maker for you?
| rlawson wrote:
| 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 :)
| Alex3917 wrote:
| > 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 that makes it easier
| to visually differentiate which code goes to which method. You
| don't need to know anything about classes in Python in order to
| use them.
|
| It's not at all difficult to switch from FBVs to CBVs later,
| and most people (myself included) use FBVs when getting
| started. But I'd also say that if you're willing to push
| through the initial discomfort and spend the extra half hour or
| whatever on YouTube in order to understand them, then you do
| get a little bit of a nicer overall development experience.
| neilfrndes wrote:
| Alex has written an excellent blog about Django best
| practices for startups. It contains wonderful insights about
| how you should structure code and why you should structure it
| that way. It has helped us a ton!
| https://news.ycombinator.com/item?id=27605052
| squeaky-clean wrote:
| I usually have a FBV handler (foo_handler) that just passes
| along all the required parameters to foo_get, foo_post, etc,
| and then takes the return value of those and wraps it in a
| HttpResponse/JsonResponse.
|
| That way my actual view logic doesn't have to deal with
| anything http, and it makes testing them way simpler.
| bitexploder wrote:
| 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.
| Nextgrid wrote:
| My recommendation for learning class-based views is to use
| a good editor or IDE that allows you to drill down into the
| library code easily. In PyCharm/IntelliJ I can just
| command-click on the TemplateView symbol and see its
| implementation, and do so recursively until I've unraveled
| the entire thing.
| ChipotleRice wrote:
| Agreed. Django's documentation is pretty light on the
| order in which certain functions will be executed and
| diving into the code is the only way I've been able to
| understand what happens when handling forms and views.
| deckiedan wrote:
| http://ccbv.co.uk/ is a pretty useful resource for
| learning class based views...
| nisegami wrote:
| >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.
| atum47 wrote:
| I laughed
| matsemann wrote:
| Another classic is "c string".
| I_complete_me wrote:
| As a construction engineer, content with the word
| "erection" is very common but not very easy to get by the
| filters.
| bobbyi wrote:
| When I first started using the python tool/ library named
| fabric, I knew that putting just "fabric" into google would
| not get me what I wanted, so I instead searched for "python
| fabric". The top results were trying to sell me handbags
| and boots.
|
| (These days, the library does rank first for "python
| fabric").
| tda wrote:
| I recall a colleague googling Prince Albert in front of his
| boss whilst discussing a potential project in Monaco. That
| was before either before safe search was a thing or he had
| it switched off.
| _peeley wrote:
| Every time I need to write up a research paper in TeX and
| insert a graph, I make the same mistake of searching "latex
| images" and getting some pretty exotic results
| nojs wrote:
| I remember studying fork/exec at uni and having some
| awkward queries involving "fork", "kill" and "child".
| BeFlatXIII wrote:
| I just got results for repairing cellos and violas. "G
| string" got the expected spicy content in addition to
| violin repair ads. Surprisingly, no string bass repairs (in
| spite of the bass also having a g-string)
| skinkestek wrote:
| Another classic was (I haven't tested recently) that while
| Firefox would search if you entered a word that was not an
| address into the adress bar, while certain older browsers,
| at least Safari just added .com
|
| :-/
| slig wrote:
| I remember that, specifically Python dot com. (was NSFW
| back in the day, enter at your own risk).
| leephillips wrote:
| I learned something new today. And not about strings in C.
| felipeccastro wrote:
| "mongoose relationships" is not always what you would
| expect, either.
| unfunco wrote:
| I think the idiom was: Fat models, skinny controllers. That
| might return better results.
| matsemann wrote:
| 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 typing
| nothing stops that from exploding runtime when someone changes
| a model somewhere. Too easy to send fat objects around
| everywhere, accidentally doing heavy db stuff when using a
| property. Also makes it harder to test, because everything
| leaks.
| stavros wrote:
| 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).
| matsemann wrote:
| Problem is that the typing with mypy is in general not a
| very strong guarantee in Python, and combined with Django
| most of it's almost useless. Sooo many kwargs doing magic
| stuff, or types being lost after being through some django
| functions.
|
| And hard to do the organization propably in django, doing
| it breaks much of the benefits of the orm for instance.
| People will do what's convenient, and in Django that's
| writing unmaintainable code.
| pistolpeteDK wrote:
| 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_<app>_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.
| pmontra wrote:
| > one ends up with each app spaghettied with other apps
|
| 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.
| mateo411 wrote:
| 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.
| theptip wrote:
| 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.
| rlawson wrote:
| I can see that happening on a large codebase with a lot of
| devs. Being a Java guy, I organized all the business logic
| and db access into a service layer, added type info and wrote
| a decent amount of unit tests. I can't deny however that I am
| 2x faster cranking out crud screens in Django than in Java
| and the combination of ORM, migrations, templates, and access
| to the 3rd party app ecosystem is a real productivity
| booster.
| matsemann wrote:
| Yeah, for a simple app, it's so quick to get some auth,
| rest endpoints, a fine admin panel etc.
|
| Problem is when you start abusing stuff. Just hook into
| some signal to do something, nbd, but suddenly it's an
| interconnected mess. Just add some custom stuff to the
| admin page, and suddenly what should have been a custom
| made page is now a weird mess it's hard to extend. Need to
| do stuff async in the background, and what could have been
| adding a task on some queue and having a thread poll it is
| instead this behemoth of complexity.
|
| A large django app can also be good, I think, but then one
| at some part have to realize when to stop tweaking built in
| django features and write custom stuff, to avoid adding
| hacks on top of hacks. And also early stop doing the easy
| communication between apps, instead take the annoying
| detour around services and hard boundaries.
| WD-42 wrote:
| 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.
| leetrout wrote:
| They are alive and well when using Django Rest Framework
| karolsputo wrote:
| I recommend this post when thinking about fat models/service
| layers
|
| https://www.b-list.org/weblog/2020/mar/16/no-service/
| anoojb wrote:
| 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?
| robjan wrote:
| 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.
| mlboss wrote:
| Digital ocean also offers managed db(postgres/mysql) starting
| at $15/month
| rlawson wrote:
| RDS - Aurora/Postgres flavor - small instance. Entire AWS
| bill was < $100/month to support 10k users - app load
| balancer
|
| - WAF rules
|
| - EC2 instance
|
| - RDS
|
| - Cloudfront
|
| I use fargate when deploying now to get out of box management
| int0x2e wrote:
| 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.
| kaba0 wrote:
| I'm sorry but I don't buy that. Spring Boot is very highly
| productive -- I really don't believe any other stack would fare
| better by a significant margin.
| rlawson wrote:
| Fair enough, I'm just a datapoint of one. YMMV
| Daishiman wrote:
| You have to type and read a lot more code in Spring to get
| equivalent functionality.
|
| Also, and it's hard to believe, but Spring has substantially
| more magic than Django.
| strzibny wrote:
| Congrats the team on the release.
|
| Now I have to go and check what to update for Deployment from
| Scratch :D
| midrus wrote:
| I've used Django for a long, long time (since 0.96). Django is
| great for backend stuff, but nowadays for full stack applications
| (if you're not doing an SPA) I find Laravel and Rails a lot
| better. In particular Laravel's templates (blade) and asset
| handling is awesome.
| Majestic121 wrote:
| We went all in on FastAPI with my team, but we're hit the issue
| that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to
| be turning pretty much unmaintained :
| https://github.com/tiangolo/fastapi/discussions/3970
|
| We've already been hit by multiple bugs with fixing PR opened,
| but left to rot, and missing documentation : the 'tutorial'
| documentation is great, but if you want a reference you have to
| go read the code.
|
| I guess that's the issue when you pick projects maintained by one
| person, so for my next projects I might get back to something
| built on stronger grounds, like Django.
|
| How is Django this day with modern Python constructs like typing
| in general and Pydantic models integration ?
| windexh8er wrote:
| 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).
| clepto wrote:
| 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
| processing. FastAPI provides a really lightweight interface
| to gluing pieces like this together.
| Nextgrid wrote:
| > 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?
| fernandotakai wrote:
| that's how i feel about all these python "micro
| frameworks".
|
| you start simple, but then you realize you need some kind
| of db access, some kind of caching, some kind of
| authentication, maybe some admin interfaces.... aaand you
| re-implemented django yet again.
| Nextgrid wrote:
| Exactly the reason why I don't care about either FastAPI
| or Flask. In my experience you'll always need more than
| what it comes with out of the box and you'll end up
| building your own (crappy) Django.
| clepto wrote:
| There wasn't really an aversion to or direct decision to
| not use Django, it just kind of naturally evolved. We
| were experimenting with FastAPI in some mock APIs used
| for test suites and some different projects and decided
| to incorporate it into a larger project.
|
| 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".
| aniforprez wrote:
| I would say Flask is genuinely really difficult to use. It's
| very easy to start with but the moment your project becomes
| non-trivial, it's a mess of wires and plugs that resembles
| something like Django anyways but all maintained by you or
| your team. FastAPI seemed like something that's in a solid
| middle ground between something beefy like Django but
| something light like Flask and it's much easier to start with
| since it gives you REST and form/JSON validation out of the
| box
|
| That said, FastAPI seems to have a lot of issues and the
| maintainer doesn't seem to be responding to the numerous PRs
| that are piling up. I'd much rather just stick with Django at
| this point
| WD-42 wrote:
| Check out Django Ninja: https://django-ninja.rest-
| framework.com/
|
| It's like a FastAPI inspired Django Rest Framework. In
| comparison to DRF it feels very lightweight and modern, but
| it's still Django underneath so you get to keep the ORM,
| admin, etc.
|
| Speaking of the ORM, once Django's is async Ninja will
| really be amazing.
| privacyonsec wrote:
| If you wanna experiment Django async you can try this
| module : https://github.com/rednaks/django-async-orm
| nickjj wrote:
| > I would say Flask is genuinely really difficult to use.
| It's very easy to start with but the moment your project
| becomes non-trivial
|
| Do you have specific examples?
|
| I've built a number of decently large Flask apps over the
| years (dozens of blueprints, 100+ models, etc.) and it was
| never an issue. I've used similar code organizational
| patterns in both small and large apps and it worked great.
| It was a combination of solo projects and working with
| small teams.
| WD-42 wrote:
| I share OP's general statement. I've been using Flask and
| Django on and off for near a decade.
|
| When deciding between Flask and Django, I look at the
| following requirements:
|
| User accounts
|
| Object Relational Manager
|
| Database Migrations
|
| User registration/social authentication
|
| Admin Site
|
| As a general rule of thumb if my project is going to need
| 3 or more of these things I just go with Django.
|
| You CAN do all of that with Flask, but you end up wiring
| together a bunch of third party dependencies just to end
| up with what Django would have provided you out of the
| box.
| zippergz wrote:
| FastAPI doesn't (directly) help with most of these
| either, so that's really a Flask vs. Django comparison
| rather than Flask vs. FastAPI.
| abdusco wrote:
| I share your thoughts on Typer[0]. It's a super cool project,
| but lacking proper hooking points to interact with the
| `click`[1] lib underneath [2], I am not sure if it would be the
| best decision to use Typer when we're rewriting our CLI.
|
| [0]: https://github.com/tiangolo/typer/
|
| [1]: https://click.palletsprojects.com/
|
| [2]: https://github.com/tiangolo/typer/issues/77
| squaresmile wrote:
| I'm thinking about using Starlette directly. It doesn't look
| that much more verbose than FastAPI and I already disagreed and
| bypassed a few FastAPI features. I wonder how much work would
| it take to hook the Pydantic models with their SchemaGenerator.
| Nextgrid wrote:
| > typing
|
| I believe there's a third-party package "django-stubs" that
| provides type hints for Django code. For your own code, it's
| just Python in the end so you can type-hint it as you normally
| would.
|
| > Pydantic models integration
|
| There isn't as far as I know. Django has its own model layer
| however unlike Pydantic, Django's is purely for the DB level,
| it's not there to (de?)serialize JSON.
|
| In the Django world you'd typically use Django Rest Framework
| serializers for that. Now you _can_ use Pydantic and it
| probably won 't be too much work to make them work with DRF,
| but whether it's worth it is a different matter - DRF gives you
| a lot of stuff for free such as auto-generating serializers
| based on DB models (including validation and everything) which
| you wouldn't get with Pydantic.
| nurbel wrote:
| There is https://django-ninja.rest-framework.com/ which would
| be an alternative for DRF ,heavily inspired by FastApi, that
| integrates with Pydantic.
| WD-42 wrote:
| Pydantic allows you to write super clean (in comparison to
| DRF) serializers using just type hints, as opposed to the
| declarative approach of DRF serializers. It's really nice and
| refreshing.
| holler wrote:
| Have you considered moving to Starlette a la carte? I use
| marshmallow for schemas and a few other minimal deps and it's
| been a breeze.
| rglullis wrote:
| Not to single you out, but are you or your business supporting
| the project (financially) in any way?
| Majestic121 wrote:
| I do with PR, and by strongly recommending the sponsored
| classes (from testdriven.io in the ads on the doc :
| https://fastapi.tiangolo.com/) for my company, but you're
| right that I could push harder for official corporate
| sponsorship.
| Radim wrote:
| 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
| dr_zoidberg wrote:
| > 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
|
| The answer would then be: "because I have to keep another
| job to pay the bills" then? Hope you can get to your goal
| ASAP. Going by stupidly quick math, you have 12k stars for
| gesim alone, and that boils down that if every star on
| github payed 50 cents you'd already be there. I know that
| starring doesn't mean anything other than "hey, this looks
| interesting!", but then again 50 cents is probably cheap
| enough for a majority of those "stars" that they wouldn't
| even notice.
|
| Also: thanks for creating and maintaining gensim!
| Sinidir wrote:
| Thanks for creating Gensim!
| legutierr wrote:
| 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.
| ldng wrote:
| But that triggers different accounting/taxes paths that
| can be problematic. Not everybody is a freelancer.
| Radim wrote:
| 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.
| leo_blask wrote:
| Gensim is fantastic. Just used it in tandem with FastText
| to get a machine learning app running for one of my
| clients. Thank you for it!
| nanna wrote:
| I must learn Django, it's got everything I'll ever need. No,
| Rails will make me happy and it's better for lonely devs like me.
| No I must learn a Modern Web Framework (TM) to prove I'm not
| stuck in the past. No way, I'm not a fashionista. Have you seen
| that Phoenix demo where the guy builds Twitter in like 4 minutes?
| That's the future. Hold on a minute, enough of this magic. I need
| to learn to build everything in Common Lisp and own my code 100%!
| Wait I don't actually have the time for that. Django is the way,
| it's so solid, just that it won't bring me joy....
| hellbannedguy wrote:
| Yea--I don't want to waste my life learning frameworks either.
|
| The less time googling a new framework, the better.
|
| Now learning Lisp is something else.
| Zababa wrote:
| There's also the part where you dig around to see what people
| use and recommand, and most of the answers are "use what you
| already know", which doesn't help when you don't know anything
| in detail. I feel like at this point the best strategy would be
| to list all the viables alternatives, pick one, and forbid
| yourself from using anything else for the next X months, but
| when thinking about that I have a huge fear of missing out.
| myth_drannon wrote:
| That's me. Once a year I get burned out from all the new
| languages and frameworks and decide to learn Common Lisp again
| for the 10the time.
| exdsq wrote:
| Hahahaha you've just described my life too
| [deleted]
| solididiot wrote:
| It's actually a bit worse (or better) depending on how you see
| it. You get to invest (time, energy) in what will land you a
| job. 99% it's not what you want/like and not what is
| technically best. IT's just what came to dominate your job
| market.
|
| At least if you're in a EU backwater country or in EU public
| sector-related projects. (Which usually means java/c# and to a
| much lesser extend a python tech stack).
|
| PS: Loved the rant but you forgot to mention Golang :). "You're
| doing web backend and not using Go?!!"
| Nextgrid wrote:
| This really depends whether you see IT as a job or as a tool
| to achieve your own projects. If the latter, then you don't
| particularly care how "hype" your tech stack is as long as it
| successfully solves your own problems.
| ac130kz wrote:
| Nah, Django makes you sad: async support is not full,
| migrations engine is pretty poor, not all database features are
| present, any kind of typing is hacky, very slow and so on
| geewee wrote:
| What other migration engine have you used that's better?
| Anything non-django I've used makes me wish I was using
| Django
| fb03 wrote:
| "alembic" is better by leaps and bounds. it is used within
| a SQLAlchemy system, which is also a superior ORM than
| Django's.
| louissan wrote:
| question of taste...
| robertlagrant wrote:
| Less taste and more that data mapper ORMs are better
| (although harder to make) than active record ones, except
| for very small datasets/simple queries.
| andybak wrote:
| "Better" for whom? It was a long time ago that I surveyed
| the ORM landscape but I remember thinking at the time I
| was much happier using an active record style ORM.
|
| I guess I'm saying I'm always suspicious when I see
| "better" with no qualification. Everything has tradeoffs.
| handrous wrote:
| I, for one, find data mapper simply baffling. I look at
| it and can't even comprehend why someone _might_ want to
| do things that way.
|
| Granted, I'm not fond of ORMs in general, but I at least
| understand the _appeal_ of the active record pattern.
| qeternity wrote:
| > migrations engine is pretty poor
|
| I find this to be an odd take. The Django migrations engine
| is probably its strongest feature.
| wiredfool wrote:
| 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.
| WD-42 wrote:
| If you write manual migrations, then it's often worth it
| to write the reverse function (in your case, deleting
| that group) so that you avoid this situation.
| wiredfool wrote:
| It's not the back and forth, it's that a migration in b
| that requires the post migrate step from a will fail if
| both migrations are run in one shot, (say, because you're
| bootstrapping a new dev or test db) but it will work when
| done incrementally (such as during development or
| deployment).
| ac130kz wrote:
| Any change you make has to be atomic, or it is unable to
| detect the change, and you have to rely on manual
| migrations.
| WD-42 wrote:
| What do you mean by this? Auto migrations detect changes
| in your models. I'm not sure what atomic means in this
| context.
| melling wrote:
| Yep, web solutions change too fast, with lots of legacy, and
| every solution is a compromise.
| agumonkey wrote:
| paradogm of choice
| mathnmusic wrote:
| You can experience all of this while staying in a single
| language ecosystem. Just recently, I had to build something in
| Javascript and got to know Express is no longer recommended.
| Fastify, Remix are the latest hotness. :)
| aneutron wrote:
| I genuienly have not heard about either one of the three. I
| guess I remain stuck in PHP, Phalcon Framework, Symfony and
| Django / Flask.
| jimnotgym wrote:
| I was checking out Express...how do I get user logins, oh
| just npm in 50 other projects, adding 50000 dependencies.
| Back to Django then!
| abdusco wrote:
| The difference between Django and Express.js is that one
| is a fully-fledged web application framework, while the
| other is a micro framework that just gives you a simple
| request -> response abstraction over `http.createServer`.
|
| I find Flask is more comparable to Express.js in that
| regard. Need auth? You need to:
|
| 1. Install a lib for persistence
|
| 2. Set up cookie sessions, or install another lib for JWT
|
| 3. Set up auth middleware
|
| 4. Prepare login/register/forgot pass views and flows
|
| which are almost the same steps you need to take in
| Express.js.
| shafyy wrote:
| Haha, that's exactly what I'm dealing with right now on
| the project I'm working. Add on top of that Firebase
| Cloud Functions. I really miss Rails.
| Waterluvian wrote:
| There are just so many makes and models of automobile and
| people get by. I remain so confused why choice paralysis is a
| thing in software.
|
| Maybe the libraries need to cost 30,000$ ;-)
| BeFlatXIII wrote:
| Different cars are much more obviously different than
| different web frameworks. When car shopping, you know whether
| you're looking for a RAM3500, an Odyssey, or a Mustang. Sure,
| the F-150 may win out in the end, but the Caravan and Charger
| were never contenders when looking for a truck.
|
| Choosing between software (especially bikeshedding between
| languages that both place priority on being pleasant to
| write) is often like comparing a Tacoma to a Tesla on the
| quality of seat heaters, upgrade price for the sunroof, and
| selection of factory paint options. Worse, you can't often
| have a clear understanding of the difference without
| investing the time to gain direct experience with each
| option. Otherwise, you're relying on community reputation and
| hoping it's both accurate and not horribly out of date.
| Kototama wrote:
| That would for sure push our community to better describe the
| runtime of the different solutions. We talked only about
| syntax, features, semantic but very little about the runtime
| characteristics of the different platforms (Java, .Net, BEAM,
| different Common Lisps implementation etc). Maybe it's a sign
| of abundance and that most of these solutions are ok in most
| of the cases.
| whatch wrote:
| Sometimes they cost you much more, if you chose the wrong one
| raihansaputra wrote:
| I've always followed Django as Python is my first language and
| still my 'natural' way to think about code. The more I look into
| it, the more I feel like the learning curve is a bit like a
| camel's back. Easy for some stuff. Hard to figure the middle part
| (usually because not understanding "how" Django really works).
| And easy at the ends after knowing how you can "mould" Django in
| certain ways. It feels like a great multitool for the
| professionals who need to create project after project.
|
| I believe the middle part of the learning curve can be easier,
| but with the "social cruft" of all the Django tutorials out
| there, it's a game of luck to encounter what's good and what are
| the different, sensible, approaches to handling growing/big
| Django apps.
|
| What can make this easier is a document/discussion of some sort
| that provides clear, complete, approaches. Here are some aspect
| that needs to be considered. I believe with the combinations
| defined, and describing the tradeoffs will be a very great start
| for any team/person looking to jump into Django, or improve their
| next project.
|
| - Postgres seems to be default. SQLite + Litestream is there but
| still bleeding edge.
|
| - Packaging is the hot topic, for sure. Pipenv, poetry, venv,
| etc?
|
| - Traditional Serverside Templating + JS enhancement
| (HTMX/Hotwire/etc), or JS based SPA (React, Vue, Angular, Svelte,
| etc)
|
| -- This also includes the asset compiling story (Tailwind JIT,
| Sass compilation, Babel/webpack/rollup/etc)
|
| - Fat models, Fat views, or Service layer? To which extent?
|
| - Single app (Doordash) or Multiple apps (Thread with >500 apps)?
|
| - What's the theoritical limit to using Postgres + Disk/Memory
| Caching (so no external Redis/ElasticSearch/other services
| needed)?
|
| -- Search, queues/async job, scheduled jobs, reports, emails, etc
|
| EDIT: A view additional points
|
| - Documented limits about using whitenoise to serve static
| assets, and when & how to move to S3. Also Cloudflare/CDN
| fronting
|
| - Cloud storage story (uploading to S3 api from FileField and
| Rich Text fields, and also async jobs)
|
| -- Proxy story to enable <a download> from cloud? (Maybe a bit
| far, but I think this is a common request)
|
| - Deploying/Serving optimization (is gunicorn the best option for
| now? how to scale w/ regard to vCPU counts to avoid the 25% CPU
| Max utilization?)
|
| - How to debug between inefficient query/app
| code/templating/serving/caching?
|
| I'm sure there are more points, but it would be great if there's
| a documented sensible approaches to evaluate. I know there are
| templates, but great discussions about the tradeoffs of complete
| "packages" are rare.
| polote wrote:
| 14 days ago https://news.ycombinator.com/item?id=29303611
|
| 76 days ago https://news.ycombinator.com/item?id=28609188
|
| 3 month ago https://news.ycombinator.com/item?id=28566044
| WayToDoor wrote:
| While it doesn't seem like a _major_ update at first glance on
| this news piece, the changelog is available here :
| https://docs.djangoproject.com/en/4.0/releases/4.0/
|
| Of note, in my opinion :
|
| - The new AddConstraintNotValid operation allows creating check
| constraints on PostgreSQL without verifying that all existing
| rows satisfy the new constraint, meaning that one can now create
| constraints on big postgres tables without a waiting period.
|
| - Async methods are coming, to cache for now but hopefully soon
| to the ORM. They are prefixed with a `a` in the name
|
| - DeleteView now uses FormMixin, allowing you to provide a Form
| subclass, with a checkbox for example, to confirm deletion. In
| addition, this allows DeleteView to function with
| django.contrib.messages.views.SuccessMessageMixin. This is a big
| thing if you use DeleteViews, as you can now easily show a
| message post-deletion to the user.
| fleetfox wrote:
| Do you know if the ORM solution have the same `a` suffix for
| async interface? I really hope there is more elegant solution
| for all this.
| cdrx wrote:
| ORM will use the same `a` suffix, yes.
| deckiedan wrote:
| Yes - it's kinda ugly at the moment, having all the `a`
| prefixed functions - but I _think_ it 's intended as a kind
| of long-term-intermediate step - since the whole of django
| isn't async at the moment, and needs to have separate
| versions for everything.
|
| I (wildly) speculate that once the ORM is async too, and all
| the rest of the bits fall into place (maybe django 5?), maybe
| django 6 will drop the `a` prefixes and integrate it all back
| together somehow?
| samwillis wrote:
| I believe they chose the 'a...' pattern as it matches other
| apis in the standard library - it also makes it explicit
| but concise.
|
| I can't see it being dropped any time the future, Django
| will always have a sync api, that won't be dropped. And
| there is no way in (current) python to combine a sync and
| async api into a single method.
| ilovefood wrote:
| Congratulations on the release!! I'm looking forward to give it a
| go and see what's new for myself.
| the__alchemist wrote:
| Django is the nicest framework I've come across! For some
| context, my favorite overall programming language is Rust.
| Despite Rust having several web frameworks, I use Python the
| server due to Django being so nice.
|
| In Python, there are micro frameworks like Flask, and whatever
| new ones claim to be "Blazingly fast!", async etc. Once you get
| over the learning curve, Django seems the nicest to use, due to
| including features like an auto-updating ORM, email,
| authentication, admin page etc. None of the Rust frameworks, in
| contrast, come close to feature parity.
|
| Django's feature base is vast, and I admit I don't understand
| much of it. You can choose the feature sets you need. The
| template language is inflexible, but you can smooth this over
| using JS instead A/R.
| [deleted]
| ehutch79 wrote:
| You can also replace the template system with something else
| like jinja2.
| peterth3 wrote:
| Congrats to the Django team! Adding support for a Redis cache
| instead of only memcached is awesome.
| theomega wrote:
| Great news!
|
| Just for reference: The latest release for Django Rest Framework
| is not compatible with Django 4.0 yet. At least my first attempts
| failed due to a missing `pytz` dependency. This is fixed in the
| `master` of DRF on Github. Installing `pytz` explicitly again to
| your project fixes DRF for now.
| mch82 wrote:
| The transitional USE_DEPRECATED_PYTZ setting might help.
|
| Saw this in the extended release notes:
|
| https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo...
|
| > The Python standard library's zoneinfo is now the default
| timezone implementation in Django.
|
| > This is the next step in the migration from using pytz to
| using zoneinfo. Django 3.2 allowed the use of non-pytz time
| zones. Django 4.0 makes zoneinfo the default implementation.
| Support for pytz is now deprecated and will be removed in
| Django 5.0.
|
| > ...
|
| > To give time for such an audit, the transitional
| USE_DEPRECATED_PYTZ setting allows continued use of pytz during
| the 4.x release cycle. This setting will be removed in Django
| 5.0.
| pantulis wrote:
| Before Django there was Zope in python-land.
|
| I don't think I overstate the relevance of what Django did by
| saying that Django almost single handledy advanced the state-of-
| the-art of web deployment in Python forward a decade.
| stdbrouw wrote:
| Zope hails from the era when Python was trying to appeal to
| programmers by showing that it, too, could be a Serious
| Enterprise Language. Everything had layer after layer of
| abstraction and the code looked more like Java than Python. The
| Zope ORM was kind of nice in its own weird way, though.
| VectorLock wrote:
| Zope had some things like the Language Is The Database trope
| that sort of remind of the things described in those Bank
| Python blog posts that have been floating around recently.
| kolanos wrote:
| Feels more like a Django 3.3 release than a 4.0 -- was expecting
| Django 4.0 to deliver the promised ORM async support.
| mypresences wrote:
| Agree, doesn't deserve the 4.0 tag.
|
| I was hoping for some progress on async ORM as well. Is there
| any word on when this is coming?
| robomartin wrote:
| Love Django, yet the transition from local development to
| deployment, in my opinion, continues to be just plain ugly and
| painful.
|
| I've written about this before. I think the stock Django dev
| configuration needs to change to something that is equivalent to
| a reasonable deployment on a common VPS, whatever that means. The
| development server is a nice trick, but the things you have to do
| to move to a real server are painful. Same with SQLite. Why not
| come up running PostgreSQL by default?
|
| I am sure there are varied opinions on this. All I have to say is
| that, over the years, I developed a document to help with
| deployment on standard hosting platforms, like Linode. It is
| staggering when compared to the experience of deploying something
| like a Wordpress/PHP site on the same or similar platform.
|
| This, from my perspective, is the weakness for Django, everything
| else I love and enjoy.
| strzibny wrote:
| What do you find hard in particular?
|
| systemd service + gunicorn is not that bad, I think. You can
| have simple deployment and graceful restarts[0].
|
| [0] https://nts.strzibny.name/gunicorn-graceful-restarts/
| reducesuffering wrote:
| There is a huge doc[0] for a standard "deploy decent prod
| setup to VPS." What happens after you make some changes,
| something goes wrong with the server, and you have to go
| through all these steps again, only that it gets you to Day
| 1, not Day 90? It leaves a lot to be desired for quick,
| reproducible deploys.
|
| Ime, adding a docker-compose and a couple Dokku commands on
| the server is the best experience I've seen so far.
|
| [0]https://www.digitalocean.com/community/tutorials/how-to-
| set-...
| Dowwie wrote:
| Is there a possibility of the cache stampede / dogpile problem?
| nickjj wrote:
| 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.
| slig wrote:
| 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.
| nickjj wrote:
| 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.
| slig wrote:
| Fantastic, thank you so much!
| avinassh wrote:
| I recently upgraded [0] one of my project [1] to Django v4, from
| Django v1. The changes from Django 3 to 4 were fairly simple,
| just one line change in my case. The change log is extremely
| detailed, it was easy to upgrade. Also, I found a tool called
| django-upgrade [2] which makes some changes automatically, rest I
| made manually.
|
| [0] - https://avi.im/blag/2021/rc-day-20/
|
| [1] - https://github.com/avinassh/della
|
| [2] - https://github.com/adamchainz/django-upgrade
| fernandotakai wrote:
| that's super nice to know -- i need to upgrade a django app
| from 1.11 to 4 over the next couple of weeks!
| spapas82 wrote:
| If the 1.11 project is in python 3 then it would be a piece
| of cake. If it's in python 2 then it will need a little more
| effort to convert to python 3 but but not much really. Django
| have hasn't changed that much since 1.11!
| sam_goody wrote:
| OT, but considering the audience...
|
| I have a side project / website that I want to work on. I have
| over a decade experience with PHP and JS in various forms, but am
| willing to try something new.
|
| The idea of compiled languages don't appeal to me, so am not
| really interested in Go, Rust or Dart. It looks like either
| Django, Elixir, or PHP - but am open to other ideas.
|
| Anyone with enough experience to tell me confidently that it is
| worth Django or Elixir? Anyone can give a five line overview of
| the differences vs PHP or Node?
|
| And along the way, am I the only one who is confused by what
| seems too many environments and package managers? (from
| venv/virtualenv[1] to pip/easy_install to wheels/eggs)
|
| [1]: https://stackoverflow.com/q/41573587/87520
| jph wrote:
| IMHO, Elixir & Phoenix are such a breath of fresh air, plus
| power, plus adaptability, and I love the functional
| capabilties. On the other hand, if your want lots of numeric
| computation tooling, AI/ML, stats, etc. then Python & Django
| have better/more math-adjancent integrations.
| bgdkbtv wrote:
| No difference, it is just a matter of preference and selecting
| the best tool for the job. Often times the best tool for the
| job is the one that you know how to use really well.
|
| If you're good with Laravel for example, no need to switch to
| Django or Elixir and vice versa. Stick with what you know and
| you'll be a happier developer.
| dukeofdoom wrote:
| I still have a project that runs on Django 1.6. Can't imagine
| trying to migrate now, when it relies on so many old packages.
| Would probably be better of starting from scratch.
| slig wrote:
| I had a project running on 1.3 until very recently. The was a
| lot of issues with the TZ datetime fields, migrations, Python2,
| etc. It was a lot easier to start a new project from scratch.
___________________________________________________________________
(page generated 2021-12-07 23:02 UTC)