Server-side vs Client-Side Routing in a Web Application

Routing is the way we navigate through a web application with the help of URLs. By clicking on a certain link, a URL would change which provides a user with some new data and new functionality being shown in a new page. We don't need routing. We could always have an entire application be displayed in a single home page, but if an app starts to become large, this would become quite a bit of a mess. This is why nearly all large-scale web applications we use today use routing of some sorts, YouTube, Twitter, Airbnb, etc. Our tiny house application is going to have routing. And as an example, if the user adventures over to the /listings/toronto route, they would see the listings for the city that they're looking for, Toronto. There are two ways to achieve routing within a web application, server side routing or client side routing. In server side routing, web page navigation is handled completely by the server . When a user clicks on a link, the browser sends a new request to the server to fetch the content of the web page the user intends to view. The pros behind server side routing is that server side routing will only request the web page that the user is viewing, not the entire web app. And as a result, initial page load would be fast because we're only downloading the content for the single page the user wants to see. In addition, search engine optimization is optimized for server rendered apps. The cons behind server routed applications is that every URL change would result in a full page refresh as the server returns contents to the client. This is the unpleasant blinking state that's shown to the user when the user switches routes. Data that doesn't change might be requested over and over again, for example a header or a footer that stays the same in all web pages. In client side routing, web page navigation is handled completely by the JavaScript that is loaded on the browser. When a user clicks on a link, the browser simply renders new content from the code already loaded in memory. Technically, client side routed web applications are often called single page applications because there really is just one web page. The different routes are just the same web page displaying different views. The advantages of client side routing is that because there's no need to wait for a server response after the initial page load, navigating between web pages is extremely fast and there's no more annoying white screen flash when waiting for a new route to load. The disadvantages of client side routing is that the whole web app needs to be loaded on the first request and this is why the initial loading time usually takes longer. In addition, search engine crawling is less optimized. There are some good progress being made on the crawling of single page apps from different browsers but it isn't nearly as efficient as server side routed websites. For our tiny house application, we're going to build a single page app or in other words an app that is client side routed. Let's brainstorm all the routes we need based on what our app tends to do. We'll have about seven defined routes in total. The index route, the host route, the listing route, the listings route, the user route, the login route and the stripe route. The index route would display the home page. This is where we'll have our landing page that explains our app as well as links to like popular cities, the premium listings and so on. The host route would allow our users to create new listings. The page displayed here would check if a user is logged in and if the user is connected to our third party payment processor, Stripe. The listing route would display the details of a single listing. This route would take an ID as the route parameter. If the user is looking at their own listing, the listing page would also display sensitive information such as the bookings that have been made for this listing. The listings route would display all the listings matching some users submitted location. For example, in this case we're showing the listings of Toronto, which is the value of the location route parameter in the listings route. The user route would display the details of a single user. This route would also take an ID route parameter. If the user is looking at their own user profile, the user page should display sensitive information such as the income that has been made. The login page would allow the user to begin the login process with Google authentication. In addition, the login page is going to be the redirect URL where Google OAuth will send a code that will use to authenticate the user. The stripe page will be the redirect URL that stripe would return with a code and will use to communicate with our node server project and authenticate our user. Unlike the login page, the stripe page would only be used for the redirect. So if the user attempts to access this route manually, we'll simply redirect them elsewhere. And finally, the not found page would be the page shown if the user attempts to access any routes we haven't established as a route of our application. Great, we'll get a better understanding of each of these routes and the requirements needed for each of these pages as we begin to build them in this course. [BLANK_AUDIO]