I'm building a web application using node.js, this is my first time working with node. I'm using express framework and I have a question about client side rendering.
All the tutorials that I have found online talk about express and server side rendering. They talk about how you can use jade the express templating engine, to serve rendered templates as reponse to your web application.
My application is going to be client heavy and most of the rendering will be done client side. I want to call server to just get plain JSON response and then render it client side, so server side rendering is not of much use.
In this case, is express a right choice? I really like the way I can write APIS in express but I'm concerned about how to serve my application. If I don't want to use the server side rendering it would mean that I would have to serve static HTML at the first call which seems weird to me.
You might want to try Emberjs if you want most of the work done on the client side. But still, you need to send the data to the client so one way is to build your app totally on the client side just by sending a plain html and working your way up there. You can also precompile jade
What you are describing sounds like you are searching for an javascript MVC(or other) solution.
There are a lot of possibilities. Take the right tools for the right job.
Try the following link to get an nice overview of what is possible.
Helping you select an MV* framework
Related
I have read on couple of articles that when building a website with react either php or nodeJS or something else is required to have a backend to retrieve data and server side rendering
I can manage data retrieving on react without any backend server (based on my experience with react-native).
I am not sure if server-side rendering is necessary for react?
What are the pros/cons, can the website work without server-side rendering?
Something has to render the original page being served for React. However, after that, there's nothing stopping you from doing everything else client side. There are tons of articles out there discussing the benefits and drawbacks of doing full CSR (Client Side Rendering) or full SSR (Server Side Rendering). However, I've found that most agree that there's a middle ground that meets the best of both worlds.
However, if your app is relatively small and unencumbered, going full CSR as you're indicating you want to will probably have little or no impact.
Server side rendering will give you better search engine results and previewing.
You can still use React with server side rendering with a framework like Nextjs. You may just want to initially render on the server side and from then on in use client side rendering.
Really depends on what you're planning to build. Firebase has security permissions for you to experiment to filter out what type of traffic you'd want. However if you are solely dependent on the client then there would be severe consequences for edge cases. What if there was an app breaking bug and someone abuses it, what if someone has an older version of your app and calls bad code? Utilizing nodeJs to call your business side logic is a very important layer of protection since you have one codebase that handles all of this incoming traffic.
So an example of business-side logic that shouldn't be on the client's system:
What if you had an important counter say $ dollars that you've spent on that website and it goes into the database once and feeds you that information and you'd save that into local storage until the end of the session. Are there consequences to this if you had multiple instances (hint: they might not all of the same $ amount if you've manipulated that data on the client's side) ? This would be an example of why you'd definitely want to have a nodeJS backend for your React application.
I'm currently working on a new ReactJS application. In all the previous applications I've built I used Express for the server side rendering. I used Express because routing in production mode wouldn't work if I didn't.
So I've recently discovered that it's posible to just always redirect my React app to my index.html file and let the React routing just do it's work. This also works when I deploy my application to production.
I know Express can be usefull for SEO porposes but other than that I have no idea why I would need to use it. So am I just missing something? Or is it just fine to don't use Express with my React application if I don't need any SEO.
React configured as a Single Page App, renders the express routing all but unnecessary. The standard transition from a web server rendered app to a single page app is to change the server into a REST Web API and any server side data needed from the React App is obtained through AJAX calls.
So in most cases you don't need Express when you are using React to handle your routing except for in less common cases when you might want to use express as a reverse proxy or something.
If you want to do server-side rendering, you'll need a node server (typically but doesn't have to be express) to render your React components. This could not only help with SEO but also allow your page to appear to load faster (you wouldn't have to wait for the JS to download and run before the user sees the HTML).
If you don't care about the benefits, don't use SSR.
when deploying react application it is just usually an html and a JS file. So you need some kind of server to host it. Luckily there are services out there that offers that like S3, Github etc.
You're using Express because it can host the html and js files. So technically you don't need specifically express but you need some server that will host your files.
I have been working on React.js for a month now. I have been using Webpack dev server which is a node.js Express server and enables us to render react.js on browser. I want to know whether using React.js will limit us on using only a node.js http server or is there a way we can use a simple http server as well with React.js.
I have also been wondering whether it is useful to use React.js for developing webpages that have mostly pre-fixed contents text fields, data etc. during request/response for any API operation.
Does using React.js limits us on using a node.js server
No. React is predominantly a client side library. It doesn't care how it is served to the client.
In the end you are just writing JavaScript. You can deliver the JavaScript code to the client whichever way you want.
It depends. Generally the answer is no. If you only want to use it as a client-side library, it doesn't matter what the web server is. But actually, react components can also be rendered on server side so you can develop universal/isomorphic apps. In that case you will need a node.js server.
Take a look at this universal example.
we are using php+yii2+react +redux+es6 without node.js server, but ngnix. At the end it is just javascript, so that we use gulp + babelify to translate es6 to es5 and then php yii2 application renders basic container to which react application renders himself.
Node.js is one of the options, you can use wathever server you want, just need something like gulp or webpack to compile your js and all dependencies to the ready to use standalone js.
I understand that Express resides on the server and Angular resides on the client but, as far as I know, Angular can do everything that Express can do which is
routing
interacting with the database
It kind of seems like maybe Express is needed in order for an AngularJS app to be served by Node.js but I'm not sure.
So what are the benefits to adding Express to an AngularJS app?
There are things which should be done server side (i.e. Express, not Angular), most notably user input validation - Angular, as it's client side, can be tampered.
Also, if you'll ever want to offer access type other than web app (i.e. mobile app), you'll probably need an API anyway - Express can do this, Angular don't.
Finally, database access - usually Angular app will need to connect to some kind of backend to perform CRUD operations. You'll either go with hosted DB like Firebase, or you'll end up using your own database. Latter scenario is more popular and you'll need Express (or similar) for that.
Express and AngularJS do not mutually exclude one another, they serve different purpose - in fact it's perfectly fine to use both - express for all your serverside logic, and Angular for client side logic.
Express can be used to host the APIs for AngularJS's service/factory to consume. You can consider AngularJS as MVC and the API on Express as SOA.
There is lot of stuff that one wants to control from server. And that is the place where the server side frameworks come into picture.
An web app is not just some html pages linked together. There are lot of other things that needs to be implemented
Model validation.
Keeping model consistent. Remember multiple users can access the same model at any give time and even change it.
Controlling resource access.
Triggering workflows.
Business Logic.
and other such thing require a server framework. So as mentioned earlier the client side frameworks like AngularJS complement server side frameworks.
I'm looking into solutions for integrating Ember.js with Node.js+Express+Tower.js.
I just started looking into Tower.js (the last couple of hours), and it looks like that the framework provides a nice structure for placing both server-side and client-side code (similar to the assets folder in Rails).
Since everything is in Javascript, I could either place Ember application code:
Entirely on the client, i.e., send everything on first request.
Serve only what is initially needed, and serve the rest only upon request.
In the 2nd solution, one could render the views on the server and send pure HTML.
Also what about the application logic of Ember (controllers, models, states, ...). How can it better be integrated with server-side Javascript (e.g., node.js+Express+Tower.js), so that
repeated code is minimized. In an ideal scenario, you define each model/controller/etc once and its used both on the server and on the client.
We are integrating Ember.js into the core of Tower.js, this has been planned from the beginning.
https://github.com/viatropos/tower/blob/development/test/cases/support/emberTest.coffee
Not quite there yet. But it's happening next.
Ember currently works in Node.js and the Browser, as does Tower. Controllers on the server will work like Rails' with web socket additions. Controllers on the client will work like they do on the server and like with Ember, with web socket support - still fleshing this out.