I have written for a very simple app of mine .
To login facebook canvas users of the app
To do some visitor tracking , most of the code is very simple.
The app probably is not that complicated , fairly close to a blogging system . However I wish to know how costly in terms of resources my architecture of middleware going to be.
One of things that is specifically worrying me is the fact that a new visitor object is created every time a unique request is made . Is that a good idea ?
So while middleware are an amazing DRY and agile concept how well do they standout in terms of performance.
Thanks
While I can't serve you with benchmarks, my experience is that, if a middleware is thin, it does not really matter in terms of performance, at least if you're not running a really high-traffic site. In my projects (some of them middle-traffic sites), I make heavy use of middleware, and I did not notice a remarkable performance drawbacks.
About the "visitor object": If you are using sessions, Django initializes a user object on every request, independently of using a middleware or not. Even if the user has not been logged in, an anonymous user will be created.
So keep your middleware small and you might not get into trouble.
Related
I would like to build a REST Service which exchanges JSON messages with instances of a mobile app for registering patron traffic in physical locations of (public and academic) libraries.
I plan on using Django Rest Framework, and using Django and DRF for the first time, have some questions (rather, recommendation requests). I have read the tutorials and followed some of them, and it looks very promising indeed.
As I am quite confident with Object oriented coding in Python, I will be using class based views. Any reason not to?
The intended usage of the system will include many different libraries with their own ids, users and properties. The data model behind is thus fairly complex, and implemented with MySQL. I feel I will have better control on the data exchange, updates inserts and selects, with custom SQL queries, and would like the DRF to handle mostly authentication and the routing of messages to and from the instances of the mobile app. Is this a misconception on my part, and would it be better to let DRF handle all database-involved aspects?
Given that I follow the custom SQL approach:
As (authenticated) user IDs are interwoven with the rest of the activities (e.g. we would like to know which of the authenticated users stands behind a certain registration of activity), it would seem "simple" to use a single database for both the business model itself and the DRF-controlled aspects. Is it recommended ? Are there any aspects that need to be considered here?
I have not found similar projects to be learning from. Anybody knows a similar project?
I know it is not very concrete, but hope to elevate my understanding a bit while endeavoring on the task.
Michael
I have tried to keep this as unopinionated as possible. Mostly reffering from Django's and DRF's documentation to make sure.
Class based views have some implicit code flows, need method overrides at some places. But since you are quite comfortable with Class based views, it is far more superior in the following ways: cleaner code, much more DRY compliant than function based, easier to extend, keeps your code base more maintainable as it grows.
Django's ORM is pretty powerful and if used correctly it can provide a vareity of capabilities.
Unless your authentication system is very complex and needs to scale independently, having everything in the same DB makes sense. The chatter reduces and you will be able to utilise powerful Django and DRF's features.
I am building an API-first app with the Django REST framework, so it has no html views at all and uses only token-based authentication. At the same time, I would like to make use of the Django admin interface, which is no problem, but I am worried about the performance costs as it depends on a lot of apps (sessions, standard auth, messages, csrf, etc.), that are not needed in the main app, but will run on every request.
Is there a way to set admin-specific middlewares to run only on the admin interface?
I know I can subclass them and raise MiddlewareNotUsed on all requests except ones going to the admin site, but maybe there is some build-in or well-known solution to this?
To answer your question, no, I don't think there are built-in solutions that cater to this. But that's probably because your purpose is not a good fit for Django's design and philosophy.
I'm with the comment by Sahil on this. I used to be paranoid about performance too, but I realized that I was underestimating Django's speed (even with all these basic middleware), and that if performance was that critical, I probably shouldn't be using Django in the first place. I'm guessing that disabling these middleware will save an app's response time only unnoticeable milliseconds at most; inevitable network fluctuations might even be more significant. A developer's time is more expensive than the additional hardware that could be thrown at any performance and/or scalability problems that come up.
But if you still want to save on the middleware processing, I have an alternative idea: the convenience functionality provided by the Django admin (that is, CRUD operations) could be replicated quite rapidly with DRF viewsets. Perhaps you could build a corresponding API client using some rapid-development frontend framework for your users. (I was going to say, just use the DRF browsable API, but I remembered that also relies on pretty much the same basic middleware as the Django admin.)
I'm creating a Django powered website that will have numerous applications (Blog, Shop, Portfolio, etc.) that will be edited by 5 or so people, and I have so-far been designing everything with the Django admin in mind.
I have come to realise that this is a very bad way of thinking -as really- the Django admin should really only be for top level administrators, and should be used for exactly that: administrating the website, not contributing to it.
I wrote out the feature-set and realised that the number of applications the entire website should have (sitemaps,mailers,contactforms,comments,tags etc.)is much much larger than the number of features the editor should have access to (CRUD actions for blog/about section etc).
Is it better practice to build a complex permission based Django admin, or build a second custom "editors" admin to run concurrently.
I think this is something that should be discussed in the documentation, as until I realised this, I had a lot of trouble understanding how to break the website down into applications, as I was designing everything with the admin in mind (and what actual user should see in the admin)
I'd argue that you should build a separate "diverse" admin app. Here are the pros and cons as I see them:
Pros:
No need to tamper with Admin or use hacks to get specific features. I suspect you'll need several such given your requirements.
De coupling from Admin. While Admin is very useful it is a bad idea to tightly couple your app with it. All the more so if you are tweaking it. Your would have to watch out for any changes in Admin that would break your app.
Custom styling. I guess visual appeal may not be high on your list but it is far more easier to style your apps than the Admin app.
Separate the really super users from "line admins". Let only the power users see the real innards of your system.
Cons:
You'd be reinventing the wheel. Generic views make this easier but you'd still end up duplicating features or featurelets.
Testing. The Admin app is widely used and is fairly well tested. You can use it without writing any unit tests (for most part). If you build your own you'll have to build an extensive test suite around it.
It is a matter of opinion I think. But personally I prefer to create a separate admin and link a user group to that instead of using the main admin for both.
That way you can easily see how everything looks for the other users when there's a problem. It all depends on your situation though, so YMMV
I am almost done developing a Django project (with a few pluggable apps).
I want to offer this project as a SaaS (something like basecamp).
i.e: project1.mysaas.com , project2.mysaas.com etc
I seek your expertise in showing me the path.
Ways I have thought of are:
1 use Sites to define site specific settings.py
2 a middleware to detect request then set settings accordingly
3 create Django project (taking in pluggable apps) for each site
Thanks.
btw, i am a total newbie.
Your requirements aren't at all clear but I'll assume you aren't doing anything tricky and also assume your "project1", "project2" are customer names which won't need any special branding.
First, about your ideas:
You probably won't need to use the sites framework unless each site is branded differently. The site framework works well doing what it was designed to do, which is present different views of a common set of data.
This would work but probably is not the best approach IMO.
This is unmanageable.
Now, this is a really hard topic because there are so many issues. A decent place to start reading is the High Scalability Blog and especially relevant for you would be the post on 37signals Architecture.
Finally, here's what I am doing in a small SaaS app (that doesn't need extreme scalability):
Use the sites framework (because user pages will be branded by the partner/reseller and each partner has a unique login page)
Use mod_wsgi to minimize resource usage from all the Django instances.
Instead of middleware I put a common code at the top of every view that identifies the company of the user. I need this for logic in the views which is why I don't think it's useful in middleware.
I was thinking that django admin is an utility to provide trusted administrators of the site, full access to the site's data model.
However, after going through django admin in detail, I understand that it is very powerful set of views and templates that one can use to create an entire application.
How often do you create an entire application using admin alone? Is it easier to create using views itself than customizing admin that much?
How about building prototype using admin. Do we even need to build prototype? The admin customization cannot be re-used in real application.
If I want to use a part of the admin code in real application (with different templates), is there some kind of scaffolding option available?
"The Admin is not your app."
If the customization goes beyond the trivial, write your own views.
In my experience, I leave the internal admin pages relatively untouched. Instead, I override the admin index template, where I put links to custom-written views when the user needs to do nontrivial reporting or form handling.
I have done something like that before. It was a CMS for a university completely implemented by extending Django admin. It turned out it was a bad design descision. I had to jump through hoops to do some things.
It really depends on what the requirements are for your application. If there needs to be lots of ajax or some specific workflow extending the admin will not be the right thing to do. But I think 60% of cases can be covered by extending the admin.
It's also excellent for building prototypes.
EDIT
OK, that was in the 0.96 days.
So far I've built 2 "big" sites that are in production completely on top of the new admin. These are mostly case management, data entry and reporting so they could be squeezed into the workflow of the admin. But, not without a big effort going into extending the base Site, ModelAdmin, InlineModelAdmin etc. The decision to go this way is we were pressed to do it quick. But in the first case it was a perfect fit for the requirements too. Both run on an intranet in the government sector. Both do their job fine. One with 200 tables handling tens of thousands of entries. The other one manages payments.
So, yes it's true. The admin is not your app. However, it's extendable enough although much of it is not documented. And it fits in most basic enterpresey workflows. So it's worth considering in a limited number of scenarios.
I disagree with most of the other answers.
Simply put, there is no match for what you get for free using the admin app.
Your first customization of the admin will be tough as you'll be facing a steep learning curve (you will need to deal with overriding templates, Managers, ModelAdmins, probably use database views, the CSS and JS, some additional forms and validation rules, etc...). But once that is done, you'll start to feel king in bending the admin system to your needs. I have built a complex inventory and accounting web application with data-entry, reporting, and permission system all based solely on the admin interface and back-end.
The Django Admin is incredibly flexible and can be overridden in multiple ways. Unfortunately there is more than one way to do the overriding and some of the techniques are not terribly well documented.
The good news is that the following strategy seems to work well:
Override, customize and subclass the admin app until it all starts feeling a little painful and at that point just drop into your own views where needed.
There's some useful links in my answer to this question
In short:
Try out the admin part for your needs. Modify the standard views. If there is something missing, you can always develop your own view.
For me, I can't imagine an entire (bigger than rolodex) application based only on django-admin.
A.