Why Should One Use a Http Server in Front of a Framework Web Server

Why should one use a http server in front of a framework web server?

• Part of any web application is fully standardized and commoditized functionality. The mature web servers like nginx or apache can do the following things. They can do the following things in a way that is very likely more correct, more efficient, more stable, more secure, more familiar to sysadmins, and more easy to configure than anything you could rewrite in your application server.
  
  • Serve static files such as HTML, images, CSS, javascript, fonts, etc
  • Handle virtual hosting (multiple domains on a single IP address)
  • URL rewriting
  • hostname rewriting/redirecting
  • TLS termination (thanks @emt14)
  • compression (thanks @JacobusR)
• A separate web server provides the ability to serve a "down for maintenance" page while your application server restarts or crashes
• Reverse proxies can provide load balancing and fault tolerance for you application framework
• Web servers have built-in and tested mechanisms for binding to privileged ports (below 1024) as root and then executing as a non-privileged user. Most web application frameworks do not do this by default.
• Mature web servers are battle hardened and stable. By stable, I mean that they quite literally almost never crash. Your web application is almost certainly far less stable. This gives you the ability to at least serve a pretty error page to the user saying your application is down instead of the web browser just displaying a generic "could not connect" error.
  
  • Anecdotal case in point: nginx handles attack that would otherwise DoS node.js: http://blog.nodejs.org/2013/10/22/cve-2013-4450-http-server-pipeline-flood-dos/

And just in case you want the semi-official answer from Isaac Schluetter at the Airbnb tech talk on January 30, 2013 around 40 minutes in he addresses the question of whether node is stable & secure enough to serve connections directly to the Internet. His answer is essentially "yes" it is fine. So you can do it and you will probably be fine from a stability and security standpoint (assuming you are using cluster to handle unexpected termination of an app server process), but as detailed above the reality of current operations is that still almost everybody runs node behind a separate web server or reverse proxy/cache.

Why would I need a separate webserver for Django?

It comes down to the goal of the Django project and the efficiency gains associated with re-use (as opposed to reinventing the wheel).

The stated goal for Django is to offer a web application framework that enables quick development and minimal code. The original tagline was a "web application framework for perfectionists with deadlines".

That goal can be accomplished with a simple single-threaded web server that simply facilitates development and testing.

The goal of Apache httpd, Nginx, IIS, etc. on the other hand is to offer exceptionally scalable and performant web servers. These applications are highly configurable as all applications differ and there's no one size fits all. They also require different expertise to design, implement and maintain.

So it makes a lot of sense that with limited resources (developer time), the Django team chose to focus on the web-app framework, and leave the production-ready web server to another project.

What is the purpose of web server in a local web application?

If you want to use a web browser as the tool to interface with your Java app, then you need a web server. The browser is simply an app that tries to make a network connection with another app, and passes some text as defined by the HTTP protocol.

You would have a choice of three scenarios for this:

• Write an app that accepts network connections, processes HTTP, and sends back a response.
• Write a Java app that uses the very basic web server built into Java 18 and later. Note that this web server is not intended to be a feature-rich or commercial-grade server.
• Write a Jakarta Servlet class that runs on top of a Servlet container with a web server. For your needs, either Apache Tomcat or Eclipse Jetty would work well as both the Servlet container and the web server.

For your scenario, the middle option using Java JEP 408 seems most appropriate and easiest.

You said:

There is no communication with any other networks, its strictly local; yet I am having to create a web server to make this work and that is confusing me.

A Border Collie dog herds sheep. That is its most basic basic core mission. Those sheep can be herded across the hills of a mountain range or they can be herded locally within your own farm.

A web browser makes network connections. That is its most basic core mission. Those network connections can be made over the actual network or they can be made locally within a single computer ( a “localhost”).

You said:

Or do I need one because I decided to build a web application meant to be opened in a web browser?

Yes a web application accessed by a web browser needs a web server, by definition.

You said:

If I instead decided to build a windows/android/mac/ios application, would I still to bake a web server for communicating?

Or can I use something like swings (I know its really primitive)

There is nothing “primitive” about Swing. It is a fully-developed feature-rich GUI framework. Swing comes built in with every JDK. And Swing will be supported for many years to come.

However, the design and features of Swing may or may not suit your tastes. And Swing is now in maintenance-mode.

An alternative is JavaFX, now actively developed as the OpenJFX libraries.

To use JavaFX, you must either add the OpenJFX libraries to your project or else deploy to a JDK that comes bundled with the OpenJFX libraries (ZuluFX, LibericaFX, etc.).

to do this which essentially would allow the GUI to directly communicate with the business logic?

Yes the GUI and and your calculator business logic would all be plain Java classes, all peers, all running together within the same JVM.

You said:

I know front-end languages like javascript allow me to code the entirety of the calculator in itself, and as a result eliminate the need of a web server.

Yes. You could cook up JavaScript code to implement your little calculator. This JavaScript could be placed within the text of a file with the HTML of a web page. That web page file could be opened locally by the web browser. Your HTML and JavaScript would render. No web server is needed in this scenario.

But this scenario eliminates Java, and you said you want to (a) write your calculator in Java, and () use a web browser. So we go back to the three options listed above.

