Why Build a Web Server?

Modern web application development frameworks such as ASP.NET and its three flavors (Web Forms, MVC, and Web Pages) and non-Microsoft products such as Ruby on Rails all sit firmly between the web server and you, the web application builder. In the Microsoft world, we’re used to working with IIS,[10] whereas in the Unix world, Apache[11] and Nginx[12] are commonly used.

Rails says this about itself:

Rails is a web application development framework...designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks…Rails is opinionated software. It makes the assumption that there is the "best" way to do things, and it's designed to encourage that way—and in some cases to discourage alternatives.[13]

Microsoft says this about ASP.NET:

ASP.NET is a unified Web development model that includes the services necessary for you to build enterprise-class Web applications with a minimum of coding.[14]

And, with regards to ASP.NET MVC:

ASP.NET MVC targets developers who are interested in patterns and principles like test-driven development, separation of concerns, inversion of control (IoC), and dependency injection (DI). This framework encourages separating the business logic layer of a web application from its presentation layer.

By dividing the application into the model (M), views (V), and controllers (C), ASP.NET MVC can make it easier to manage complexity in larger applications. With ASP.NET MVC, you can have multiple teams working on a web site because the code for the business logic is separate from the code and markup for the presentation layer—developers can work on the business logic while designers work on the markup and JavaScript that is sent to the browser.

We can see right away that developing a web application is typically entangled with an opinionated framework that attempts to dictate how you should build that application.

While it’s a lot to take on at the beginning of this book, I would like to mention early on that there are additional complexities that affect the entire decision-making process as to which server and server “tool set” one chooses. For example, one can usually choose from a variety of view engines. A view engine is a server-side processing tool for creating dynamic webpages using a specific markup syntax, often leading to what is affectionately called “tag soup.”[15] For example, Razor,[16] introduced in 2010,[17] is perhaps the in-vogue view engine that can be used in conjunction with ASP.NET MVC (at least at the time of this writing). Rails comes with its own view engine and supports other view engines such as Slim,[18] one of more than 24 different template engine offerings[19] in the Rails community.

Another consideration is that these frameworks come with their own ideas of how you should interface with a database. In other words, there is a strong push toward using an Object-Relational Mapper (ORM). In ASP.NET MVC, the preferred ORM is Entity Framework, and with Rails, the ORM is implemented with Active Record.

What does all of this have to do with writing your own web server? According to Wikipedia, “the primary function of a web server is to store, process, and deliver web pages to clients.”[20] This, in my opinion, is not actually correct, but it is accurate with regards to today’s concept of a web server. It’s not correct because technically all a web server should do is hand off the incoming request to a worker process—the web application—and respond with whatever the application returns. However, Wikipedia’s comment is accurate in that we see an entanglement of the concept “web server” with the supporting “server framework” and “web application.”

In other words, serving content to a browser actually involves three pieces:

6. The web server (managing workers, also known as threads), and possibly handling upfront things like white lists and black lists.
7. Based on the request syntax, processing that request into meaningful entities such as session state and routing.
8. The application-specific response to a route, an authentication request, and so forth.

Once you move into item #2, you pretty much immediately encounter the opinionated framework. There really is no middle ground that provides a minimal but useful implementation for item #2, and that’s what this book addresses. This book is about creating that middle ground. In this book, we look at options for threading and options for work processes, and we also provide flexible but minimal scaffolding to support application development, providing features such as session management, routing, and security. Implementing an application with the web server presented here puts you closer to the metal (which actually translates to higher performance and less code) without enforcing overly opinionated implementation requirements.

At least, that’s my opinion!