I'm new to Django and trying to understand the preferred means of operation when deploying web applications.
Let's say I'm making a web application with (for example) user login management, some uploading functionality, manipulation of uploaded files, and rendering uploaded files on screen. They're all part of the same "web application".
Would each of these functions be its own app in the project, or should these all be together a single app? Is a Django app intended to correspond to a web application, or does it correspond to a single set of functions interfacing with a few tables in the database?
There's a distinction to be made between reusable apps and non-reusable apps. For reusable apps it's essential that they offer well defined functionality and are intended to solve a well defined problem. If this wasn't the case, they wouldn't be very reusable.
However you're likely to also have some non-reusable apps, i.e. one or more apps in a project that implement application logic that's specific to the project. In my projects I always have a non-reusable app called core that acts as glue and ties everything together. If I have distinct sections in my site I may choose to have more non-reusable apps, because I like the way it essentially namespaces my project (e.g. models, views, templates, etc.)
A Django app is a group of related functionality used to complete or maintain one aspect of a site. The web application you describe would be separated into at least 2 Django apps, depending on how granular you want to make the handling of the uploaded files.
Related
I am starting with developing REST API's with the Djano framework. Previously I have worked extensively with Java related frameworks specifically with SpringBoot.
If I take an example of a REST API in Java based framework below is the directory structure that I have mostly used :
So something mostly on the lines of a MVC Design Pattern.
Also in java mostly each class is written on a new file, however the tutorials that I have been looking around writes multiple classes within one file, is this the best practice around Django?
Also I see that in Django we create a project and then inside it we create an app. Are these app equivalent of package in java?
Also, in SpringBoot and other java related frameworks we normally follow a Top-Down approach, where a Controller recieves a call which is further passed on to the Service where all business logic resides which then further calls DAO(Repository) for CRUD and the corresponding result is passed from DAO to Service back to Controller which generates the formatted response.
What I have moslty seen in Django is all the logic is written on views which calls Model for CRUD. Don't we follow SOLID priciples here?
If I take an example of a library management system, How will one design that around the Django framework?
This is a great question, but I'm not sure that StackOverflow is the right place to ask it, as there is no clear-cut answer. That said, I'm trying to give it a shot.
Django also follows the MVC design pattern, but the naming is a bit different.
Django Models -> MVC Models
Django Views -> MVC Controllers
Django Templates -> MVC Views
It is often referred to as MTV instead of MVC. But that's not the end of the story, because many people think it is a bad idea to put too much business logic in the views, for reasons like testability and reusability. There are two common approaches to this issue:
fat models: you put all your business logic inside the models
services: you have separate modules containing methods/classes for your business logic
Personally, I have worked with both and had better experiences with the services approach.
The equivalent to a DAO in Django is probably the Django ORM. Note that this is really only an abstraction layer for the supported relational databases. If you want to use another datasource like a NoSQL DB or a REST API, you have to roll your own solution or look for third-party packages.
Java can only have one public class per file and they must have the same name. Python does not have this limitation, so it is indeed a best-practice to have multiple classes per file (.py files are called modules). If a module/file becomes too large, you can turn it into a package (a directory with a __init__.py file) containing several modules (and/or sub-packages).
The differentation between app and project can be confusing, so I have written a whole article about Django's naming scheme. A Django app is a Python package, but they are usually organized by domain. E.g. in a library management system, your library project might have an app catalogue to manage the inventory, and a checkout app to manage the process of checking out books.
Finally, if you are specifically aiming to build a REST API, I highly recommend you have a look at Django REST Framework.
I have a very large django project with many features that uses django as backend framework. My project lets users use both a website and a iOS app.
I am researching using a monolithic app (currently using monolithic) vs micro services, I watched this video but one part really throws me off. At 1:05, he previews his 'monolithic' app before he changes to micro services, which to me looks like a single project with a bunch of different apps.
1) Are these technically just folders and not apps? These (what i would assume he calls folders) all have a models.py and views.py and most have a admin.py.
2) What makes this a monolithic app? Is it just because he doesn't simply use django-admin startapp in the terminal to create these 'folders'?
3) Or are microservices multiple projects connected and not simply multiple apps in a single project?
My biggest confusion is with the previewed project in the video because before then I thought I had a good grasp on these concepts. I was simply looking to change to microservices, after this part in the video I'm not sure I even know what a monolithic app really is.
The main difference between a monolith and a microservice is more about how they are deployed. A monolith is one large app that must be deployed all-or-nothing. Microservices are many "apps" that work together to achieve their purpose, and each can be deployed separately. Typically monoliths are more difficult to deploy, and involve more risk since the entire system can crash if they are badly deployed. For Microservices, each only handles part of the business processing so, in theory, if one is deployed badly only part of the app goes down.
This is just a conflation of terminology.
In the context of monolithic apps vs. microservices, "application" refers to a web application, or in this case more specifically a WSGI application. A Django project is usually deployed as a WSGI application. So a monolithic app would be a deployment of a huge Django project, while microservices would be multiple smaller Django projects that are deployed separately.
"Monolithic app" may sometimes be used to refer to a Django application, i.e. a python module that is in INSTALLED_APPS. However, in that case you wouldn't be talking about microservices.
I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.
I am currently working on a Django web application consisting of following parts:
API (Django-REST-Framework) Finished
Custom administration page Unfinished
For super users
For normal users
The API app which has currently been finished has all the models for the entire system hence it made most sense. Now what i'm very uncertain about is if i should build the administration page inside of the API app, or create a separate app for that purpose? I will still need to refer to an external model, and will this be painless to maintain in the future?
I am not fully certain how the app structuring should be handled in my certain use-case.
According to advises i ended up creating separate apps to keep clean structure in the code.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).