We Keep Coding

Why is it a best practice to use Asynchornus functions everywhere in nodejs

ive found out that its a best practice for nodeJS / ExpressJS as an API-Endpoint for a ReactJS Software to only use asynchornus functions for mysql-querys etc.
But i really dont get how this should work and why it decrease performance if i didnt use it.
Please imagine the following code:
API Endpoint "/user/get/1"
Fetches every datas from user with id one and responds with a json content. If i use async there is no possibility to respond with the information gathered by the query, because its not fulfilled when the function runs to its end.
If i wrap it in a Promise, and wait until its finished its the same like a synchronus function - isnt it?
Please describe for me whats the difference between waiting for a async function or use sync function directly.
Thanks for your help!

If i wrap it in a Promise, and wait until its finished its the same
like a synchronus function - isnt it?
No, it isn't. The difference between synchronous and async functions in JavaScript is precisely that async code is scheduled to run whenever it can instead of immediately, right now. In other words, if you use sync code, your entire Node application will stop everything to grab your data from the database and won't do anything else until it's done. If you use a Promise and async code, instead, while your response won't come until it's done, the rest of the Node app will still continue running while the async code is getting the data, allowing other connections and requests to be made in the meantime.
Using async here isn't about making the one response come faster; it's about allowing other requests to be handled while waiting for that one response.

jQuery .when().then() not working as expected

