3 ms·
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 a
by mi100hael 9y ago
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 "polls" app like the Django docs example.
- I get a lot of users and they like my functionality, so I want to engage the community.
- I decide to start publishing blog posts, but I'm too lazy to spin up a whole new Wordpress install
- I find a "blog" app and drop that into my project with the '/blog' URL prefix.
Now I can start writing blog posts right away and anyone can go to my site '/blog' and see it. There are no cross-app database dependencies to worry about.
The same would be true for adding a basic "social" app that shows a user-profile page for django Users at '/users/<id>' or something like that.
- randomsearch 9y agoThe polls app example is given in the introductory Django tutorial...
- mi100hael 9y agoYes, that's what I said...?
- randomsearch 9y agoSorry, misread that line. Point being, how many examples do you have where someone writing a Django site is going to reuse their own apps?
- soperj 9y agoI reuse my own apps constantly, whenever I do new sites.
- randomsearch 9y agoExcellent - 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.
- mi100hael 9y agoIt's a worthwhile abstraction for any generic feature that isn't specific to the one project you're working on: - User profiles - Content management/publishing - Messaging and chat - Searching your database - Admin - Analytics on your database Segmenting into apps makes the most sense when there are no cross-app dependencies on migrations: additional read-only capabilities on your existing models in another app, or new capability using entirely new, stand-alone models.
- deleted 9y ago[deleted]
- vosper 9y agoIs 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...
- arctangent 9y agoYes, 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/ https://djangopackages.org/
- vosper 9y agoThanks!
- sly010 9y ago> What if one of them does something nasty to your database? Same question is valid for Wordpress plugins.
- andy_ppp 9y agoWordpress has already done nasty stuff to your database...
- photojosh 9y agoWordpress 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