I will soon be starting a new project which involves upgrading my existing application frontend to use React.js. The current frontend makes standard REST calls to a server built using Microsoft technologies, which is not planning on changing any time soon.
I want to utilise the concept of server-side rendering and the new React Saga framework to improve SEO and performance. As I understand, in order to achieve this, I would need to run a Node.js server to enable this behaviour and make server-to-server calls from Node.js to the existing API.
My question is.. is this a common architecture? I.e having Node.js act as a middleman server? (UI - Node - Existing API). Or is there a better way/technique of integrating exiting non-JS APIs with the latest and greatest UI frameworks?
Any resources/materials you can provide for some reading on this topic would be a great help too!
Thanks.
Yes, its common and its also not bad, to split it that way:
Frontend Server
API(s)
The FE-Server will render and serve the UI.
The API(s) could be further splitted in many smaller microservices.
Related
I am creating an app in Electron using React. The first version will be a purely desktop based app using a local database for data storage etc. However, eventually I would like to utilise as much of the same code base as possible and deploy the same app as a cloud-based alternative (by just leaving out the electron component).
I'd like some advice, thoughts, opinions from the community on if I should use axios for creating internal restAPI infrastructure rather than a API using javascript modules/functions etc. for performing requests such as getting data from a database.
My thinking is then that when I port the application to the cloud, I really just need to change the restAPI locations to point to a cloud version which would then get the data from a cloud database rather than a local database etc.
Would exposing such APIs locally within Electron using axios pose any security risks or other issues that I may need to consider?
Perhaps this answer/discussion may also provide useful for the community in the future.
Looking forward to thoughts, or even new suggestions on how this may be best approached.
Thanks.
I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?
I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.
im looking forward to build RT web apps with NodeJS. Coming from Rails, I've felt in love with NodeJS and Async JS programming.
Run a few experiments with Node, and then as I search tools and resources to get used with, I got overwhelmed with the lot of stuff over there.
I found lot's of libraries and components over there, and pretty much got confused on how a large-scale well-writen and implemented RT web app should be built.
So the app will run over NodeJS, using Express framework.
I read about knockout.js, a client-side library to provide realtime stuff like automatic UI refresh, and I guess I could conbine it with jQuery.
Also, I found socket.io.
The author says:
Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It's care-free realtime 100% in JavaScript.
So socket.io is about compatibility.
What about backbone.js? Where does it goes to?
With so much stuff, I got shocked. What should I learn? Which modules worth studing?
Im focusing on NodeJS and Express but most books/screencasts covers old versions of nodejs. So im being guided by its official API.
Now im here asking your advice and to organize somehow all the info out there.
Correct me if my assumptions are not precise, please point me to the right direction and feel free to suggest any other module that could help on my learning.
Thanks in advance
It might be useful for you to separate the node.js server side libraries (via npm etc...) from all of the client side (browser) libraries and technologies like jquery, backbone, knockout etc... when you think about it. Even socket.io which exposes a persistent socket connection between the browser and the server (to avoid polling) does not dictate what client side technologies you use.
Focus on exposing a solid web-api ( random example ) from your server and your client technologies can be swapped, augmented etc... with no effect on the server. The only place they intersect is if you're using a view technology like Jade. It's also an option to have a pure separation where the server is just serving up the client files and your client is a thicker javascript application (using knockout, jquery etc...) calling a good server web api.
Some folks try to unify the client and server models - for example, this article using backbone and node. It depends on how much data you work with to say whether that's feasible but it does couple the client and server and makes the server stateful which can have downsides (scale out, requires affinity etc...). Personally, I get wary of that much magic (binding, state, syncing etc...). Node is about keeping things simple, light and fast. It's a fast front end network server.
My 2 cents (and some may disagree). Start with node on the server and pick your storage (mongoDb etc...). Design a solid RESTful (hypermedia) API - a good webapi regardless of the client. Then start with a basic html/css/js, maybe jquery client and add things like knockout etc... as you expand your client skills. That will allow you to replace your client technologies independent of your server as the new technology winds change (and they will).
That's the hallmark of a well designed system - the ability to replace componets/sub-systems without rewriting everything :)
Hope that helps clear up some of the fog :)
You may want to look at Meteor if you are focussing on real-time Javascript apps: http://meteor.com/
I plan to write a rather large-scale web application using JavaScript. I believe I will be developing the webapp using CanJS to organize my client-side pieces.
I am strongly considering using Node.js for my server-side component, but I was wondering what the best way to set up Node to accept and handle REST requests. I did some Googling and came across something called Express. Any comments on this?
Any help/suggestions would be greatly appreciated.
restify is a node.js module built specifically to enable you to build correct REST web services.
http://mcavage.github.com/node-restify/
Express is more directed towards full web application (rendering HTML, etc). Restify is just for web services.
Besides, the guy who created Restify works at Joyent, the company where Ryan Dahl developped Node.js (which is kind of guarantee quality).
For REST request handling, express-resource is a more focused solution than railwayjs that's also built on top of expressjs.
You can try http://railwayjs.com/ it is build on top of http://expressjs.com/
Express is nice and fast :) railway has similar stack to ruby on rails.
http://expressjs.com is the de factor standard, does Sinatra-like routing. If you want real easy automatic generation of resources (sort of Rails-style), try one of those libraries above.
If you want it real simple on top of express, try http://github.com/deitch/booster
Disclosure: I just released Booster this week.
I heard some facts about ZeroMQ, and I think it's very powerful thing. But now I try to imagine how it can be applied in web application.
Could you make an example of using ZeroMQ in web applications?
So, the first that strikes me - simple chat application. So, we need frontend and backend. I prefer using python+Tornado as backend. There is python lib for using ZeroMQ. It's clear. So, the next thing is frontend. In frontend I will use some javascript to interact with backend.
So, to do this I should use ajax calls, right? Are there some other ways to do it?
TIA!
The easiest way to do this is to map WebSockets to ZeroMQ sockets, which is quite simple with tornado and PyZMQ's ZMQStream objects. An example of such an app is the IPython Notebook. This approach has the downside of requiring websockets, which puts a limit on what browsers you can support. Of course, you could also map ajax calls with jQuery, etc. and handle the relay with async handlers in tornado.
A more sophisticated web:ZeroMQ app is the mongrel2 webserver.
The right choice for you is just going to depend on your communication patterns.