I am planning to deploy an application which is built in react frontend, and calls a python backend. What I am planning is to deploy react on a linux box on a node.js server and python on django behind Apache.
Can someone would suggest if this would be right architecture from production grade perspective?
If application is expected to get 1000 requests per hour, then will this architecture work? or I should replace or add components or layers?
Generally, you run both servers on different ports, and then point apache to django server for /api/ calls (or whatever URLs need to go to django api), and then the rest of the regular requests you point at node.js serving your javascript frontend application.
1000 requests per hour seems like nothing - depending of course on the work of the backend server - but in general any webserver should handle that no problem.
Apache has following settings for this:
ProxyPass "/api" "http://127.0.0.1:8000/api"
ProxyPassReverse "/api" "http://127.0.0.1:8000/api"
You can read more in documentation here: https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html
Related
Setting up Flask with uWSGI and Nginx can be difficult. I tried following this DigitalOcean tutorial and still had trouble. Even with buildout scripts it takes time, and I need to write instructions to follow next time.
If I don't expect a lot of traffic, or the app is private, does it make sense to run it without uWSGI? Flask can listen to a port. Can Nginx just forward requests?
Does it make sense to not use Nginx either, just running bare Flask app on a port?
When you "run Flask" you are actually running Werkzeug's development WSGI server, and passing your Flask app as the WSGI callable.
The development server is not intended for use in production. It is not designed to be particularly efficient, stable, or secure. It does not support all the possible features of a HTTP server.
Replace the Werkzeug dev server with a production-ready WSGI server such as Gunicorn or uWSGI when moving to production, no matter where the app will be available.
The answer is similar for "should I use a web server". WSGI servers happen to have HTTP servers but they will not be as good as a dedicated production HTTP server (Nginx, Apache, etc.).
Flask documents how to deploy in various ways. Many hosting providers also have documentation about deploying Python or Flask.
First create the app:
import flask
app = flask.Flask(__name__)
Then set up the routes, and then when you want to start the app:
import gevent.pywsgi
app_server = gevent.pywsgi.WSGIServer((host, port), app)
app_server.serve_forever()
Call this script to run the application rather than having to tell gunicorn or uWSGI to run it.
I wanted the utility of Flask to build a web application, but had trouble composing it with other elements. I eventually found that gevent.pywsgi.WSGIServer was what I needed. After the call to app_server.serve_forever(), call app_server.stop() when to exit the application.
In my deployment, my application is listening on localhost:port using Flask and gevent, and then I have Nginx reverse-proxying HTTPS requests to it.
You definitely need something like a production WSGI server such as Gunicorn, because the development server of Flask is meant for ease of development without much configuration for fine-tuning and optimization.
Eg. Gunicorn has a variety of configurations depending on the use case you are trying to solve. But the development flask server does not have these capabilities. In addition, these development servers show their limitations as soon as you try to scale and handle more requests.
With respect to needing a reverse proxy server such as Nginx is concerned it depends on your use case.
If you are deploying your application behind the latest load balancer in AWS such as an application load balancer(NOT classic load balancer), that itself will suffice for most use cases. No need to take effort into setting up NGINX if you have that option.
The purpose of a reverse proxy is to handle slow clients, meaning clients which take time to send the request. These reverse load balancers buffer the requests till the entire request is got from the clients and send them async to Gunicorn. This improves the performance of your application considerably.
I'm so confused as to what benefits I will be getting from using Apache to serve my Flask App in my EC2 instance if it's already out there to the public, & whether I have to think about using something like Apache or Nginx from the first place?
Why not just configure a production server like gunicorn (as I heard it's better to be used for security purposes even though this answer kinda made me doubt this a bit) and get a private domain and that's it for my flask app?
This question boils down to "application server vs web server". In your case gunicorn is an app server, and nginx/apache is a web server.
What is the difference between application server and web server?
To give some brief advice, you need to consider the scale and actual functionality of your app. If you expect to serve any consistent number of users, use web server, they are better optimized to serve concurrent requests. If your app serves some static files - also use web server, they do it more efficiently. If it's an internal app which only you and couple of guys use occasionally, you can get by only running a gunicorn.
I recently moved over to using Dokku and am wondering if someone can help me out with this. I am trying to run Vue and Django on a Linode server. Currently I have Django serving at my IP. Looks like in nginx, that port 80 is being listened to and Django is being served at /. I'd like to move Django to either be served at ':8000' as it is on my local machine or to be served at '/backend'. Then I'd like to serve Vue the way Django is currently being served () and it can hit the api at either previously mentioned Django location.
I ended up just throwing Vue up on netlify and that worked great.
Is it possible to configure Heroku where one has two processes that accept HTTP requests?
I would like to run one traditional request/response process (perhaps a Django Gunicorn process), and also run a NodeJS service that provides web-sockets. It would be nice if I could configure Heroku to work to a routing pattern like this:
ws/ # NodeJS websocket process
* # Django Process
Where any request with a URL begining with ws/ gets routed to the NodeJS websocket process, and everything else gets routed to Django.
Heroku gives an example of something similar.
https://devcenter.heroku.com/articles/realtime-polyglot-app-node-ruby-mongodb-socketio
But I really do not like this approach and will only consider it as a last resort. The issue is that the NodeJS process and the Rails process, are in separate Heroku apps. This will cause hassle when it comes to billing versioning and staging.
I'm a complete newbie when it comes to sysadmin/deployment. Here's what I'm hoping to accomplish:
Have domain.com be a normal WordPress site.
Have either domain.com/app or app.domain.com be a Django webapp.
Hosting on Linode.
Quick and easy updates of the Django webapp code.
From what I can tell, gunicorn is an elegant way to serve the Django webapp, while WordPress fits most naturally with Apache. Meanwhile, nginx is recommended as a proxy in front of gunicorn and also seems to be used to improve performance of WordPress sites.
So what I'm thinking is: use nginx as a proxy server that routes all incoming web requests to either gunicorn (for the Django wepapp) or Apache (for the WordPress site). The Linode host would be running nginx, gunicorn, and Apache simultaneously.
Meanwhile, for updates of the Django webapp, I can simply update to the latest version of the code via github.
Does all that make sense? Am I even understanding things conceptually correctly? Or barking up the wrong tree entirely? (For instance can/should I just use a single Apache server to route requests to either WordPress or the Django app based on URL?) What gotchas and issues should I keep in mind as I research how to get this running nice and smoothly?
UPDATE: I've side-stepped all of this by (1) using Heroku to host my Django app, (2) using a CNAME record to map app.domain.com to the Heroku-hosted Django app, and (3) leaving (for now) the WordPress site on its existing host at domain.com. Thankfully, after gaining great new respect for what sysadmins and db admins do as I investigated all this, now I can get back to coding!
#Ghopper21
+1 for your question first.
Now, This is really interesting to know how it's possible in real time execution. I checked with some of my geek friends and I found tremendous response, here are some of suggestion with reference I got after brainstorming with them.
First of all check this link for deploying & running WP altogether with Django on Nginx +uWSGI...
These two threads of support forums from Webfaction.com gives you more idea about how they are recommending it to their client...
Deploying Django and Wordpress in same domain
wordpress + django on same account - advisable or not?
Hey, I got one support ref. of Stack Overflow itself, which is explaining how to achieve it on APACHE server...
How do I run Django and PHP together on one Apache server?
And last but not least, the one where a geek like us integrated WP with Django...
Integrate WordPress and Django