I have an object which acts as a client side API Client which exposes several functions which all return jQuery ajax() objects. Some of those ajax calls have .done() and .fail() calls chained directly onto them because they are actions which need to be taken every time the API responses come back before the rest of the js code is allowed to deal with the response. Pretty standard stuff.
I need to kick off a variable number of API requests, wait for all to fail or succeed, and then continue processing. For the examples I will create, I will simplify this down to just two ajax calls.
So I create an array to hold the returned ajax objects, and then use $.when().apply(null, deferreds).then(function(){//do something after both ajax requests complete}). When the calls complete successfully, everything works great. When calls fail (such as if the ajax call 404s), things are not so great.
The problem is that .then() doesn't seem to detect the fails, even though I thought then() was supposed to be fired regardless of success or failure of the underlying promise(s).
I can switch to .always(), which seems to work better (in that it detects the failures and still triggers the callback) but it seems to fire before some of the .fail() callbacks that are registered directly on the ajax calls, which doesn't make sense to me since I thought the callbacks for an ajax call were called in the order they were registered.
I'm sure I'm just missing something about the behavior of the ajax() when() then() combo.
Fiddle showing successful calls using .then(): https://jsfiddle.net/kwrLyw6q/5/
Fiddle using .then() with failed ajax calls (not working, would love to know why. Seems like this is the "right" way to do it, but I can't figure out where I'm going wrong): https://jsfiddle.net/kwrLyw6q/2/
Fiddle using .always() (working, but notice the out-of-order callback order. At least, out of order compared to the order I want them!): https://jsfiddle.net/kwrLyw6q/7/

It looks like deferred.then() takes three arguments:
success function (first argument).
fail function (second argument).
progress function (third)
updated fiddle

AngularJS and jQuery alert

I'm just curious why the following code is working:
<script>
var app = angular.module('VEL',[]);
app.controller('VELControl', function($scope, $http) {
$.getJSON("../json/dict.php?p="+$_GET['p'], function(response){
$scope.velData = response;
});
alert($scope.velData); // also works with alert($scope);
});
But when I remove the alert(...) it stops working.
Could anyone explain me why or refer to a documentation?

The main problem is that you're using jQuery's $.getJSON() method, which Angular doesn't know anything about. Angular is great at tracking when asynchronous events occur and updating the view when they complete, but you have to use Angular's services to take advantage of this.
Angular gives us the $http service for making AJAX calls. Since $http is tied into Angular's digest cycle (read up on this if you've never heard of it, it's critical to understanding how Angular works), Angular will update the view after $http returns data and its callbacks are run.
Rewrite your controller like this and it should work:
app.controller('VELControl', function($scope, $http) {
$http.get("../json/dict.php?p="+$_GET['p']).then(function(response){
$scope.velData = response.data;
});
});
As an aside, your alert() working with the old method was probably a fluke based on how fast your server returned the data. As I understand it, alert() runs asynchronously anyway, so when you called alert($scope.velData), this was probably pushed onto the end of the browser's execution queue, and before it was reached the AJAX call returned and set the value you needed. If your server had been slower, you probably would have alerted undefined and then received your data. If you have control over the server (which it looks like you do), this would probably be a fun experiment to try: put in a sleep(10) or some similar wait to force the server to take a long time; try different values and see what happens with that alert() statement.

Polymer iron-ajax and asynchronous requests (etag sync and response handling)

I'm looking for a tried and true way of handling asynchronous calls to API endpoints returning JSON (using polymer's latest rendition of the iron-ajax element). These API calls rely on etag matching, so it is important that the etag sent matches the one on the server. I have that part working, except in certain circumstances, where quick succession API calls may cause an out-of-sequence response (and therefore can get the etag out of sync). There are also multiple API endpoints (i.e. different URLs). So, sometimes if quick succession calls using different endpoints are initiated via an iron-ajax element, it can cause issues for the response handler function, as the response handler currently checks the URL of the ajax element to know how to handle the response appropriately. Therefore, if the 2nd call overwrites the URL of the ajax component before the 1st call response is received, when the 1st call does come back the responseHandler doesn't handle it appropriately. Perhaps there is a much better and reliable way of checking exactly which call has returned?
I know I'm not the first person to encounter this scenario, so I'm wondering if someone out there can show me the enlightened path? I'm thinking there is a simple strategy to handle this problem, perhaps implementing call queuing etc., but I'm not sure if iron-ajax has anything built-in that could help in that regard.
An example with some sample code would be absolutely stupendous!

If you depend on multiple API endpoints, I would have a separate iron-ajax element for each one so that they don't stomp on each other if the URLs change (through data-binding or something):
<iron-ajax id="cats" url="https://api.example.com/cats" handle-as="json"></iron-ajax>
<iron-ajax id="dogs" url="https://api.example.com/dogs" handle-as="json"></iron-ajax>
Generate the requests, and use Promise.all() to wait for both requests to complete:
<script>
Polymer({
is: 'my-element',
...,
fetchPets: function () {
var catsRequest = this.$.cats.generateRequest();
var dogsRequest = this.$.dogs.generateRequest();
Promise.all([catsRequest.completes, dogsRequest.completes])
.then(function (requests) {
var cats = requests[0].response;
var dogs = requests[1].response;
// do whatever you want from here...
alert(cats.concat(dogs));
});
}
})
</script>

Firstly iron-ajax uses iron-request under the skin and that returns a Promise.
I think what you are trying to achieve is that with a string of sequential calls, you can have the same order of responses, despite them all running, possibly in parallel.
This article has an example of doing this with a set of chapters from a story
http://www.html5rocks.com/en/tutorials/es6/promises/
The article gives an online example here:
http://www.html5rocks.com/en/tutorials/es6/promises/async-best-example.html
In essence it is doing a Promise.all(array of requests).then(...) to give you an ordered array of responses.
If you look at the source code for iron-ajax, you will see how it creates the iron-request, and then uses it. You could do the same but based on the example I have pointed to above.
If I have misunderstood, and you are trying to ensure the requests go out sequentially, then you can still do that with Promises, but instead of using Promise.all, you chain them with .then clauses one after the other.

Why are busy indicators not displayed when sending requests?

I have some slow OData calls which need to present some sort of visual indicator to the user that something is happening.
I've read the API reference and seen functions like attachRequestSent(), setBusy(), BusyDialog, BusyIndicator, etc.
I tried using them accordingly but did not work for me. The problem seems to be oModel.create causing the whole app to hang while it executes. No loading indicators or anything can run since the app is frozen until the create function has returned.
Edit: I have set up an asynchronous batch read OData call. I have then wrapped the code for handling the received data in a function and called that function inside the success function in the batch call.
This works; the view loads and I see a busy indicator before the fields are populated with the data
oModel.submitBatch(/*fnSuccess*/);
Is this a good way to do it, or is there a better way which is more standard?

Before the Odata call, display the busy indicator (locks the entire app screen). with
sap.ui.core.BusyIndicator.show(0);
Then, in both the success and failure handlers of the odata call, hide it with
sap.ui.core.BusyIndicator.hide();
It does not work with implicit calls (when for instance you bind to an odata model), for this you can use the request sent events, but the idea is the same.
Edit: You also need to give a small delay to allow the indicator to appear, then use setTimeout to call your odata after a small delay.
doStuffWithIndicator: function(){
sap.ui.core.BusyIndicator.show(0);
setTimeout(function(){
doStuff();
sap.ui.core.BusyIndicator.hide();
}, 20);
},

checkout this thread: SAPUI5 Wait for an Deferred-Object // wait for .done() function
Javascript is asynchrone, this means the code will be processed further no matter if you make an call (which might take longer). Therefore before calling an OData Service you need to tell your JS to wait for it (make it synchrone) via an deferred object.

The main problem seems to be oModel.create causing the whole app to hang while it executes. No loading indicators or anything can run since the app is frozen until the create function has returned.
Sounds like you've been using the now-deprecated sap.ui.model.odata.ODataModel the whole time, which sends mostly synchronous XHRs. Synchronous XHRs block the main thread (== UI thread) until the browser receives the response. The browser isn't then able to update the DOM to display the busy indicator during the round trip.
If anyone reading this has the same issue, please migrate to the newer equivalent model: sap/ui/model/odata/v2/ODataModel. It sends only asynchronous requests (AJAX), allowing the UI thread to handle other tasks (such as adding the busy indicator to the DOM) while the browser waits for the response.