Web API service on NGINX

Animation is one of the hobbies I enjoyed watching. When I watch it, I have a lot of memorable moments that left deep traces and emotions. Sometimes a word in the film is sometimes a character’s laughing crisis or a dramatic incident. I recently watched the Sing movie, which I had watched for a while, as one of my long-time books. Buster Moon, who can not get rid of troubles with the bank due to financial problems, writes the following sentence in a point where film in is full of all hopes;

“When you’ve reached rock bottom, there’s only one way to go, and that’s up!”

When you go down to the bottom, there is only one way to go, which is, “YUKARISIIII!” If I do not remember what it was like. I can say that the end of 2017 and the beginning of 2018 are similar to what it is supposed to mean. Now we are connected to your central studios.

In a time when I was working on some time, I was trying to customize the Authorization mechanism of a REST service written in WCF and host it over IIS via SSL. It was easy to handle the authorization process by writing the service, throwing it to IIS, generating an experimental certificate on IIS side, making the site callable via SSL, and deploying the ServiceAuthorizationManager derivative class. By a few minor tweaks I found myself in the test case. However, I was in the process of getting mistakes while your service was approaching the foot. At the end I came to a point where I was bored and struggled with the script that I had and worked on.

I said to myself “I’m going to try this on West-World or Gondor.” Both were computers with Ubuntu 16.04 versions. I leaned on the arms and headed to the terminal to create a Web API service. However, there was a serious problem. Linux and IIS. Ovv yooo … Of course there can not be such a union. The alternatives at hand were obvious. Apache Server, Lighttpd and Nginx. Nginx was when I stopped watching. The subject came to a different place, of course. My current goal is to host a sample Asp.Net Core Web API service on the NGinX environment I will build in West-World.

nginx

Nginx (pronounced Engine X) Kazakhstan Almaty-born computer programmer Igor Sysoev (has sys in sibling)It is an open source web server developed in 2002 and produced in 2004. Originally developed as mail server for mail.ru, it has become a product that can work much faster than Apache for web sites by acquiring much wider capabilities afterwards. Compared to products like Apache and Lighttpd, which I have not yet verified but which are equivalent to some generally accepted performance tests, they provide very high response times and minimum memory consumption. We can say that these angles are very popular. There are basic features such as Load Balancing, Virtual Host, Automatic Indeing and Reverse Proxy.

I keep reading the details of Nginx’s development story. It was originally developed in response to a so-called C10K problem. C10K, eleven simultaneous demands of being expressed as a web server can not remove formidable ( this address from you can document about the subject Kegel) In other news, Nginx, Apache mainly being compared with. The most notable difference is Apache’s use of the Single-Thread operating principle at the point where Nginx welcomes requests while running Multi-Thread.

Setup

I have always kept the way to my working room with these considerations. The purpose is to host a simple Web API service on nginx (which will be produced in standard template) . I have to set up NGinx in West-World before. I performed the installation steps from the terminal using the following commands.

After installation with install command, we start nginx service with start. With status we also see the current status. It is nice to see the active (running) font in green color.

Routing Settings

After Nginx is installed I need to make a setting to work as Reverse Proxy Server. On this page, requests to the Nginx server will be forwarded to the address of the Kestrel server where the Web API is located. Of course the opposite is true of course. In fact, the client will not be aware of anything. The HTTP calls made to the Web API from the browser will actually be served by the Nginx server and flow to the actual Kestrel runtime at the back. On top of that I opened the file / etc / nginx / sites-available / default with gedit and made the following arrangement in the contents.