25đź‘Ť
A typical, real-world example would be to store uploaded images in a subdirectory of your site’s media/
directory 🙂
This can become a problem if you need to store more images than your app server has hard disk space, or you need more than one app server, or you want to use a CDN to decrease your latency, or… one of a thousand other things.
But, unless you’ve got specific up-front requirements, the only way to know which (if any) of those thousand things you’ll need to worry about is to get your site launched, and the fastest way to do that is to store images in a subdirectory of media/
.
If you do this using a FileField
, and you’re careful in your code not to assume, for example, that the image is a file on your local disk (for example, you do use the .url()
method of FileFile
and you don’t use the .path
property), it will be straight forward to move those images onto a more appropriate backend when (and if) the time comes.
9đź‘Ť
By default, Django saves all of your files (and images) in the MEDIA_ROOT. You can however write a custom file storage, in order to save it on other places.
What to choose? It really depends.
How many files do you plan to store? How much storage will they use? How much bandwidth? Do you think there will be peaks of very high usage?
Usually, local file system is the fastest option; but if you see that those images will use too much of your bandwidth, then you may want to offload them, especially if the usage pattern sees high peaks. Conversely, if you need to scale out to several servers, then you may find it beneficial to move them in a database.
Anyway, you should decide only after getting some data, if possible real data. Switching to a different storage system is quite easy, so I would start with local file system, and then switch to something fancier only after seeing issues.
- [Django]-How can i use signals in django bulk create
- [Django]-Python Asyncio in Django View
- [Django]-Django REST — How to "modify" value before returning the REST response?
5đź‘Ť
It’s not bad practice, per se. I think whoever told you that is a little confused. Django says you should never serve static resources with Django, i.e. they should be served directly by the webserver you’re using as a reverse proxy for Django (Apache, nginx, etc.), but it makes no contention on whether that must be on a different server or the same server.
If you have a simple app or website, using an entirely different server for static files is probably overkill. It only matters in instances of high concurrency (think Twitter, Facebook, etc.) where the application cannot afford to have the webserver worry about anything but ferrying requests to the app itself. Now, some web hosts offer “cloud” storage to go along with your VPS (Rackspace, for example). If you’re using such a host, by all means take advantage of what you have, but it’s not necessary for the most part.
However, there is benefit in serving static resources under a different subdomain. You can use the same server, but using a subdomain (e.g. static.mysite.com) will allow browsers to do more parallel downloads, in some cases, and at the very least, prevents cookies from the main website from being attached to each static request.
- [Django]-How can I MODIFY django to create "view" permission?
- [Django]-Django REST Framework: Unique_together validation on Serializers
- [Django]-Django – ImproperlyConfigured: Module "django.contrib.auth.middleware"
1đź‘Ť
It really depends on the solution you’re trying to solve for. There are instances where s3 can be a much better solution than local file storage. s3 offers more flexibility in terms of being able to access the data from different web apps and being decoupled from the server you’re using. I think s3 is a route to go if you plan on using a lot of images. If you think there are a limited amount of images that you’re going to use, then local storage on the server would be a fine implementation (i think).
In terms of tools that you can use, I’d look into PIL. http://www.pythonware.com/products/pil/
- [Django]-Django: 400 bad request syntax – what does this message mean?
- [Django]-Malformed Packet: Django admin nested form can't submit, connection was reset
- [Django]-Fields.E304 Reverse accessor clashes in Django