Combine Any Web Server With Any Server Application's Language - nginx

I am new to server side programming, so please excuse me if my question seems obvious or ridiculous.
I am testing different back end options, like a language of a server (PHP, ASP.NET, Node.js, Python, Ruby and Go) and web servers (Apache, nginx, IIS...).
I am doing this to find the optimal language and web server for a monitoring web app. The server should grab data from a DB (updated independently by another app) upon a client's request, and return it back to the client (just as a background, it has nothing to do with the question).
My question now is as described in the title, can I use any web server with any application server's language?
For example, to use nginx with let's say ASP.NET (I know very well ASP.NET goes with IIS, I am just trying to give an extreme example)?
If the languages are not compatible with any web server, then, please explain to me with which each of the following languages is compatible with which web servers (the most recommended ones) and why:
PHP
ASP.NET
Node.js
Python
Ruby
Go
Again, sorry if it is about cars and I am asking about bikes. And Thanks for any help, I really appreciate it.

First of all, it's best to consider the framework and the programming language as completely different concepts, even if they often go hand in hand. E.g. Python is a programming language whilst ASP.NET is a framework. You can program ASP.NET framework applications for example in C#, VB, or even in Python. And if you were to choose a programming language, say Python, you can use Django, web2py and TurboGears for Python based web applications.
For web servers, it depends what kind of integration with the programming language you wish. More integration isn't necessarily better. Apache can run a PHP module, which is tightly integrated. Nginx can run PHP web apps using fastcgi, which allows you to run the PHP code as an external process. Even though Nginx using fastcgi isn't as tightly coupled as in Apache, it's not necessarily slower or worse! In many cases, the main web server (e.g. Nginx) is only a proxy for the actual web server, where the Nginx proxy handles latest web protocols such as HTTP2, SSL and compression support. This way the application's main web server can be reasonably simple. This is how ASP.NET core Kestrel web servers work: it's a very simple barebone web server with little to no support for latest and more advanced web protocols. Instead, Kestrel relies on the proxy to offer these services.
So, to answer your question, you can use practically any general purpose web server as your main web server for any programming language/framework assuming the web server is either 1) a proxy to an external web service, 2) the language support is built in or as bundled modules (e.g. Apache+PHP) or 3) supports using interfaces such as cgi/fastcgi (e.g. Nginx+PHP or Apache+Pyhthon). IIS for example can run .NET 4.x apps natively, .NET core using proxy and PHP using fastcgi.
However, entirely different question is whether it's a good idea to combine any language with any web server. Some combinations are badly supported or might have slower performance.
My recommendation is to look at the question from the other end: Choose your language first, then choose from the frameworks available to that language, and then, depending on support, the suitable web server. If you want flexibility, use a proxy. Using e.g. Nginx as a front facing proxy, you can have multiple web servers running using different programming languages on the same computer. With the proxy, all these will play nicely and you can have multiple websites originating from the same IP address.

Related

HTTP/2 with WebForms - What actually does this feature mean to a developer?

I am exploring the current news for ASP.NET WinForms with .NET 4.6.
The resources I am currently looking at is this Video overview by Microsoft Program Manager Pranav Rastogi and an article on DotNetCurry. Besides the information, that I will require Windows 10 Preview, I can not decipher, what this really means to me as a WebForms developer.
To use HTTP/2 will I...
need to make some changes in a config file?
need to change something in the page / master page?
use a different programming model when it comes to serve resources?
Of course, IIS will need to be configured, but this does not affect me as developer.
Is there actually something I need / can do as developer to support HTTP/2?
Note: If someone sees this as a better fit on Programmers or other SE site, please move.
Basically, HTTP/2 is seemless for web services. The basic functions, request/response multiplexing and header compression, are defined at the network protocol level. That means it can be seen as the matter of web browsers and web servers.
But for the new features like HTTP/2 server push and stream priority/dependency, it needs to be considered for developers. To use those features, web browsers and web servers should provide APIs.

What do I need out of ASP.NET and IIS?

I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.

What is the best way to host an ASP.NET MVC6 Application

