When to use "client-side routing" or "server-side routing"?

Question

I'm a little bit confused about this, and I feel slightly stupid asking this question, but I want to understand it.

So, say I'm working with a client side web framework, like Backbone, Angular or Durandal. This framework includes routing.

But I of course still have a server for database stuff, and so on, which also has routing.

My question now is:

When to use "client-side routing" or "server-side routing"?

How is it "decided" whether routing is already performed on the client side or whether the request is first sent to the web server?

I have a particularly hard time imagining this because the client side could do routing before the server ever gets to know about that request.

I'd be very thankful if someone could explain how these two routing systems work together.

P.S.: I have not included code samples because I'm not looking for an answer concerning a particular framework, but concerning the routing process in general.

Yvonneyvonner

What exactly do you mean by server-side routing? Do you mean hitting an http endpoint defined by your API, or an http endpoint defined by your database's API? Routing on the client side involves the UI; routing on the server side usually involves the resources that drive the UI, or that are driven by the UI. Could you possibly provide a hypothetical scenario? – Aseptic

I first came across this when looking at this project: github.com/mikefrey/noah-challenge.git. He does some routing using Angular and some routing using Koa (server-side, like express). – Yvonneyvonner

I have a similar understanding problem. I´m trying to build a SPA and I´m currently using sammy.js with php in the backend. Now I´m thinking about switching from PHP to Node.js, and there is Express.js, which seems to do exactly what Sammy.js does, but on the server side... confusing – Stanfordstang

Answer 1

tl;dr:

• with server-side routing you download an entire new webpage whenever you click on a link,
• with client-side routing the webapp downloads, processes and displays new data for you.

---

Imagine the user clicking on a simple link: <a href="/hello">Hello!</a>

On a webapp that uses server side routing:

• The browser detects that the user has clicked on an anchor element.
• It makes an HTTP GET request to the URL found in the href tag
• The server processes the request, and sends a new document (usually HTML) as a response.
• The browser discards the old webpage altogether, and displays the newly downloaded one.

If the webapp uses client side routing:

• The browser detects that the user has clicked on an anchor element, just like before.
• A client side code (usually the routing library) catches this event, detects that the URL is not an external link, and then prevents the browser from making the HTTP GET request.
• The routing library then manually changes the URL displayed in the browser (using the HTML5 history API, or maybe URL hashbangs on older browsers)
• The routing library then changes the state of the client app. For example, it can change the root React/Angular/etc component according to the route rules.
• The app (particularly the MVC library, like React) then processes state changes. It renders the new components, and if necessary, it requests new data from the server. But this time the response isn't necessarily an entire webpage, it may also be "raw" data, in which case the client-side code turns it into HTML elements.

Client-side routing sound more complicated, because it is. But some libraries really make it easy these days.

There are several upsides of client-side routing: you download less data to display new content, you can reuse DOM elements, display loading notifications to user etc. However, webapps that generate the DOM on server side are much easier to crawl (by search engines), thereby making SEO optimization easier. Combining these two approaches is also possible, the excellent Flow Router SSR is a good example for that.

Derose

I have a curiosity regarding with client-side routing the webapp downloads, processes and displays new data for you. If I have a 200kb script for each page (considering that 120kb is React itself), doesn't this mean that having client-side routing will download a 1.5MB script even if the user will not access every page? – Kaylenekayley

No. If you have a 200k client script in case of client-side routing, that's for the entire webapp, usually containing the code for every page and the complete business logic. You don't need to embed React in all the pages separately. There's (usually) only one common instance of each JS library in the entire app. – Derose

You know very well that writing a React component without import React from 'react' won't work, so it must be imported in every component I write. But the 200k script is for one page in the case of server-side routing. – Kaylenekayley

I'm not entirely sure I understand your problem. The import directive doesn't embed a new instance of React in every React component. But the client-side code contains the logic for all pages, even those that the user doesn't visit, if that's your question. – Derose

But the client-side code contains the logic for all pages, even those that the user doesn't visit, yeah this was my question, because it seemed like useless traffic is done. I know React is not embedded in every component, but I calculated the size with something like reactSize * a theoretical script size (100k) * theoretical number of pages = 1.5m. Thank you for clarifying that for me! – Kaylenekayley

You assume that the average custom script is about the size of React itself, per page. That's a lot. I believe the sum of all custom scripts is usually only a fraction of the libraries they use. Add to that that the client doesn't have to download the entire HTML markup upon in-page navigation, and you'll find the traffic at least comparable, possibly even less. – Derose

@Derose thanks for greate explanation, When creating a SPA there are routes that are only known to the browser. For example, '/customer/21', If this route is entered manually what will happen or how can we handle this (actually I'm having problem in understanding what this library actually do github.com/johnpapa/lite-server) Any Help is appreciated – Sharlasharleen

If you enter an URL manually, a request is made to the server. The SPA is downloaded as usual, and then the router library initializes the state of your app based on the URL. You can't catch or override this, because it's not a DOM event. – Derose

Answer 2

I think client side routing is used by single page applications, where the actual site is never left.

Routing works by attaching to the current page, where client-side routing frameworks react on.

index.html#/mysubpage

Server side routing is similar to what apache does by default when calling a subsite by it´s url, but node.js does that by using routes because the html files need to be rendered first.

If you have a SPA with a client side routing framework, and you are using Node.js, you still need server side routing to switch between sites

Theologue

Answer 3

Modern applications often use both client-side and server-side routing in a "mixed" or "hybrid" way so it is quite hard to draw a line between these two techniques.

To better understand when and how to use server-side routing and client-side routing, you probably have to figure out what it happens when you have a large application that is used to manage a large manufactoring company (this does NOT happen very often in the real world. It is just a useful example).

In these cases, you will likely have different people (with different roles) who see different parts of this complex environment (different aspects or domains). For example, an engineer would see a file server with a lot of digital documents while the people working in the company canteen would see the menu to be prepared, the working schedule and the store. These are totally different application "domains" that requires totally different UIs so it makes sense to serve different SPAs to each type of user.

In this case, you could use server-side routing to serve a specific UI (SPA) to a specific user while you could use client-side routing to navigate inside this UI (and to load data). Think to these SPAs as "dashboards" or "control panels" devoted to specific "tasks" and used by specific types of "professionals".

For example, you could have a /myapp/engineering route for all of you engineers and a /myapp/canteen for all of your canteen staff. Each of these URLs would represent a specific domain and would serve a specific dashboard to a specific type of user. These URLs would be managed server-side.

Instead, you would use client-side routing to navigate inside each of these dashboard, loading data and re-configuring the UI as needed.

Of course, your app would probably also have a RESTful API used by your SPAs to fetch the data they need. The URLs belonging to the REST API must be managed server-side to perform their job (even if they are NOT associated to real HTML pages) and are invoked only by your SPAs "behind the scenes". They usually are kept in a separated "domain" like /myapp/api .

The same happens with static web page (like the "contacts" page and "about" page) that are usually kept in a /myapp/static folder (or "domain") and managed server-side (this folder or "domain" can be - and often is - hosted on a different server).

So, you should probably use server-side routing to separate applications domains from each other and client-side routing to navigate inside each domain.

Blinders