We are starting a project at work and we have used sammy.js with handlebars.js to handle the front end rendering. We are moving this new project to node and using express.js. Do we still need to use sammy.js for front end routing? We do not plan to use any front end framework currently.
Sammy.js is a routing framework designed for single page webapps. That is, Sammy is traditionally used for requests that will never leave your browser and are handled by a set of Javascript code running within it.
Express is used for server side routing, or in other words requests that hit your server. In this case, your server would render the page, then hand the rendered response back to the browser.
You can use both of them together, or use one over the other. The question you should really ask while architecting your app is whether your app is better off as a single page webapp or a multi-page app? For that, I'll refer you to this question: Single Page Application: advantages and disadvantages
Related
Let's say I have a blog and it's a normal Express multipage app. Now I would like to have a blog content manager as SPA with Vue.js.
I want to serve this app from a single route e.g. https://myapp/admin/dashboard
while the rest is a plain multipage express app (same server).
How to setup something like this in express and vue?
There are three possible strategies:
either you serve everything under a common path to the SPA with something like
app.get("/spa/*", spa);
app.get("/spa", spa);
In this case the client-side app will have to know its prefix because it will have to prefix all its links, ie it will have to send you to /spa when it wants to send you home. Both Vue and React Router support this via an option.
either you use URL fragments, ie hash links of the form /spa#sublink
In this case Express sees a single route:
app.get("/spa", spa);
The application doesn't need to know its prefix, you can relocate it, it always sends you to a relative link like href="#sublink. The downside is that you can't have multiple levels.
or you use query arguments like /spa?item=sublink
This is probably the worst way to do it, since it combines the downsides of all other methods
If you are not sure, the second method is probably the way to go - it doesn't require any special setup.
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.
Working on a new project, I need to create two sets of the front end with a same back-end code base and data. The second set of front end can be accessed through a sub-domain name such as secondfrontend.mywebsite.com. What will be the best approach between two sets of front end codes and two basic pages of the single page applications? I am going to use Vue for the front end as it is the simplest Javascript framework in the current JHispter project.
You can consume the JHipster REST API from any consumer you want (SPA, native mobile, ...). Since you have 2 webapps and not written in Angular, you would probably serve them from another http server than the Spring Boot app as static contents (lots of solutions there depending on your infra. Eg: Apache/Nginx, CloudFront, Express, ...). Note : If the fronts and the back are not on the same domain, you will have to take care of setting the CORS accordingly in the Jhipster app.
Also note that JHipster does a lot of optimizations when serving the static content (gzip, set caching headers, ...) so you will have to reproduce these optimizations in your server if you want optimal performance.
For this kind of expansion, I would definitely use a REST API with some sort of load balancing/caching sitting just before the entry point of backend. For sub domain, Cross Site Origin (CORS) should be able to take care of your problem.
Although, I have never used JHipster, but Spring with RestController that serve as rest API is a very nice option if you are working with very large backend. Just bare in mind that Spring Security takes in a urlencoded HTTP Body (Although through some Added filter JSON can also be parse in).
Vue as a front end is also a very nice option for SPA.
My general idea was that I was going to make a RESTful backend and then in my frontend request and render data by backend spits out. Is this generally how to layout a Node and React Web app? I'm new to front ends, any help is appreciated!
Yes this is how your app should be structured. The front end should make the API calls to your node backend and will just display the data to the user. This allows your front end to be very dynamic. If you ever want to expand your application later it will be completely independent of your backend. If you ever plan to expand to different platforms (mobile,etc) you will then be able to build those out as separate "front ends" to interact with the API as well.
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.