I am developing an application with node.js and express.js hosted on firebase using firebase functions, and development in typescript. I would like to use react.js as client side framework. I set up node + express + firebase using:
firebase init hosting
firebase init functions
However, there is no obvious way to set up react front end framework using create-react-app ... given the current project setup. In particular, create-react-app seem to create its own node_module and index.js. I found this: https://medium.freecodecamp.org/how-to-make-create-react-app-work-with-a-node-backend-api-7c5c48acb1b0
It is a bit ad-hoc. In particular, it is launching a dev server using yarn, but I am using firebase serve ..., and would like to keep it that way. Do these different frameworks play together at all? #webDev
You can definitely use React and Firebase together, but merging the complex templates generated by starter kits for each may be more trouble than it's worth.
You will likely need to pick which generated template gives you the most value (whether it be from firebase init hosting or create-react-app) and then work on standing up items from the non-chosen ones piece by piece.
If you really want to use firebase serve you will be losing hot-reload and other development time benefits that create-react-app provides, as firebase serve internally uses superstatic (repo) which is a dev server for hosting static files.
You can use React with such a setup by npm install --save react react-dom and then using React as normal, but it's very likely that you will want a toolchain between your source and the static files that firebase serve serves (given your use of the typescript tag, I'm assuming you at least need to transpile .ts to .js), and you will then need to set that up on your own if you simply want to use firebase-serve.
In my opinion, the dev toolchain that you get through create-react-app will provide more immediate value for your specific situation than wanting to stick with firebase serve. Is there any specific reason you feel glued to firebase serve?
(Not using firebase serve in no way causes issues running firebase deploy --only hosting later when you want to deploy to firebase hosting, as long as your hosting config points to the directory where npm run build outputs your built files.)
Related
This may be a dumb question, but is the default react app (created using npm create-react-app my-app) using node.js? I am confused because in my web development class at university, I had to download node.js to create react applications. However, I didn't have to do anything like creating a server or initiating a node.js file, which is described in w3school's node.js tutorial. Because of this, I found out that I don't even really know what node is used for, besides downloading packages like redux and whatnot.
create-react-app uses node.js for all of its dev tooling. Likewise, a lot of the tools you'll use in the React ecosystem (like webpack, prettier, npm), all run on top of node.js as well).
You'll most probably build your react app to a static file, in which case the production output will not require node.js, it will be html and javascript assets that can be served directly to a client.
Hope that helps! Let me know if you have other specific questions
Node.js is used for server-side while React.js is for the front-end part. So, no, you don't need Node.js.
Under development mode, yes. Create react app runs NodeJs with Webpack Dev Server to allow you get feedback when modifing files, start or stop the server.
I am following Ben Awad's wonderful tutorial to build a fullstack
app using Next.js, Express, Typescript, and GraphQL. Everything works smoothly locally, but I have run into a barrage of issues trying to deploy to Heroku. I would really like to deploy both server and client to Heroku as one app, and have Express serve the frontend files as well as be the backend.
monorepo
- web
- package.json
- server
- package.json
package.json
To my understanding, this is possible using Next's custom server option, which I have integrated in my server.js file. My problem is when deploying to Heroku, it doesn't detect React as a dependency for the backend so while the deploy succeeds, the app crashes when I try to access it in the browser. I have tried a few things to resolve this issue - having two copies of React in frontend and backend, respectively, only leads to more problems (understandably so). I have tried keeping one copy and using npm link to point to the module, but it only works locally. I've tried changing the webpack config as well but it doesn't seem to register. I tried defining the custom server as a util in the frontend and import it in server.js, but the import is always undefined, which makes sense so I moved it back.
I'm still new and have many misconceptions about how Next.js works, especially when coupled with a custom server, so I might be doing something fundamentally wrong. Is there anything I'm missing, or is it better to split the app into two Heroku apps and push one subtree into each?
The source code can be found here, but I will be probably rolling back because it has become very messy.
I know there are other ways to do this I just don't want to give up quite yet.
From udemy React courses i could see Brad Traversy using create-react-app with node.js backend server and Andrei Neagoie using only create-react-app without node.js server to develop a full stack product.
I am seriously confused with when to use what?
Can any one explain me between these two scenarios? Please?
This is mostly related to how you want to structure your code. You can either :-
Set up your front-end and back-end code together. So, in your script tags in package.json, you will have something like 'nodemon server.js && react start' (refer package.json for exact syntax) to start both front-end and server with 'npm start'
Setting up front-end and back-end separately.
This is preferred for separation of concerns. In this case, you would start each separately.
Also, your front-end shouldn't be concerned about how your backend code has been written. It should only be dealing with backend using an API.
For ex: if in future, you wanted to change to Deno.js instead of node.js server, you would have make some modifications in package.json if you had front-end and back-end code written together in folder.
As far as deployment is concerned, in this case also, it will help if you kept the front-end and back-end code separately so you can deploy them separately.
React is used for frontend, while node.js is used for backend.
I think your confused because one is using react with node.js the other is using react alone.
Well React can be used for other backend other than node.js, like php for example.
This means you can create an app using react/php.
The reason Brad Traversy is using create-react-app with node.js because he wants to use node.js for his backend.
While Andrei Neagoie is using create-react-app without node.js because he either:
Don't want to use any backend.
He will add backend later on.
I'm working on a project and using nodejs as backend. I want to use react for the frontend. And currently, the way I know to use react is by creating a client folder inside it and using create-react-app and then running both the server separately and using the proxy to connect with the node backend. The other way I came to know is via this link which basically involves installing react, reactdom, webpack etc, and using it directly inside the node app without having a separate server for react as in the case of create-react-app. So which way is better and what are their pros and cons.
The usual way is to run both react and node in separate servers.
Create the react app using npx-create-react-app
Create the node app using npm init
If both the folders are in the same directory you can use a npm package called concurrently and run both the servers with a single command. Also don't forget to install the npm package cors in your node app. If you don't , you'll get CORS errors from your API calls.
Imo using create react app is better than manually trying to configure webpack. Saves a lot of time and it's more easy to deploy.
I'm building a simple website using Node.js and Express.js with a typical root-level package.json to handle my dependencies.
Now, I'm learning to use Google Firebase for web hosting and functions to deploy the website. Upon executing the Firebase CLI command firebase init functions, I now have a functions directory that also has a package.json file. I transferred my initial /app.js file into the functions/index.js and it's working fine when I firebase serve for testing.
Here is my project directory structure:
functions
└─views
└─index.js
└─package.json <- contains firebase-admin and firebase-functions dependencies
public
└─images
├─styles
└─scripts
firebase.json
package.json <- contains express, handlebars, etc. dependencies I had originally created.
Is it good practice to now have 2 package.json files for this project? One for Firebase functions, and the other for my app? Should I consolidate them into one, and if so, which one?
I'm still new to back end development, so any advice would be deeply appreciated!
You have to see your functions as your backend server. In the end if you host your web app and call your functions via http requests your functions act as independent "components" even then they are in the same place in your local project. That's why they need their own package.json.
To help rookies like me, yes you should have two package.json files.
One for your front end. One for your Firebase Functions 'backend'
To install packages on the functions package.json, in the terminal navigate to the functions folder.