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

Tips for Building High-Quality Django Apps at Scale

blog.doordash.com

Post reply on HN
Print view View original

101–110 of 125 posts

Re: Tips for Building High-Quality Django Apps at Scale

#101

Post by neves »

randomsearch wrote: post #2

I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse. This seems to me to be somewhat un…

I'm not affiliated with them, but you think seriously about Django, you should take a look at the book https://www.twoscoopspress.com/products/two-scoops-of-django...

I still have the 1.5 edition, but it helped me a lot. I'm think about upgrading. Do you recommend?

Re: Tips for Building High-Quality Django Apps at Scale

#102

Post by tschellenbach »

cwisecarver wrote: post #4

I've got more than 5 years of experience with Django on a number of teams and at a couple of companies and in my experience almost everything in this article is completely incorrect. The only things I would agree with is the point about project layout and avoiding django's squashmigrations for the truncate the migrations table, delete the migrations, and create a new initial migration. Practically everything else in…

Same thing here, no clue why people are upvoting this.

Re: Tips for Building High-Quality Django Apps at Scale

#103

Post by andy_ppp »

sly010 wrote: post #82
vosper wrote: post #77

Earlier quoted context omitted.

Is it actually possible to find and drop in apps like you suggest? And have it just work? Is a repository of various blog apps out there? What if one of them does something nasty to your database? It seems like it'd be easier to spin up a Wordpress instance...

> What if one of them does something nasty to your database? Same question is valid for Wordpress plugins.

Wordpress has already done nasty stuff to your database...

Re: Tips for Building High-Quality Django Apps at Scale

#104

Post by vosper »

arctangent wrote: post #81
vosper wrote: post #77

Earlier quoted context omitted.

Is it actually possible to find and drop in apps like you suggest? And have it just work? Is a repository of various blog apps out there? What if one of them does something nasty to your database? It seems like it'd be easier to spin up a Wordpress instance...

Yes, there's a whole universe of them. Here's a good place to start looking for things to help make development easier: https://djangopackages.org/

Thanks!

Re: Tips for Building High-Quality Django Apps at Scale

#105

Post by jwarren116 »

dangayle wrote: post #29
randomsearch wrote: post #2

I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse. This seems to me to be somewhat un…

Have you checkout out O'Reilly's Lightweight Django book? It basically goes through all of this, starting with a single file Django app.

+1 for Lightweight Django. I had the pleasure of working with one of the authors. The book is well laid out and covers some really great topics that aren't always covered well elsewhere in the context of Django (i.e. Websocket services with Django). It's a great companion for Two Scoops of Django.

Re: Tips for Building High-Quality Django Apps at Scale

#106

Post by zachsnow »

cwisecarver wrote: post #18
adamors wrote: post #6

Earlier quoted context omitted.

Can you expand on what do you think is incorrect in the post?

- FK/M2M across reusable, packaged apps is only bad if you don't match the interfaces correctly. See: almost every third-party Django app that is built to integrate with another application's models. - Sometimes you want the app concept just for organization. There's nothing bad about that and it makes sharing things inside of a project easier. - Explicitly naming your database tables doesn't make any sense. You're u…

Re: naming tables, older versions of Django require (not sure about the latest) you to name your app in each model (via Meta) if you've broken your models into several modules within an app; maybe they are trying to speak to that?

Re: Tips for Building High-Quality Django Apps at Scale

#107

Post by randomsearch »

soperj wrote: post #88
randomsearch wrote: post #56

Earlier quoted context omitted.

Sorry, misread that line. Point being, how many examples do you have where someone writing a Django site is going to reuse their own apps?

I reuse my own apps constantly, whenever I do new sites.

Excellent - could you give some examples of what you reuse?

I'm interested in whether this is a worthwhile abstraction in the general case, or whether for most people (like me and the post) it's an unhelpful complication.

Re: Tips for Building High-Quality Django Apps at Scale

#108

Post by photojosh »

avium wrote: post #65
tclancy wrote: post #10

Earlier quoted context omitted.

I've got 10 years' experience on projects small and large and I have to agree. The title talks about building at scale but the article doesn't stress that which makes some of the advice downright weird. >If you don't really understand the point of apps, ignore them and stick with a single app for your backend. You can still organize a growing codebase without using separate apps. This is where the article lost me. If…

