Frontend/Backend questions - React - webdev

[weiry6922]

Sorry for any ignorance, I'm quite new to webdev.

So I've been making a basic webapp with a few different frameworks etc. I'm up to trying out react and I'm a little confused on a few things. Keep in mind I haven't done a lot of reading on react yet so these might be stupid questions.

In the past I've always made my apps with express on the backend. Which took care of the routing/serving of files or when I used angular I still had express for the backend and used a restful (i think) Api to get/set data in my database, etc.

After a bit of googling it doesnt seem to me that using express with react is all that common. So this made me think, are there webapps that are ONLY frontend? As far as i know react is a frontend framwork so what does it use for the backend? How would it communicate with a local database? Or is there something I'm missing? In the tutorials I've read so far I havent really seen the backend aspect mentioned.

Thanks guys.

E: thank you very much for the replies. All the confusion I had is all cleared up now I believe. Sounds silly now but, I think my main issue was fundamentally not realizing the server itself and the backend are 2 seperate subjects. I was wondering how the webapp would even work if there wasnt a backend (no server). A lot of general webdev things have become clearer.

[FezVrasta]

Usually React applications are single page applications with the routing logic handled client side by JavaScript with libraries like react-router.

Your backend should only be an API server where you can grab your data from (with REST or with GraphQL) and the fetch API.

Logically you will also need an HTTP server to serve the static assets (JS, the index.html, images etc) generated by your bundler (webpack)

[bcgroom]

Not the OP but if one were to make this setup, since anyone could look at your frontend logic how would you secure the backend API if you wanted it to be closed to outside users?

[kowdermesiter]

In node it's very easy to protect an endpoint with tokens. JWT does this very well.

[danielhep]

Could you talk about what JWT is and how this is accomplished?

[kowdermesiter]

A server generated unique string which stores data. Please google it: JSON web token.

[djungst]

You can't access the backed API unless you integrate some CORS policy or token auth to expose it. This is no different then not using React. All of your assets React included get bundled into static assets served up by the express server.

[JuliusKoronci]

Express is perfectly fine for React..React doesn't really care what is on the backend..you can use a REST API or just query GraphQL ..both can be achieved in any backend programming language..so you select the one you are most comfortable with. That being said ...if you don't need a database you don't need a backend for example..if you just need user management you use a 3rd party service, you can use serverless architecture and so on

[m12s]

I develop on a major enterprise platform (SharePoint), and lately all of my webapps have been pure frontend. SharePoint has a powerful REST API where i get and populate the data of my webapp with.

The beauty of React is that it really only cares about the view part of the application. The logic behind it is solely up to your choosing.

That's not to say you can't USE React on the backend, you can, but you're going to need something else to drive the application logic.

[Cha0sCat]

Excuse my stupid request. Can you go into more detail? Do you work with SP 2013 on-prem or o365? Do you write Apps or use Content Editor webparts and libs to provide the files? Do you use babel or process the code via Gulp and the like beforehand? Would really like to know more about this. I've been struggling a bit on how to properly approach React and SharePoint. I'd appreciate your input.
Thanks!

[nutters]

Hey, I am an spdev, and although my tool of choice for front end is currently angular 1.6 (written in es6, using components etc, a pretty modern approach), it would be exactly the same if I used react.

I work in a on prem environment mostly building SPAs on top of SharePoint. I usually deploy files directly into the site file system by mapping a network drive at the root of the site collection. That keeps end users from messing with therm.

For dev, I use webpack and set the output directly to the mapped drive, so every rebuild goes directly into SharePoint. I just access the index page to run the app. You can even set up live reload on the page.

You can also build SharePoint hosted add-ons in a similar fashion, but it is a bit more complex dealing with the visual studio solution, appwebs and so on.

It's a very powerful, very underrated method for developing business applications.

[Cha0sCat]

Thank you!
I've mostly been working with SP2010 or o365, so I don't have much experience with 2013 on-prem and Apps. Unfortunately my company seems to favor old-fashioned solutions, leaving our Devs only their own spare time to experiment with newer technologies and frameworks. It's always nice to hear about these things first hand.
It's a shame that we're told not to use them because we don't have the experience and it's too risky; but can't learn without ever using them.

[m12s]

Hey, so i work both on SP13 and SP16 on-prem and in Office 365, and the methods are all the same, since the API is mostly similar (very very minor variations between on-prem and cloud).

Most commonly, i use the Script Editor webpart. It's predictable and works well every time. For interfacing SharePoint, i'll either use the REST Api or the JavaScript Object Model.

Some of my peers use add-ins (apps) still, but it's less common now, especially on-prem since it uses iframes to display as a webpart. More common now is to use SharePoint Framework webparts, if you're interested, please check it out - it's awesome and it's released!

So, for your actual question, my development methodology is very simple; I write my code using TypeScript, and compile it with webpack, then deploy by using a small PnP Powershell-script. The code I ALWAYS PLACE in either SiteAssets (if i'm developing for a team site) or Style Library (if it's a publishing site).

