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.
Related
So, I am new to this "monolith vs microservices" architecture debate and I have pretty much understood most of it. From my limited understanding I get it that in microservice architecture each feature(lets say) is a separate app. Now I need some clarification with respect to django for implementing microservices. Heres my question
Should I make every microservice aka the app a different django project altogether OR should I make every app aka the microservice inside one django project and keep them isolated (as in loosely coupled) ?
Microservice architecture simply states that your each service should be independent of each other.
Its also not necessary to create one micro-service in java and one in python since they are not related.
So yes, ideally your each micro-service is a separate django project.
The best way to break this, first list down all the possible modules in your site or app.
Then go through :
https://microservices.io/patterns/decomposition/decompose-by-business-capability.html
https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
These are two recommended pattern of how you should divide modules / domain into micro-services.
well, you can use database routers in django ... that does the trick ... one wSGI file per app communicating with your NGINX server
The main purpose of micro service is to serve the specific business, for example you are running a cloud kitchen then Django project can have many sub projects under one master project or you can run each project as separate service, it up to you.
Service
backoffice
finance
rider
kitchen
now we will set the url for each service like
Endpoints
backoffice.mycompany.com
finance.mycompany.com
rider.mycompany.com
kitchen.mycompany.com
Once our app is up the service load will not effect other service.
The microservice should be completely independent so it should not belong to one Django project. You should be able to deploy each service independently with its own database, so even you split the project into separate apps they still share one physical database and you can not deploy them separately. Therefore, you could potentially create separate Django project for each 'microservice' but this does not make much sense. You put lot of overhead for creating a microservice and also using Django framework is not a best choice for MSA , have a look at Flask.
I new to the web development.
Right now, I am using Angular 2 as front-end and Django-Rest-framework as back-end. While browsing the tutorials online, people often build the angular2 app (ng build) and then place those built files under the django project. But my question is, doesn't this approach defeat the purpose of decoupling? Can you provide me the pros and cons of these two approaches?
Ask Django to host the built angular project, and deploy it as one instance.
Separate both frontend and backend, and deploy them as two instances.
Thanks in advance.
I don't see a reason to host an Angular app inside a Django project, most apps will separate frontend from backend and deploy them to different servers (at least in my experience) to ensure easier maintenance, that way if your backend has any bugs, you'll have an easier time finding where the bug is and how to fix it.
Mixing both would mean that if for some reason front or backend have any problem, THE WHOLE app will have said problem and result in a bad user experience.
I am using reactjs for frontend and Django REST API for the backened. What is the best possible way to integrate both?
which of these two is a good option?
Running two servers for frontend and backend?
or
replacing django templates with reactjs?
Your help is highly appreciated.
Few options here
Django templates with react.
Not my preferred method. Essentially, you are blending django templating and jsx. The benefit here is low over head. It requires little configuration and allows you to write react and leverage the django templating language in the same file. If you need to get something up and running quickly, its a great solution. Have a look at this library https://github.com/Frojd/django-react-templatetags
Using django webpack loader
This will allow you to separate your react code from django code but still keep all your code to one repository. You need to configure django settings to find your react code. Then on your prod/dev server, have your web server point to the directory where your static react code lives or write a django url and view that will serve the react apps index file. It will be located in /static/ after you configure correctly and run python manage.py collectstatics. Benefits here are that it keeps the code to one repository but still isolates the python and javascript code. This is a middleground solution of the three. Quick note. You won't have react hot reload with this method for development. Here is the library that helps you configure this setup https://github.com/owais/django-webpack-loader
Having 2 separate applications
Similar to what you are doing right now, have a separate react repository, either served by a nodejs backend or deploy the code to a cdn service like amazon s3 and serve the one page app from there. And then as its counterpart, have your django app on a separate server with its consumable rest api (will need to configure allowed cors) . This method requires a lot of operational work: deploying, configuring, and management of 2 separate code bases. If you have the time and resources I do recommend this setup. The decoupling of the 2 apps allows this solution to scale the best
What do you mean two servers? You mean two projects/repositories?
Yes, you can keep frontend in the separate project. It make sence if you have multiple clients for your backend (like mobile apps and web). Different developers can have permission to edit only their repositories. Also it make sence if you are going to use some microservices structure for your project. But more simpliest way is to keep frontend and backed in the same project. Try to check some tutorial about Django+reactjs apps.
We are developing a SaaS that uses a number of quite independent apps that are all currently in the same django project running on the same server.
We know that eventually some of the apps will be relocated to their own server primarily due to differences in server loads. We also believe some of the apps may become resources for new applications as well (the same app instances running in our SaaS).
We are at the point that we should go in an clean up cross app coupling and make rules about a common interface medium. My thoughts are that is should be a restful interface between all apps.
So: Is enforcing a restful interface across all apps a bad idea in the best case scenario for such an argument (all apps on different servers), and worst case scenario (all apps stay on the same server)?
You can take at look at Piston for creating RESTful APIs in Django.
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.