I was just wondering, that since react is/has
- ES6 compatible
- NPM support
- Request Support
Consider the case where we have a UI based interface to some data that is in a different website, where we use APIs/requests to fetch data and render it to the frontend. Can react be used as a standalone frontend+backend solution for small task stuff?
Since react has it's own routing mechanism, can the processing that an express app does be done via imported libraries in react itself? Assume that the size transferred in requests is very less and processing the response is basic string manipulation/html parsing, and there is no requirement for a database, the client's storage should do.
Why did i think of this? No need to maintain a server that acts as a middleware to the react app.
EDIT: For such an app, compile the code into react native, and every user who uses the app is their own server. Possible?
Thoughts?
Top comments (7)
I don't understand, you want to use React components as "partials" in a template? Or instead of HTML responses? Or instead of an encoding format like json/xml?
React doesn't need a server, you can make static websites with it (as in no server/ajax involved), you can import react from a CDN and generate the content "dynamically".
Can you give an example?
Consider that I want to extract information from a table that is present on a site somewhere else, and render the info as cards or something. In a way, the express app for the same would send requests and fetch html responses, which are translated into JSON responses and sent. I was just asking how feasible it is to parse the html grammar inside of the react app itself, after receiving a response from the website.
About the server, I was thinking of compiling into react native and ship it as a standalone app that simply does the job of rendering multiple website content fetched from other links based on my frontend, which I also write in react. Does it make sense now?
If the source is public you can just write the scrapper in JavaScript and run it on the client side.
React has nothing to do with your problem. It will just output your data, its only job is to render the HTML, not deal with your business logic.
Yeah this was what I was planning to do, cause we maintain a server that does the Parsing and aggregation that uses Express, and now we don't really want to lol.
React does happen to use NPM right? All the libraries we use for parsing and stuff are npm packages, so that's why this came to my head.
Thanks!
you can avoid npm by just adding the react as an external dependency, like we did in the old days :))
It's not required to run React server-side, or use a server at all.
You can compile React into a SPA, or single page application, using create-react-app that accomplishes this. Or use a static site generator (NextJS, GatsbyJS, etc) to create HTML/JS pages for each route. You can even just create static HTML/JS files yourself and import the external React library (if you're comfortable writing non-ES6 React, or run your own build process).
Then you can deliver your entire website through a CDN, rather than relying on an Express server.
The only limitation with this setup is the inability to hide any code from the client-side, like API secret keys, which is where you'd need a "middleman" API server. Even if you needed to leverage this down the line, there are lots of static sites nowadays that accomplish things like user auth using specialized hosts (like Netlify) or a separate API / microservice / 3rd party service.
And if you're into GraphQL, I'd also consider looking into implementations like Apollo or Relay, since they do a fantastic job of fetching the exact data components need.
But as long as all your client-side code is cool to be public, you don't need a server at all 👍 Welcome to the JAMstack revolution 😎
The code will be open source, so perfect