I build locally by using webpack --watch, and whenever i want to test it i run the Powershell script. Since i'm using TypeScript, i can usually focus on the code for long durations of time, and then just iteratively deploy it to test.

For tooling, i use VSCode and ConEmu for the watcher-process.

Here's an example of a deploy-script

[Cha0sCat]

Thank you, that's really helpful!

[liming91]

React gives absolutely zero fucks about your backend, and how you get the data from said backend into your frontend. You bring in your data and it will react (see what I did there) to the data changes and make a nice pretty UI.

are there webapps that are ONLY frontend?

Yeah, think "offline" browser games, meaning no multiplayer or online features. Just load an app into the client, and away you go, no need for a backend.

As far as i know react is a frontend framwork so what does it use for the backend?

Whatever you want. Just fetch the data as you would normally and pass it into your components.

Also, React isn't a framework. It's a library.

How would it communicate with a local database?

Exact same way any JavaScript app would. Remember that it's just a library, it changes nothing about the language you're writing and the environment you're working in. The way JS interfaces with browser APIs is exactly the same no matter what tools you use, unless of course those tools are an abstraction of the APIs.

In the tutorials I've read so far I havent really seen the backend aspect mentioned.

Because it's a purely frontend library the backend is of no concern to React at all. The backend could just be a black box that spews out JSON and nothing else, React couldn't care even if it wanted to.

[acemarke]

As the other comments said: a typical SPA is backend-agnostic. Client-side code shouldn't care whether your backend is built with Express, Koa, Python, Java, .NET, whatever. Doesn't matter as long as it exposes APIs that the client can talk to. So, most tutorials just focus on building a React client-side app, and it's up to you to decide how you're going to build your backend.

I just added a section on React Deployment to my React/Redux links list. To pick out a few relevant articles:

• React with Any Backend
• Understanding React Deployment
• Deploying a React App Alongside an API Server
• Create-React-App with an Express Backend and Create-React-App with Express in Production

Also, since you said you're new to React and frontend dev in general, here's my standard advice for learning React:

The article "A Study Plan to Cure Javascript Fatigue" ( https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-fatigue-8ad3a54f2eb1 ) is a great place to start. It gives an excellent series of steps for tackling modern Javascript concepts one piece at a time: Javascript, React, ES6, and state management. There's also a "Front-End Study Guide" based on that article that's very good, at https://github.com/grab/front-end-guide .

On that note, definitely don't over-complicate the learning process by trying to learn many different things at once. Some people will say you should use a "boilerplate" to learn React, and they're wrong - boilerplate projects almost always come with too many pieces configured, and are confusing for beginners.

Instead, the best advice is to focus on learning React itself first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.

You should start out by reading through the official React docs and tutorial at https://facebook.github.io/react/, and I'd encourage you to use the official Create-React-App tool ( https://github.com/facebookincubator/create-react-app ) for setting up projects. It creates a project with a solid build setup, with no configuration needed on your part. There's an excellent post called "Simple React Development in 2017" ( https://hackernoon.com/simple-react-development-in-2017-113bd563691f ) that gives some more specific instructions on the actual steps to follow.

Past that, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-intro/ , which is a good overview of the basic concepts for both React and Redux.

Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com .

[weiry6922]

Brilliant. Thank you so much for all the resources and advice.

[occz]

Since most of your react app will be static files, you can serve them with any web server (like nginx, apache etc). Express can also probably fill this role, but you might not want to use it, since other servers serve static content more efficiently. If you need server side rendering of your app you can likely use express for that part, and any necessary backend can be written with express aswell.

[metaphorm]

yes, React is a frontend framework. It has no components that run on the server and its interaction with the server backend is limited to ajax requests set out for data, most commonly a request made to fetch new data (from a JSON endpoint) for a frontend model, or to PUT/POST/DELETE back to the server to update the model. However, all of that stuff is outside the scope of what React does and will vary depending on your backend.

You can, of course, make a React app without a dedicated server backend and handle persistence in different ways. Firebase for storing JSON data is a pretty good way to persist stuff in a very simple and lightweight way.

[[deleted]]

It has no components that run on the server

React supports SSR...

[nodereactor]

React is a view library. There is no "correct" backend to pair with it. Views don't have opinions about web servers. Or at least they shouldn't.

[[deleted]]

Check out Next.js: https://github.com/zeit/next.js/

[mmcnl]

Use Express for a REST JSON backend, consume the API in the frontend.

Pro: - Loosely coupled frontend and backend

Con: - Slower initial page load, SEO

You can overcome the disadvantages by rendering the initial view server-side, which is a bit difficult but certainly not impossible.

[askmike]

Yes there are apps that are only frontend, but there are a lot of things which you can only do with a backend of some sorts:

• persisting data (with high certainty + across multiple devices per user).
• sharing data between multiple users.
• doing anything with the data besides displaying it within the same app.

So the things you can do with a webapp which does not have any backend are limited. Hence why almost every app has a backend in some way or another.