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.
Related
I have external api hosted in the cloud and I would like to write desktop app for management. Last version of electronjs I worked with was version 8 and over that time a lot of changed especially from security perspective. The concept of preload was introduced and I would like to know is it fine to write renderer as react app with redux toolkit and make api calls that way or should I use preload script to get data on the server side.
I would like to know what is a proper way of writing such app.
Yes, it is totally fine to use react and redux toolkit in your renderer.
To quickly get started, you could use something like electron react boilerplate or one of the several other boilerplates available online.
I don't understand why you would want to use preload to fetch from the server.
You can treat the renderer as just another browser instance and make requests to the server directly from your react app using fetch or xhr.
Preload is generally used to run code before the renderer has loaded. I generally use it as a bypass to turning on nodejsintegrations for my electron apps, but you can read more about it in the official docs
I am using React in my project and I have problem with client-side prerendering.
More specifically, it would be necessary to configure SEO
Which is the least painless way to prerender existing reactjs app wiht react-routes
Some examples I have researched:
Gatsby.js - https://www.gatsbyjs.org/docs/porting-from-create-react-app-to-gatsby/
Next.js - https://nextjs.org/docs#custom-document
Netlify - https://dev.to/joelvarty/prerender-your-spa-using-netlify-for-better-seo-3h87
React-snap - https://web.dev/prerender-with-react-snap/
Prerender.io - https://prerender.io/
Keen’s Server Side Rendered - https://medium.com/keen-studio/keens-server-side-rendered-react-wordpress-rest-api-boilerplate-bb58edb7cc0a
Razzle - https://reactresources.com/topics/razzle
React Helmet - https://github.com/nfl/react-helmet
Can anyone suggest what option I should choose that is the least painless.
I have headless wordpress as backend and reactjs client-side as frontend.
Or are there other faster options besides the prerendering?
Thanks.
IMO you really don't need to use a framework to achieve SSR if you want to keep control without turning your codebase into a blackbox and choose your own stack.
I created some boilerplate using Node Express. It supports:
SSR using StaticRouter on the server and BrowserRouter in the client
ES6 webpack transpilation + hot reloading both client and server and auto-updating browser
Redux, data preloading and client store hydration
https://github.com/kimgysen/isomorphic-react-setup
Last time I ran it, I noticed that I hadn't saved the favIcon in the public folder and perhaps there are some minor bugs that I will fix soon (I've fixed them in my projects but didn't update this repo because nobody looks at it anyway (lol!)), but what happens here isn't all that difficult to understand.
I created some basic SSR websites with it in a matter of hours.
I enjoy redux-observable to initiate server ajax calls before rendering the content (using forkJoin), but this is not included in the boilerplate (I haven't actually supported it since I uploaded the first time).
But in terms of setup, I don't really see a point in using a framework for this necessarily, it really isn't that painful / difficult to do yourself.
The benefit that I particularly like is that you don't depend yourself on the scope and dependencies of the framework. You don't get into trouble with things like 'the framework will support this feature or fix that bug in one of the upcoming releases'.
Although ultimately, it comes down to personal choice. So it's not like I want to downgrade these frameworks.
Note: The way Redux achieves pre-rendering is simply by adding Redux store (state) objects to the window object in the html that is sent back to the client.
Then at the client, the it initializes the stores with these objects.
So very simply, this is something that is easy to achieve, even if you decide not to implement any other SSR features.
to create server side applicantion with painless integration you can use my cli to generate a default configuration like create react app cli from facebook, https://github.com/ghondar/crassa
In an article I read that
React uses server-side rendering.
But in another articles I came across this:
Client-Side-Rendering is a relatively new approach to rendering
websites, and it didn't really become popular until JavaScript
libraries started incorporating it into their style of development.
Some notable examples are Vue.js and React.js
Now Which statement is correct?
When I use create-react-app and run npm start, it seems to me that React uses the Client-Side-Rendering. isn't it?
It’s client side. But React, like some other client side libraries, can be used on the server to prerender it with node, usually for SEO.
Out of the box it renders on the client side.
But, if you have a requirement to render pages on a server, you can achieve this with:
Next.js or
Hypernova or any other tool (there is a bunch of them nowadays!)
Note, that SSR will require a bit more experience than a regular React app.
The main goal of this approach is to allow search engine robots crawl information form web pages(SEO).
create-react-app uses client side rendering by default. There are some tools like next js and gatsby js which pre-render pages on the server side. You can also do Server Side Rendering from scratch.
A few years on from the last answer, it is now quite difficult to implement a client-only React app - serving it on Node is trivial and absolutely what it expects, trying to use it as a client library with other server-side support is more of a challenge and documentation about how to do this is patchy and much of it out of date.
In my web app, I don't want to use hash-based routing, I don't want to see any # appear in my URLs. I want to use RESTful URLs, e.g., http://www.example.com/blog/id.
react-router can deal with client-side routing quite well, but if a user hit enter on the browser address bar or refresh the page, the request will be sent to the web server and then the web server has to understand the URL and handle the routing.
Isomorphic is a good solution to this situation since it can render any page on both client-side and server-side. Actually there are many react starter kit projects on Github which claim to be isomorphic.
In my opinion, isomorphic looks beautiful but it's too expensive to write code: you need to make you react components render successfully both on client-side and server-side, which needs developers to make great efforts.
So here is my question, can I just make the react-router be isomorphic, not the entire code?
Yes. You can use react-router for a purely front-end (non-ismorphic) app with HTML5 history.
The routing is determined client side, so react-router will spit out the expected page.
However, whilst you don't need to write any server side code, you will need to configure the web server to point your routes to the correct place. This usually means pointing every single request - or every single valid request - to the same HTML file or entry point. Exactly how you do this depends on what you're using to serve your pages - Express, Apache etc.
I hope that makes sense.
I'm doing some due diligence on backbone for a single page app and wonder if it is possible to re-use the same views/routes from the client on the server side, so that when google visits a pushstate URL, or it is accessed directly, the server can generate the exact same HTML that would be generated by backbone in the client.
It would be a pain to have to maintain two separate sets of views/routes, one on the client and one on the server. I have seen the backnode project on github however this seems to miss the point a bit and you end up having to write the same backbone router twice.
Just wondering how people are generally handling the case when using pushstate urls in backbone and needing to serve the same view from the server? Are people duplicating code or is there a better way?
I haven't tried this yet but these ideas using node.js and backbone might help:
http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
http://bennolan.com/2010/08/13/pushstate-and-nodejs.html
Basically the only way to make it so your not writing the same thing twice is to have both your node.js server and frontend client share the same routing/model code. If you are using something else on the server side (like Ruby) you would have to place node.js in front of your app server. Then make node.js proxy for new clients (push state and client js) and do actually rendering work for old/bot clients.
The other option is doing what jQuery Mobile does which is the Hijax method. The idea to make tons of HTML5 pages (you'll have to look at its routing to see).
And for completeness you should be aware of how google crawls AJAX: http://code.google.com/web/ajaxcrawling/docs/getting-started.html
This project does exactly what you are trying to do. It might interest you to check it out.
https://github.com/developmentseed/bones