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

I got a little confused about this, and I feel a little silly asking this question, but I want to understand that.

So let's say I work with a client side web map like Backbone, Angular or Durandal. This structure includes routing.

But I, of course, have a server for the database, etc., which also has routing.

Now my question is:

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

How was the decision made whether routing is already done on the client side or is the first request sent to the web server?

It is especially difficult for me to imagine this, because the client side can perform routing before the server finds out about this request.

I would really appreciate it if someone could explain how these two routing systems work together.

PS: I did not include code examples because I am not looking for an answer about a specific structure, but concern the routing process in general.

+47
web-applications client-side server-side routing
May 31 '14 at 22:56
source share
2 answers

TL; DR:

  • with server-side routing, you load an entire new web page whenever you click on a link,
  • with client-side routing, loading, processing and displaying new data for you.



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

In a web application using server-side routing :

  • The browser detects that the user clicked on the 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 completely discards the old web page and displays the recently loaded one.

If webapp uses client side routing :

  • The browser detects that the user clicked on the anchor element, as before.
  • Client code (usually a routing library) catches this event, detects that the URL is not an external link, and then prevents the browser from making an HTTP GET request.
  • The routing library then manually changes the URL displayed in the browser (using the HTML5 history API, or perhaps hashing URLs in older browsers)
  • The routing library then changes the state of the client application . For example, it can modify the original React / Angular / etc file according to the rules of the route.
  • The application (in particular, the MVC library, such as React) then processes state changes. It displays new components, and if necessary, it requests new data from the server. But this time, the answer is not necessarily a complete web page, it can also be raw data, in which case the client code turns it into HTML elements.

In contrast, client-side routing is complicated because it is. But some libraries really make these days easier.

There are several aspects to client-side routing: you download less data to display new content, you can reuse DOM elements, display user download notifications, etc. However, web applications that generate DOMs on the server side are much easier to crawl (by search engines), thereby simplifying SEO optimization. A combination of these two approaches is also possible; an excellent example of a Router SSR is a good example for this.

+43
May 6 '16 at
source share

I think that client-side routing is used by single-page applications where the actual site never remains.

Routing works by joining the current page on which the client-side routing framework responds.

index.html # / mysubpage

Server-side routing is similar to what apache does by default when a child node is called at its URL, but node.js does this using routes, because html files must be displayed first.

If you have a SPA with client-side routing infrastructure and you use node.js, you still need server-side routing to switch between sites.

+3
Dec 06 '14 at 18:45
source share



All Articles