I agree the doordash article gets some stuff right and most stuff wrong, almost to the point where it's difficult to read. But (somewhat tangentially) I admit I have struggled in the past with separating out Django apps for reasons not mentioned in the article. Specifically, say I have two apps, with a second more specific app heavily dependent on a first more general app. What I find in this scenario is that I somet…

Agreed. I've built and maintained a moderate size Django app for 5 years now, and had similar issues.

GOOD app division: my "members" app which has classes for UserProfile, MemberType, and communicates with an upstream 3rd party membership API. It doesn't have any dependencies, but a bunch of other apps that depend on it. Another one I've just started work on is a generic Questionnaire/Survey app. This one is a definite candidate for spinning out as an open-source third-party app later, it lets you attach Questions and Answers to any of your own model objects via generic relations.

BAD app division: I have separate "Entry" and "EntryHandling" models across two apps, the latter is a OneToOne with an Entry. Originally this was a separation of concerns, but it's become a mess. Like the parent, the generic app ends up depending on the specific app, and migrations have to be handled gently and sometimes manually edited.

If you treat your Django apps as points that would be logical for splitting as micro-services, you'd probably be just fine.

Re: Tips for Building High-Quality Django Apps at Scale

#109

Post by photojosh »

vosper wrote: post #77
mi100hael wrote: post #5

Earlier quoted context omitted.

Part of it is that Django has been around for quite a while now. It's maybe _the_ most succesful Python framework out there, so there are some paradigms that aren't common anymore but are hold-overs from years past. In particular, it pre-dates the current "microservice" trend and assumes a fairly monolithic environment. And I think "apps" _do_ make sense in certain contexts. Consider this situation: - I start a "poll…

Is it actually possible to find and drop in apps like you suggest? And have it just work? Is a repository of various blog apps out there? What if one of them does something nasty to your database? It seems like it'd be easier to spin up a Wordpress instance...

Wordpress is a CMS more comparable to something like django-cms (haven't used it). Django is more generic than Wordpress.

An example is worth 1000 words? Here's my app setup for the website I've been developing for 5 years.

    # these are the "drop-in" apps we've been discussing    
    THIRD_PARTY_APPS = (
        # django-allauth
        'allauth',
        'allauth.account',
        'allauth.socialaccount',
        #'allauth.socialaccount.providers.facebook', # to add later on
        'django_hosts',
        
        'bootstrap3',
        'imagekit', # for thumbnails
        'paypal.standard.ipn',
        'template_debug',
        'import_export', # CSV import and export
        'jfu',
        'extra_views',
        
        'post_office',
        'django_xworkflows',
        'markdown_deux',
        
        'django_mobile_app_distribution',
        'hijack',
        'compat',
    )
    
    # Ones I've written...
    LOCAL_APPS = (
        'membership',
        'awards',
        'reports',
        'entryhandling',
        'folio',
        'judging_console',
        'email_manager',
        'printing',
        'judges',
        'logs',
        'honours',
        'api',
        'questions',
    )
    
    INSTALLED_APPS = DJANGO_APPS + THIRD_PARTY_APPS + LOCAL_APPS

Re: Tips for Building High-Quality Django Apps at Scale

#110

Post by gjjrfcbugxbhf »

tinix wrote: post #51
asdfgadsfgasfdg wrote: post #39

Earlier quoted context omitted.

How do you add columns to your db? Do your requirements never change? I am fully capable of doing everything done with migrations with SQL - but I always use migrations (even for custom sql outside of the ORM's capability). Why? because then we have a record of the schema state at any given moment (that is in sync with the application code at that point) and how it got to where it is now.

If you're leaning on migrations often, with SQL, then I think you should not be using SQL, obviously (or you're just doing something wrong) Or, one should use a SQL database that allows more abstract data types (like JSON blobs in Postgres)

I prefer to make use of the strong type system and inbuilt integrity checks that a database gives. json blobs mean reimplimenting this at app level. The people paying me are paying me to build their products not reinvent the wheel.

Migrations are an excellent tool if you aren't using them you are doing something wrong.+

Edit + assuming that you are working with a relational database and have an agileish development process or ever have requirements changes.

Post reply on HN