I am kind of in cross roads in the process of understanding the basic difference between Client Side Rendering and Server Side Rendering. After doing significant amount of research, here is my understanding
When we render on to the server it means:
You have a local server say Apache Tomcat, You host a web application
by clicking the run on server, It renders your HTML on the server.
I understand this completely. Now here starts my confusion:
Client Side Rendering?????
You host a web application without a local server???
I might be wrong, but this is what the conclusion it is taking me too.
I know, ReactJS does both serverSide Rendering and Client Side Rendering. However, I am not getting the basic difference between both these renderings.
Any help would be highly appreciated.
"Rendering" in this context means "Assembling the document from various component parts".
With server side rendering, you would do all that on the server and then send a complete HTML document to the browser.
This is:
Traditional
Robust
Search engine friendly
With client side rendering you would use client side JavaScript to load a template and some data (using multiple requests) and then put them together in the browser to form a DOM and create a page.
This can provide performance benefits for subsequent pages (since less data is being fetched for them) although the cost of bootstrapping the initial page is usually higher.
Lack of robustness and search engine friendliness can be compensated for by combining the techniques. A new request for a page (any page) uses server side rendering, but following links trigger JavaScript to involve Ajax, the History API, and client side rendering. If you use server side JavaScript, you can reuse some of the same code for both (this is sometimes called Isomorphic JS).
Related
I am very used to the approach where SSR meant that the page got a full refresh and received a full HTML from the server, where it gets rendered with razor/pub/other depending on the backend stack. So every time the user would click on the navigation links, it would just send a request to the server and the whole page would refresh, receiving a new HTML. That is the traditional SSR which I understand.
With SPA however, we have for example react or angular, where we receive almost empty HTML on the beginning and then the JS so that the whole app gets initialized on the client side. We can then have some REST API to get json data and render views on the frontend (client side routing and rendering) without any page refresh. We don't even need any server really.
Now, what I have a problem understanding is how SSR (such as next.js) works with react.
From what I am reading, the first request returns full HTML+CSS (which helps with SEO etc - I get that), but what happens later? What happens after that first/initial request? Does the whole react app initialize in the browser and then it just behaves EXACTLY as if it was a normal SPA (meaning we have client side routing and rendering from now on, without any need to make requests to that server)? In other words, does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?
I spent lots of time reading but all the articles mainly focus on the initial request and SEO and time to first byte, paint etc. and I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.
does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?
You got it right. The first (initial) request is handled by the server and after that the frontend handles the routing (at least in the case of Next.js).
If you want to see an example OpenCollective is built with Next.js. Try playing around with it and see the Network tab in the DevTools.
I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.
It is called SSR because the app is effectively being rendered on the server. The fact that frontend routing takes over after the initial render doesn't remove the fact that the server did the work of rendering the app as oppose to the user machine.
That's Not all the things that happen with Next.js, In Next.js You can build something called Hybrid apps.
In traditional SSR, all of your client requests get handled by the server. Every request goes to the server and gets responses.
In classic CSR with something like React, as you said, all the things happens in the browser via the client-side javascript.
But, in Next.js you can define three different approaches (mainly two according to the docs) for pages to get delivered.
based on the app needs and requirements, you can serve a couple of pages in pure traditional SSR mode, a couple of them in classic CSR mode, and a couple of in SSR mode via dynamic data that get fetched and rendered into the pages on the fly.
these features bring lots of flexibility to design a web-app that behaves perfectly in every different scenario that is needed.
This is kind of a weird question I think to ask, but I have browsing about for the past some time and cannot find a clear definite answer.
I understand that a client connects to its own server and communicates with the web-server through sockets and I kind of see how that works in php (I have never used php but have used sockets before so I understand the concept).
The issue is I'm trying to get a real view of this.
The question is, do websites generally use sockets and contact a web-server to fetch data or the actual html? Or is it a rare choice made in some areas?
If it is generally used, then is the "real" js usually in the server? or is it client-side (for performance sake)?
Context:
Let me explain a bit where I'm coming from, I'm not a web expert, but I am a computer engineering student so most concepts are easy to understand. A "real"-er view of this would be very helpful.
Now, onto why I'm asking this. I'm developing a web-app as part of a project and have done a fair bit of progress on it but everything was done on a local dev server (so basically a client?)
I've started wondering about this because I wanted to use a database for my website and since I want to connect to something, I will need to connect to a web-server first (for security sake).
My question's intent is to guide me on how and most importantly, where, to setup this server.
I don't think showing any code would be of help here, but assume I have my client running on localhost:1234, my database on localhost:3306, I think I should have a web-server on another port so I can establish this communication, but I want to do it in a clean and legitimate way so all of my current solutions can be ported online with little to no changes (except the obvious)
There's a bunch to unpack here.
First of all, servers can be distant or local. Usually they are distant, local server are mostly used for development purposes.
Even if your server is on your local machine, it still isn't the client. The client is the part that is connecting to your server. For web development it is usually the user browser.
Javascript is a language that can be used server-side, with a NodeJS server, but more often client-side, in your user browser.
Your website, or web application, communicate with your server through various means. Most common one is the HTTP protocol, used to make server requests such as data request to populate your page (in case of an API server, REST or otherwise), or simply request the actual page to display in the browser. The HTTP protocol works by resolving URLs, and making requests to your server registered to this url using special methods such as GET, POST, DELETE, etc...
Sockets are used to create a persistent connection with your server that works both ways. It is mostly used for realtime updates, such as a live chat, as it allows you to push updates from the server instead of having the client request everything.
In most cases the database can be found on the same server as the one serving the website or application, as it is a lot easier to handle, and often faster without the extra networks requests to get the data. However it can be placed on another server, with it's own API to get the data (not necessarily web related)
Ports such as 1234 or 3306 are often used for local development, however once your move your project to a host service, this is usually replace by urls. And the host service will provide you with a config to access the associated database. Or if you are building your own server you might still use ports. It is heavily dependent on your server config.
Hope this clear some things up.
In addition to #Morphyish answer, in the simplest case, a web browser (the client) requests an URL from a server. The URL contains the domain name of the server and some parameters. The server responds with HTML code. The browser interprets the code and renders the webpage.
The browser and the server communicates using HTTP protocol. HTTP is stateless and closes the connection after each request.
The server can respond with static HTML, e.g. by serving a static HTML file. Or, by serving dynamic HTML. Serving dynamic HTML requires some kind of server language (e.g. nodejs, PHP, python) that essentially concatenates strings to build the HTML code. Usually, the HTML is created by filling templates with data from the database (e.g. MySQL, Postgres).
There are countless languages, frameworks, libraries that help to achieve this.
In addition to HTML, the server can also serve javascript that is interpreted in the browser and adds dynamics to the webpage. However, there could be 2 types of javascript that should not be mixed. NodeJS runs on the server and formats the server response, client javascript runs on the browser. Remember, client and server are completely isolated and can communicate only through an HTTP connection.
That said, there ways to make persistent connections between client and server with WebSockets, and add all kinds of exotic solutions. The core principle remains the same.
It does not matter if server software (e.g apache, nginx) is running on your local machine or anywhere else. The browser makes a request to an address, the DNS and network stack figures out how to reach the server and makes it work.
We are developing Android mobile app that will have about 8-10 screens with about 10 fields on each screen. On each screen we need to "submit" data to server. Where we should perform validation related to length, format- on server side or app side? If we do it on app side, we have a limitation to do it using JavaScript. We want views in consideration to performance impact and ease of debugging.
You should validate both on the client side and server side.
Client side:
Validating on the client side makes you application snappier because you'll not have to wait for the response from the server before showing any information about incorrect format, length or required fields to the user. It also enables you to handle validation in real time which will result in a much UX. I don't understand why you would do it with javascript of you are writing an Android application. This article has some information about it.
Server side:
This is where you guard against incorrect data. The checks on the server side will almost never be needed because they've already been made by the client. The checks are simply there to prevent anyone from circumventing the client side checks and passing bogus data.
If you only want to or can implement one of these it should be the server side checking.
Complexity of UI logic is common problem. But it is obvious that you should organize your code in the way when you can add any checks. To debug application (running on phone) you can try to use Android 4.4 and remote debugging of WebView.
Also I guess you should perform validation on server side. Logic must accept or reject data incoming to chain of processing. Also it can be possible that somebody will call your logic, not only your own app.
The best solution is to perform a double validation, both on client and server side.
Assuming that data validation is a simple CPU bound operation, and can be quickly done by any mobile device in a reasonable time (i.e. not impact on performances), a first client-side validation prevent your app to perform potentially useless network requests, which means network useless traffic generation and depending of the user's contract with his Telco operator may imply a cost. Plus, this is an extra effort for your backend system to process invalid data, and even if one single validation is a simple operation, since you may (hopefully) have many application instances installed on several devices this effort will be multiplied and cause a big load for the server.
Nonetheless you can't avoid a final server side validation, cause we live in the real world and not in an ideal one, and any client side operation can't ever be considered safe at all!
The technology you are using (javascript in your case) does not affect or influence the above considerations! All technologies provide sufficient ready-to-use validation and debugging tools!
I want to use markdown in a website, I'm wondering about convert markdown to HTML client side or server side. I'll use https://github.com/evilstreak/markdown-js that has both client/server libraries. (node.js)
I never used markdown before and I'm wondering about the efficience of the two ways, the security too, because I don't want to have html tags from users (injections)
Do you have any advice or explanation about why do it client side or server side? Thanks.
If you're looking for efficiency, you should use the same module to render at both server-side and client-side.
Server side rendering is needed for initial request, and if your data is updated somehow by user, it needs to be re-rendered at the client-side.
Reasons:
client-side rendering is too slow for initial request because user needs to fetch all libraries first
server-side rendering is too slow for using after the page is loaded because it needs additional requests
I am new to the REST world. I am writing an ASP.NET MVC application. My requirement is to make a few REST calls from the client. I can either choose to make these REST calls from Javascript or I can do that in the C# code in the Controller. Which method is recommended? According to my understanding, the Controller runs on the Web Server and the Javascript runs on the browser. So is there any perf degradation if the REST calls are made from the Web Server.
Can someone suggest me the general practice around this? Are there any security gotchas for the same?
Thanks
Let us consider the pros and cons of doing this Server side
PROs:
You can do other processing on the data using the power of the server
You are not subject to cross domain limitations like you would be in ajax
Generally you do not have to worry about your server being able to access the resource, whereas on client you are at the mercy of users net restrictions, firewalls etc
More control over your http response\request lifecycle
CONS:
You will have to consume more bandwidth sending the resulting data down to the client.
You may have to do more work to leverage good caching practices
Dependant on having certain server side libraries\framework elements
Now although we have a much bigger list of Pros than cons... in the majority of cases you will still want to do this on the client... because the issue of double handling the data is actually a very big one, and will cost you both time and money.
The only reason you should actually do it server side is if you need to do extensive processing on the data, or you cannot circumvent CORS (cross domain) restrictions.
If you are just doing something simple like displaying the information on a webpage, then client side is preferable.
It strongly depends on your situation. If you simple display this data in your page without any actions, you can get it from javascript. If you want to work with this data, transform it, join it with other data or else, i recommend do this operations on server so get this data on server too.