I am evaluating how is it possible to implement Server Side Rendering in SPA app with React and CMS as backend.
This is the approach I see Next.js suggest to have per-rendered and all most all CMS system suggests:
User request a page from react app running on Node server
Node server requests JSON data from CMS through fetch call
Then React App reads this JSON and transform HTML into String like renderToString() and sends the response back to the user.
The disadvantage of this approach is that if JSON data from CMS is huge then first request takes long time.
What alternate solution do you suggest?
Heyooo, Contentful DevRel here. 👋🏻
your concerns are absolutely valid.
And that's why Next.js just recently added advanced static pre-generation using getStaticProps. The goal is to tackle the long dynamic response times by pre-generating as much as possible. This way the user has a fast initial content paint, but can still enjoy all the dynamic benefits that come with a React application (Next.js usually follows an isomorphic JavaScript architecture)
The processing time you describe then is moved from dynamic request/response time into build-processes.
In general, when you're not dealing with millions of pages, I recommend giving static HTML a try. It makes applications often faster, safer, and more secure. For more complext and larger sites, Vercel is also experimenting with hybrid solutions that offer ways to only pre-generate certain pages. That's all very new though. :)
Related
I apologize in advance for how new I am to this all. I have a new business and there are some things I want to code for it myself as proof of concept till we have enough revenue to actually hire real coders.
Our ecosystem will have 4 major areas and I'm not sure if my approach is how to go about it or even possible.
The normal, static, info webpage that just talks about our business. (SEO and load times important)
A React JS / Next JS non-static section of that same website for blog and other dynamic content. (SEO and load times important)
A react JS employee backend for customer tracking and another tracking of customer data. (SEO and load times not as important here).
A customer portal where they can log in and see stats and stuff about their account (this will pull from data we enter in the employee backend and they can access to track progress) (I would eventually like android/ios apps as well as web portal for this so I was thinking using react-native / react-native web for this section to try and maximize code reuse. (SEO not important, but a smooth experience is)
I planed on using firebase to host it all. I'm curious if this seems it can work? Can you combine all of these different frameworks and strategies in one overall project like this without causing over bloat of download and such? Like for example, the employee backend will likely have a lot of packages and dependencies that the static front end would not require. And the static frontend would be in the same project as the dynamic blog but be built on different things (one static HTML, the other react with next.js? is that a bad idea?). Also, it's been hard to find info on exactly how goog react-native-web is so I'm just lost with this all and would love some guidance. Thank you so much in advance for any direction you can offer.
With firebase hosting you can host static sites, and redirect some paths, such as /api/* or /dynamic/* to firebase cloud functions.
On those cloud functions, you can do dynamic rendering, e.g. with remix.run or next.js.
If you use good cache-headers on those cloud functions, firebase hosting caches the results appropriately, making dynamic rendering of all pages feasible too.
Using a client side routing server side doesn't forge entire page to serve a client, but datas are downloaded from webapp "on demand".
So, in this scenario, if you see html code you could see something like this below:
<body>
<div class="blah">{{content}}</div>
</body>
I know that prerender strategy can be used and i think that probably google crawler is very smarty and can see contents anyway, but the question is:
is it good this approach on seo side?
Using prerender strategy server needs to generate page with content. Could be that a penalty in page speed factor?
Thank you in advance to everyone.
As you've mentioned google is pretty smart and from a recent experience, is able to fetch some of your site's static content even when using client-side rendering. However when it comes to client-side routing it's not quite there yet so if you need to have SEO, server side rendering frameworks like nuxt.js should be your go-to.
but datas are downloaded from webapp "on demand"
The same thing applies when you do asynchronous fetches (download on demand as you've described it), imagine the data inside your {{ content }} was coming from an external API, as far as I'm concerned no crawler at this time is able to deal with this, so your content area would just be empty. So generally speaking, when SEO is an requirement, so is server-side rendering.
Using prerender strategy server needs to generate page with content.
Could be that a penalty in page speed factor?
Yes and no. Load times will certainly go up a little, but when using client-side rendering, the client needs to render the page after loading it, so this time just gets shifted to your server. This applies again to asynchronous data fetching. The delivery of the site will take longer, but the data it has to fetch will already be there, so the client wont have to do it (SSR frameworks allow you to fetch data and render it before sending the site to the client). If you accumulate everything, there shouldn't be a huge difference in time from sending the request to actually seeing the rendered page in your browser.
I've got an old app I wrote in Node, Mongo, Express and Handlebars. It seems to be a bit outdated in the sense that it was more static and all data was called locally off the same domain and rendered with Handlebars on the server side, which I thought was always necessary for SEO and it wasn't built with the idea of later building and connecting the data to a mobile version.
I've been using React a lot lately as well as looking into building mobile apps and with the tutorials out there, it seems like most apps these days are designed in a way that the backend is mostly a remote api with cross site origin requests enabled and a frontend that just gets the data from it and parses it on the frontend whether it's a desktop client or a mobile client.
What would be the best way to modernize my old app that'd keep it rendering on the server side using react instead of handlebars for SEO, while also having an api service for if I were to develop a mobile version that could get and parse the data?
There's a lot of server side rending react tutorials out there, but I'm not sure what the best approach is.
To turn your current app into a SSR (server side rendered) react application would be a big ask.
You would have more luck ripping out the html / handle bars response and just returning JSON instead, effectively turning it into an API.
In terms of adding a SSR react layer, the easiest option would be to use something like Next.JS. This does the heavy lifting for you to create server side rendering. There are plenty of other options out there but Next is one of the best and probably the easiest to get going with.
You would then make API calls from your SSR Next / React app to the Node API.
You can reuse the same API for a mobile application if you chose to go down that path at a later stage.
You would then make API calls from your SSR Next / React app to the Node API.
You can reuse the same API for a mobile application if you chose to go down that path at a later stage.
What is the point of server side rendering in React/Redux?
It would seem to me that another level of complexity is being added to the software, but I don't really see the benefit of it.
What are some common use cases for server side rendering?
React's SSR (Server Side Rendering) offers some benefits over CSR (Client Side Rendering):
1. Improved (Perceived) performance at the client side
Obviously, rendered components are shown to the user right away without the need to wait for browser to render. The website won't be interactive until all React code are loaded and executed, but the perceived performance is improved by showing content to users ASAP.
2. Better SEO
Since content are rendered at the server side, search engine crawlers can see the rendered content instead of just a blank page with JS tags.
Note: Google crawler supports JavaScript rendering, not sure about other Search Engines though.
Interms of complexity - yes, SSR introduced extra complexity but there's always a tradeoff for each technical decision.
The whole point of so called Universal apps or "Isomorphic JavaScript" is its "write once, run everywhere" kind of motto. Meaning that you wouldn't need to maintain a specific backend project and a specific frontend project differing in techniques and instead consolidate a whole JavaScript project into one.
It's not quite as dandy as you'd think because you still need to maintain a backend specific part that handles the initial GET request.
Furthermore you also leverage the Single Page nature of an application whilst getting the server side first page load making your website 100% crawlable by the Googs, even though Google now crawls SPAs quite competently currently.
As for complexity - it could be as complex or as simple as you would want to, I guess. Not everything is solved by doing a "Universal app" nor is everything solved by doing a standard web app either.
I'm new in MEAN stack area and I have some doubts related to Angular routes. Why should I recreate on the client side the routes already made in backend with express.js, what are the benefits? Is this the only way how Angular.js works? I saw some examples with Jade.js and it wasn’t necessary to recreate the routes on the client side, making the things simpler.
Thanks!
Disclaimer: I haven't specifically used Angular myself, but I have used Backbone.js for the same purpose, and the same arguments apply.
There are many use cases where it makes sense to define routes on the client side, not the server side. For instance, I do a lot of work with Phonegap using Backbone, and the architecture is generally a REST API for the back end, and the data gets used to render the pages on the client side. This approach has the advantage that it reduces the amount of data sent over the network, generally making the app quicker. Client-side routing also preserves browser history when compared to just updating the existing content via AJAX.
Ultimately, it's something you have to consider on a case-by-case basis. For something that's very dynamic, building it as a single page web app with client-side routing may make sense. For a more traditional web app, such as a blog or ecommerce site, you're probably better off defining routes on the server side.