I'm currently writing a webservice (with node.js) for an AngularJS frontend which is hosted with node.js
It will later be available through a proxy under domain.com/api and therefore I don't need JSONP.
For local testing purposes i have my AngularJS app running on localhost:80 and my node.js backend on localhost:3000. Naturally I'm not able to query json requests. The easies
What would be the best setup to test my homepage locally without screwing to much in my setup?
I'm currently working on windows. Linux is also an option if it is easier.
Would it be possible to write a simple proxy for express that hosts both apps in the same domain?
You can use the hosts file to set the domain.com/api to localhost. This is done in /etc/hosts in Linux, but its present somewhere in Windows too. Another thing that helps me a lot is ssh tunneling. You can, for example, tunnel remote ports (where your backend is running) to localhost with ssh -L localPort:your.server:remotePort
It's not exactly what you asked for, but the easiest might be to have the node.js app serve the AngularJS app, too. It's quite efficient, certainly efficient enough to use for development.
If it's an expressjs app, you can just add
app.use(express['static'](__dirname + "/public"));
before your other routes to have it look for static files in ./public/
If your app is served by a template or build system that you can't easily reproduce in node.js, then another option would be to run nginx, apache or haproxy on some port (80 or 5000 or ...) and have that proxy to the current backend server for the app and port 3000 (the node.js app) for the API/data requests.
You might even be able to have your server currently running on port 80 do this.
As a final idea you could also setup the node.js app to proxy to port 80 for the "app files".
Edit - I just realized that both of your apps are written in node.js. Would it be possible to set it up so you run them separately in production but together in development? Put all the real functionality in modules and then have three separate "loaders" that start the apps, one together and then a loader for each individually.
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.
To this point, I just created and played my Django server in my localhost, like setting up a basic server Linux distro on my another device and testing etc.
However, I also heard of server applications like apache2 or nginx. The thing I wonder about is: Do I really need to use one of them in production? I want to buy (or rent?) a VPS service, then deploy (or publish?) my project on that server. The questions on my head are:
Running server with manage.py runserver 0.0.0.0:80 means it does not make my application worldwide? An server application (or whatever it is) makes it accessible outside?
Or a server application is simply needed for better performance, optimization etc. ?
Simply, why do I need to use apache2 or nginx to deploy my project?
It's a long story. In few words:
Running your project on localhost surely wont make it worldwide accessible, since at least you need a public address for your server, but not a local one.
Speaking honestly it is not a problem to run a site in pro using django built-in server. But, as you can read in docs, it is strongly NOT recommended. Why? Because it was developed specially for testing. It is written in python (slow enough for web server) and not suitable for handling multiple queries to the server and it is only a matter of time when it will crash. Of course, there are plenty of other reasons like cache and access settings, redirects and others.
So I have noticed that the docs for various Application Servers (think Unicorn, Puma for Ruby, Warp for Haskell etc) always mentioned something similar to "it is optimized as an app server.” Typically this is mentioned when describing the standard setup of using a HTTP server (like Ngnix) in reverse-proxy in front of app servers.
So my question is: What exactly does the programming of a web application server make it more performant for serving data generated by code v/s HTTP server? Is there any particular engineering trade-offs? Or is it more the case where HTTP servers are optimized for serving files from a disk, and so they're merely trying to say that HTTP servers are not optimized for application code?
First, this really belongs in ServerFault or SuperUser.
But basically, Apache & Nginx strictly deliver static web content. Yes, you can install PHP as a module & it will parse scripts when the page is requested. But it is all on demand. Meaning the program runs only when the page is requested.
In contrast application servers run programs that are active in memory all the time. Which can have some engineering benefits depending on what you want your system to do. So Tomcat or Passenger (for Ruby) run Java & Ruby apps, and are optimized to do it in a production server environment.
Why does Apache or Nginx get attached as a front end? Because at the end of the day Apache & Nginx still are the best tools for simply delivering web content. And have better optimizations & security in place to do so.
So the application server focuses on making Java or Ruby run as cleanly as possible & deliver basic web content. And Apache & Nginx concentrate on the front-end side of web delivery.
As a systems administrator, I prefer to proxy via Apache or Nginx since I already know how to configure & optimize those tools for my use. If I have to learn how to fine tune Passenger or Tomcat, it should only be enough to allow me to get it running so I can place Apache or Nginx in front of that.
I use Django for my website and I want to know whether there is a work around for testing secure pages in Development server. As a temporary workaround, I wont use HTTP to check the webpages in dev server, which I think is not a correct way? What do you think?
You might consider mod_wsgi, since it can be used for development, testing, and deployment. mod_wsgi can be configured to detect any changes to you make to your Python code and automatically restart, same as the development server.
I tend to do most of my development on my local machine, but use an actual reference implementation server for testing. It's running mod_wsgi under apache, with a self-signed certificate. A recent detailed article by Graham Dumpleton is available here:
http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django.html
This looks helpful -- using stunnel to route HTTPS requests to django dev server.
The Django development server is very basic and intended for local testing only. It does not support ssl/https. You'll have to run it using Apache, NGINX, or some other web server that supports SSL in order to test.
You can now use FakeSSLMiddleware