If I understand correctly part of the motivation of ASP.NET vNext is to reduce overhead. An MVC6 application can be self hosting. My question is what is the best practice way of hosting a ASP.NET vNext application. Is there something similar to the WCF activation services that monitor the health of the service or is there some way of doing this from within the application?
The "best" way to host ASP.NET MVC 6 is to choose the way that best matches your app's needs, of course! But that perhaps isn't so helpful as far as advice goes.
First, you need to consider the requirements of the application, such as:
Does it need to run cross-platform?
Does it need health management?
Does it need to use existing IIS modules?
Does it need to run in the context of another application?
Does it need to use Windows Authentication?
And no doubt many more requirements...
Here's a brief summary of the various hosting options and their pros/cons:
IIS is perhaps the most well-known host. It has been hardened for well over a decade. Many popular modules are available for it, including providing various security features. IIS has built-in support for Windows Authentication, logging, app warmup, health management, remote administration, and lots of other features.
IIS Express shares the same codebase as IIS, but can be run without admin privileges.
Kestrel is a cross-platform web server that is being written as part of ASP.NET 5 and is currently most suited for development work. It's very lightweight, which can be both good (nothing in the way!) and bad (not very many features).
Self-host is where you are master of your own domain. Nearly everything is up to you, including figuring out what should happen if there is an unrecoverable error. Self-hosting is a great option if you need to host a server within your app (e.g. a client app that uses a web server to host UI or services that the app directly uses).
There is certainly no one "best" way to host an ASP.NET MVC 6 app, but there are certainly many solutions catered to a variety of needs.
In my answer to ASP.NET vNext is host agnostic, what does it deeply mean? I covered a few other aspects of host agnosticism.
ASP.NET Core 1.1 Answer
The 1.1 release added GZIP compression and response caching.
Kestrel is still not security tested and should not be used without IIS or NGINX as a reverse proxy. This will change at some point.
Kestrel still does not support HTTP 2.0.
Using IIS or NGINX with MVC 6 is slower than MVC 5. Yes MVC 6 is supposed to be faster but only if you use Kestrel on it's own.
ASP.NET Core 1.0 Answer
IIS or NGINX is by far the best host for an ASP.NET MVC 6 application. Below are a list of features you will not get without IIS or NGINX without lots of extra work. Note that all of these features require a small amount of config in the web.config file.
The Kestrel web server has not been battle hardened and tested for security. It's not supposed to be exposed to the internet...yet.
Kestrel does not support HTTP 2.0.
GZIP compression of HTTP requests for saving bandwidth and better performance. This alone is a big enough reason.
Error handling outside of ASP.NET. What happens when you have a .dll file missing? Well IIS will still show an error page and you can customize the error page too.
Dynamic IP security - During a Denial of Service (DoS) attack, a very simple and small 403.501 or 403.502 Forbidden static error page is displayed.

What are the things missing in Owin/Katana which is available in ASP.NET?

I am looking to build a small ASP.NET application using WebAPI and a html front-end, on .NET 4.0. I need to support authentication, authorization, data access (EF), logging / tracing. It can be an intranet/internet application, so it should support load balancing / clustering.
I am sure if I just go with ASP.NET and IIS I will get all these features. However I like OWINs idea of independent async modules and its goal of being high performance hosting environment. But how much of OWIN/ KATANA is matured and what functionalities are still missing/buggy?
The whole idea of Owin/Katana is to build a light weight server with only the function we need. Your question is better to be "What are things missing in Owin/Katana, which is available in IIS?"
The short answer is, IIS is a full-blown server. Many of the websites we developed only requires a small fraction of all its functions. It is like shipping a bag of grocery using an 18 wheeler.
If you look at Katana, all functions are modular. Say, if I need WebAPI, I can add in that function. When CORS is needed, I will extend appBuilder to the related functions. So in a sense, we have a fully customizable server. Since all functions can be added in, I would say nothing is missing.
Another thing to mention is that an installation of IIS would require you to run a Windows Server. If you are on a Mac or not a server version of Windows, you can host your website on Katana or any other OWIN implementation.

asp.net : How to embed a server.exe?

I haven't put up a web site/app yet, so please excuse my ignorance.
Eloquera looks like a great object database, but the embedded (in-process) mode is not meant to be used for a web app. I have to therefore somehow run the server exe on the server to use it.
When I use the server on my comp it first needs to be allowed through the firewall, as one would expect.
I am wondering if I could somehow run the server.exe in the same process as the web app and still have it be a tcp/ip server accepting multiple connections.
Or perhaps there are normal ways of dealing with this situation on typical "retail" web hosts?
In Short: I believe I am trying to embedd a tcp "server.exe" into an asp.net web application
Seems like the usual thing to do in this situation would be to get a dedicated server, or, more realistically in my case, a VPS (I did say I was learning!).This really pushes up the costs and hassle. No shared hosting that I can see offers Eloquera DB.
So, it seems that my only option would be a low-end VPS.
It's disappointing that I can't use embedded (desktop mode) eloquera in an asp.net web app, but I understand that this is to do with the nature of web apps.

Resources