Looking for some thoughts and feedback on making async requests from dust.js template helpers:
Dust.js can make async requests from template helpers, but is it actually a good idea to make use of them? Consider this scenario...
A particular page requires several api requests to be rendered. In the page's route controller, a single async api request gets the bulk of the data for the page and passes the data to the template to be rendered. In the template there are several reusable and standalone dust helpers (can be dropped in on any page) that make their own async requests in order to display their components.
In this situation, all the dust helpers have to wait until the request made from the controller finishes before their calls can be made (when template rendering begins).
It seems that ideally (excluding having one endpoint for all data on the page) all requests should occur in the route controller in order to avoid synchronous calls, otherwise the request chain would be 1) controller requests 2) dust helper requests 3) nested/dependent dust helper requests.
Cons:
route controller complexity by calling n services to build the view model
adding display components to new pages require changes to controller and template instead of just adding a template helper
Pros:
reduce/eliminate synchronous requests and increase performance
easier to understand the view model
What are your thoughts? Thanks!
If you consider to use your templates only server side I would move everything into the controller. I like to have a controller who "controls" all the data needed for the view layer.
If you think about using dust templates in the browser (so ajax calls from the cleint) both ways in my point of view are reasonable from an architectural view.
But I would ask my self some question about user experience before deciding:
How much time would take to complete all the calls from the
controller? Sometimes is better to send partial data to the user and
give to him something to view and load other components later for a
better user experience. But if the overhead is not over some ms, I
would decide to build my page context all in the controller.
Where is the data displayed in the page? Do you need it in the first
part of the page? Or user should scroll to view other sets of data?
If the data is not consumed immediately I would decide to leave it
to the client.
Related
Given that we can do routing with Express on the server, why do need a client side router?
What are the benefits, and is it only significant to SPA?
Client side routing is required to keep your application in sync with the browser URL.
It is mainly useful for Single Page Applications where the backend will be used for RESTful API calls via XHR or AJAX calls.
Being a SPA uses can book mark your URL and when they hit the URL again , your application should load that page with the data and its state.
The main difference between Server side routing and client side routing:
1. In Server Side routing you download(serve) the entire page.
2. In client Side routing along with the entire page, you can serve a specific portion of a page, reuse the DOM, manually manage the URL and history states. eg.
www.something.com/page1/tab1 will show tab1 in the UI
www.something.com/page1.tab2 will show tab2 in the UI
In this way the url can get more complex and you can have sub-routes with states.
Those who need a client-side router, need it for state management. Say you have server-rendered pages, but with some client-side widgets - e.g. a calendar, set of filters or collapsed or open sidebar. Router helps you initialize these components of the page in the exact state you want them. Granted, you could do most of it and all of the use cases I've named on the server, too. But it's usually a lot easier to handle these on the client. You might render it faster on the server, but sometimes, especially when doing partial page updates, it's cheaper and faster to handle that client-side.
So, I have been searching everywhere and can't find any hints on this.
I have a REST API built with express that will be consumed by a website and in the future a mobile app.
I have to build the website and want to use react/redux, and I'm struggling to understand how to avoid the initial state to be render from server because I will have nested components and a lot of async data, and it will become a mess to maintain code both client- and server-side. Is there any solution/alternative for this?
Thanks in advance.
You don't necessarily need server-side rendering to solve this problem. You can make your components load with a blank state and then immediately fetch your data.
According to the React docs, your ajax requests should be made in the componentDidMount() lifecycle method, which fires once as soon as your initial render is complete.
If you want to ... send AJAX requests, perform those
operations in this method.
For example, you don't load your app if a user isn't authenticated, or you put up loading spinners to indicate that data is being fetched.
What I would like to know is, how do you built your web application? I'm really confuse as which method should I use for my project.
Already decided which technologies to choose.
1) Node.js and express as its Framework
2) MongoDB
3) React + Flux
But the problem right now, should I use method (A) or method (B)
Method (A) - Serverside rendering for HTML
app.get('/users/', function(request, respond) {
var user = "Jack";
respond.render("user", { user: user });
});
Method (B) - Clientside rendering for HTML
app.get('/users/', function(request, respond){
var user = "Jack";
respond.json({ user: user });
});
Method A will render the HTML from the server and as well as the data.
Method B will just respond the data that is needed for the client which is React.js, so that it could manipulate the data.
My concern, is which method should I use? most startups use which method?
Thank you.
It's not an either/or proposition.
React is a client side framework. You have to render on the client side. The question is whether to render on the server side in addition to rendering on the client side.
The answer? If you can, YES!
You will get SEO benefits and an initial performance boost by rendering on the server side. But you will still have to do the same client side rendering.
I suggestion googling "isomorphic react" and doing some reading. Here is one article on the subject.
http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/
Well, it really depends on which vision you have on the modern web, and what you are willing to do.
Will you prefer to let your users wait, displaying a loader while data are loaded asynchronously, or will you prefer to keep your users busy as long as you can ?
Here are different articles that will help you clear your mind and be aware of the different advantages that you can have by doing server-side rendering, client-side rendering having multiple issues.
You can see this post from Twitter blog saying they improve their initial page load by 1/5th to what they had before, by moving the rendering to the server:
https://blog.twitter.com/2012/improving-performance-on-twittercom
An other article, this time from airbnb, describing the issues you can have with client-side rendering itself:
http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
There is also an other interesting article talking about client-side/server-side rendering, bringing a debate on when should we use / not use server-side or client-side rendering and why:
https://ponyfoo.com/articles/stop-breaking-the-web
And to finish, I can give you two more link more focused on react, and describing in which way server-side rendering should be helpful for your case:
https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html
http://reactjsnews.com/isomorphic-javascript-with-react-node/
Now, about what you SHOULD do, it's a matter of what you exactly need to do, to my opinion, but basically, you can do both at the same time (client-side AND server-side), to have the best user experience.
This concept is called "isomorphic javascript" and it is getting more and more popular these days.
The simplest architecture is to just do dynamic html rendering on the server, with no Ajax, and with a new HTML page requested for pretty much any client click. This is the 'traditional' approach, and has pros and cons.
The next simplest is to serve completely static html+js+css (your React app) to the client, and make XMLHttpRequest calls to webservices to fetch the required data (i.e. your method B).
The most complex but ideal approach (from a performance and SEO perspective) is to build an 'isomorphic' app that supports both approaches. The idea is that the server makes all the necessary WS calls that the client would make and renders the initial page that the user has visited (which could be a deep-linked part of the application), a bit like option A but using React to do the rendering, and then passes control to the client for future DOM updates. This then allows fast incremental updates to the page via web-service calls as the user interacts (e.g. just like B). Navigation between different 'pages' at this point involves using the History API to make it look like you're changing page, when actually you are just manipulating the current page using web-services. But you you then did a browser refresh, your server would send back the full HTML of the current page, before passing control to client-side React again. There are lots of React+Flux+Node examples of this approach available online, using the different flavours of Flux that support server-side rendering.
Whether that approach is worthwhile depends on your situation. It probably makes sense to start using approach B (you can share the your HTTP API between mobile apps and websites), but use a Flux architecture that supports server-side rendering and keep it in mind. That way, if you need to improve the performance of initial page loads, you have the means to do it.
I have a MVC5 app that is using layout page to control the header and footer ect. The layout page has some sections that are database driven such as the nav bar. I am not sure of the best practice for where to make these calls is. I can think of 2 ways but neither are perfect
Method 1: Pass in data with the pages view model. Don't like this approach has my homepage controller should only be concerned with homepage content, not the layout. This would have to be repeated for each and every view.
Method 2: Ajax to WebAPI controller. Kinda leaning towards this, although I think this means losing stuff like #URL and #HTML which are being used to create links and render custom content.
EDIT: Though of another method
Method 3: Load info into cache on Start. Since this is not info that changes often after initial setup and this code is displayed on every page, caching would be needed anyways.
You should call a controller method from within the view. On your view:
#Html.Action("MyAction", "MyController")
Make sure this action can find everything it needs without having to have values passed in, and you're set. We do this in several projects via service location and/or dependency injection.
I am learning about backbone, and from the examples and tutorials I have gotten this impression:
The initial GET / returns the skeleton page with backbone and the view templates.
Backbone uses the REST API to flesh out the page by GETting the data it needs and adding it into the DOM.
This works, but it seems wasteful in terms of additional HTTP requests, and latency from the perspective of the end user (minimum two round-trips before the page is visible. Actually three in my case, since the API must first ask which widgets are available, and then fetch the details on any available widgets....).
Is there an established, standard method for getting around this? My current candidates are:
Ignore the problem.
Embed the initialization data directly into the original page via inline javascript.
Render the page as if backbone didn't exist. When backbone finishes initializing, it will (hopefully) be in sync with the page as the user sees it. It can correct anything it needs to if things changed in the intervening couple seconds, but at least the user is not left hanging.
Another solution I haven't thought of?
Is there an established way to do this? Is it situation-specific? I am using Node / JS / Express.
Update: I think I found a solution, possibly the "accepted" solution, in Backbone's documentation:
Here's an example using reset to bootstrap a collection during initial page load, in a Rails application.
<script>
var Accounts = new Backbone.Collection;
Accounts.reset(<%= #accounts.to_json %>);
</script>
Calling collection.reset() without passing any models as arguments will empty the entire collection.