Introduction

Finally! Here we find ourselves ready to move into the browser where we can render robust applications that anyone anywhere in the world can interact with! This is an exciting time. But just what is going on here? Where does our application actually exist? How do I get anything to a browser? Well let's answer just that.

Server vs Client

Regardless of the kinds of applications that you build on the web, these two words will be ones that you deal with extensively. The server environment is essentially the big invisible part of the web that hosts or provides access to web applications. This is where all of the files that are used to build your applications live once you are ready to give people access to your app.

The client environment describes any environment that people use to access your applications. Usually we're talking about a web browser when we're discussing the client, but there are others.

So, in short, we put our applications on a server, so that our users can access them via the client.

What happens when I navigate to a website??

So how exactly are these things working together to provide the robust user experiences we interact with everyday?

We start at the Uniform Resource Identifier (URI) which is what you type into your browser to go to different locations on the web (i.e. Google). When you type a URI into your browser, your machine (provided it is indeed connected to the internet) makes a request to your Internet Service Provider (ISP) for what ever exists at that address.

Your ISP doesn't have any idea, however, what that URI means. This is because locations on the web are not identified by those easy to remember names you type in. Locations on the web are identified by Internet Protocol (IP) addresses which look like this: 127.0.0.1. (If you want to know more about how IP addresses work, Wikipedia is actually a great resource) So to obtain this IP addresses, your ISP sends a request to a Domain Name Server (DNS) with the URI that you typed into your browser.

The DNS sends back the IP addresses that is registered to that URI and your ISP then sends that back to the user. Once the requesting browser has the IP address it can make an actual request to that server location. (That IP address actually represents a physical location on a server somewhere in the world) Once the request is received by that server, the application actually decides how to respond.

This response, pending it being valid, usually responds in the form of some combination of HTML, CSS, and JS. The browser accepts these files, pending them also being valid, and renders them on the users screen. The user is then able to click a link and start the process all over again.

MVC

When we're dealing with these worts of requests, more often than not, we're dealing with a Model-View-Controller (MVC) ecosystem. MVC describes a web app paradigm that processes requests through a controller, manages data through a model, and renders all of that through a view layer. MVC based applications use things called (template engines)[https://stackoverflow.com/questions/9547028/what-is-a-template-engine#9547082] to turn dynamic data into static HTML. The one you use will vary based on the programming language you're learning.

The important concept is that in this ecosystem, when our application receives a request from a browser, dynamic data is pulled from a data store somewhere, and passed to a specified template to render that data. The resulting HTML that we get back will have CSS and JS attached to it. Once this process is finished all of that resulting static material is sent from the application to the browser to be rendered. This is what we are referring to when we discuss Server-Side Rendered applications. In these environments, we're only dealing with dynamic data on the server end of the transaction, not in the browser.

Conclusion

Server-Side Rendered applications ae a powerful tool for building web apps because they handle all of the application logic in the controlled environment of the server and pass back fast, efficient static material to the browser when they're done processing. It is a tool that you will use extensively in your career as a web developer.