You said:

However, what if I was building relatively complex application with a backend database, like spotify? (within the same constraint that the application doesn't need to communicate with other applications and all data is stored locally) Would this solution still work?

Yes you could deploy a database server on your local machine. Then you could find and use a JavaScript binding tool to talk to that database.

But then you would not be using Java and all its goodness. For that scenario I would choose to write a JavaFX app with an embedded Java-based database engine such as H2. This would result in a single all-in-one double-clickable-app solution.

But that would be my choice based on my own preferences and skill set. Other people might choose other solutions.

the purpose of building an entire client-server infrastructure even though the entire thing is local and offline

The “offline” part may be distracting you.

Conventional computers with modern operating systems such as macOS, BSD, Linux, Windows, etc. are always “online” in that they all maintain a networking stack. That network stack can be used locally by processes within the one computer to communicate with each other. Whether you happen to have an Ethernet cable plugged in, or WiFi turned on, makes little difference to the computer. The networking stack in the OS is still available and active regardless of outside network access.

So client-server architecture works just as well within a single computer as it does between computers. (Actually, it’s works faster locally, as hopping on and off the network is terribly slow.)

Why choose client-server architecture for a local app? Either:

• You are skilled in, and prefer, the tools for a client-server architecture.
• You want to eventually move from local-only to being networked.

If neither of those two is true, then the JavaFX with H2 solution I mentioned is likely a better fit for a Java programmer.

---

By the way, let me put in a plug for Vaadin Flow, a GUI framework for building web apps in pure Java.

Web Frameworks versus Web Servers?

Apache/nginx are web servers, they can serve both static content(html,jpg, etc), and dynamic content generated by web apps.

Django/Flask/Express on NodeJS are web frameworks, they provide the common functionality for writing a web application, like request routing/ORM/session/template. It makes writing a web app much easier - you only need to 'fill in the blanks'.

Most of the time, a web app (implemented in a web framework) sits behind a web server, and process requests handed over by the web server. But sometimes, the framework itself can function as a web server, like Tornado/Express.

NodeJS is neither a web framework or a web server. You can think of it as a Javascript cross-platform runtime environment.

Why do we need apache under Node.js express web framework?

Putting Apache in front of Node is not typical in a greenfield app. The only case I can grant to this is if your company has an existing investment in an Apache based infrastructure (monitoring/security/routing/caching etc..) on the frontend and the sysadmin insist on this setup.

Some folks prefer to put nginx or haproxy in front to manage routing rules, so they can channel requests for static files (assets) away from Node.js (node.js wasn't always performant when handling static files), or do fancy load balancing or failover. In the early days of 0.2.x etc... even Ryan Dahl advocated running something in front of Node.js for security mainly; although, I don't think any significant issues were discovered. I personally run nginx in front of Node.js as we have several sites and services that hit the frontend shared IP which we proxy back to various node instances listening on different internal ports.

Nginx is better suited than Apache as it is light and single threaded vs Apache thread per request (in most normal setups). But nowadays there's even a reliable (node-http-proxy excluded) frontend Node.JS based proxy http://www.github.com/substack/bouncy which one of the celebrity node.js developers uses/will-use to frontend his PaaS.

What are the benefits of using Nginx in front of a webserver for Go?

It depends.

Out of the box, putting nginx in front as a reverse proxy is going to give you:

• Access logs
• Error logs
• Easy SSL termination
• SPDY support
• gzip support
• Easy ways to set HTTP headers for certain routes in a couple of lines
• Very fast static asset serving (if you're serving off S3/etc. though, this isn't that relevant)

The Go HTTP server is very good, but you will need to reinvent the wheel to do some of these things (which is fine: it's not meant to be everything to everyone).

I've always found it easier to put nginx in front—which is what it is good at—and let it do the "web server" stuff. My Go application does the application stuff, and only the bare minimum of headers/etc. that it needs to. Don't look at putting nginx in front as a "bad" thing.

What is the difference between web server component and web server? - No framework

To clarify:

Tornado is a Python web framework and asynchronous networking library.

That's their own definition, not mine. (https://pypi.python.org/pypi/tornado)

Tornado can function as a web server as well. Some Python web development frameworks don't really function as a web server - they need to be bootstrapped onto another library for development work. Others can function as a web server, but don't recommend it - they were designed to write code, not build it.

If you're inclined to do so, you can serve everything from Tornado directly. Most people - including the Tornado development team - have seen much better performance by putting Tornado behind nginx , and using nginx to load-balance and serve static content. http://www.tornadoweb.org/en/stable/overview.html?highlight=nginx

There are many different ways to deploy WSGI applications to the internet. Some of them include:

• Directly deploy the app on port80
• Use nginx/apache as a public load-balancer:
  
  • proxy connections to the app running on a local port
  • run the app under uwsgi, configure the public load-balancer to proxy requests to uwsgi

There are also other ways to deploy WSGI apps using gunicorn, eventlet, twisted, and countless other networking or web serving libraries.

To answer your question :

In the project you worked on, nginx functioned as a public facing web server. Tornado (most likely) functioned as both a web framework and a private web server.

---

Related Topics