At first, I am learning Python and Django only... So I'm a noobie yet.
I need to build a microservice architecture to I could run each my service on a separate server machine. In the Django I need to create an environment, project and apps. So, can I run these apps after on different servers? If no, how can I make it with Django? Do I need to create a separate project for each service?
P.S. If my question is stupid, pls, explain where am I wrong. I am from Java Spring world where I was need to create just new app for each service.
Either approach will work.
If it makes sense for your services to share the same code base, you can create a single project and use separate apps for each service and separate settings files for each deployment. The settings file would activate the desired app by listing it in INSTALLED_APPS, and would include settings specific to that service.
Or, if you don't need the services to be coupled in that way, you could certainly make each one its own project.
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 want to be able to able to inject some configurations from each app, and then run some code after all apps are loaded to load a service with all the provided configurations from all apps. How do I go about implementing that ?
Could you elaborate more the intention of loading all the config from each app? IMO Django by default has an ability to centralize the configuration in the one particular main app inside the project, and of course, it's configurable by mean you can store the configuration outside the project, using env_vars for instance.
TWITTER_SECRET = os.getenv('TWITTER_SECRET')
Some reference might help:
Django settings
The Twelve-Factor APP
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.
Is it possible to have each app in a django project in its own docker container? this way
1- All the dependencies of the app is contained to itself and there wont be any dependency conflicts between two apps.
2- In our project we are discussing a use case where apps should deployed in containers(primary and backup) such that when the primary goes down the backup takes over .. basically implementing High availability(HA) of an app.
I know that this may not exactly be a use case that Django was built to solve, but if it is doable in Django then i would like to do it using django as we have already created lot of apps using django and changing the architecture for the sake of HA would be a lot of work.
Note: I understand that the whole project can be deployed in a container and HA can be implemented.. but i'm more interested distributing apps in containers.
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.