I am currently building a dashboard page with multiple widgets. Those widgets retrieve their data with REST calls ($resource). A few widgets make similar calls and I don't want to DDOS our server so I am looking for a way to make a call only once and resolve all similar requests with the same response.
Since I am restricted to using POST requests only, I cannot use the cache option that $resource offers. This seems to be doing exactly what I want but only for GET requests.
I was thinking along the lines of using a http interceptor to queue similar POST requests, fire only one of them and resolving them all when the first one gets its response.
However, I cannot seem to put the pieces together so any help is appreciated. I am open to other options.
Kind regards,
Tim
Services in AngularJS are singletons, so a solution would be to store the response in the service, as a variable. Then next time you'll do the request, previously check if the variable is null, if it's not you wrap it in a promise and returned it. If it's null, then you do the request, and store the response for the next call.
You can also either use this in your request service or in your interceptor service.
I hope I helped !
Refactor your widgets to depend on a service (singleton).
This service should either poll the server via XHR, or get server push via websocket for updates.
If polling, look into server side caching and etags.
Related
since i was struggling in making API calls to apache server from my angular app running in node-express,
So i was unable to call apache server with POST calls inspite of setting the CORS filter in most of the ways available,
So someone suggested rather of making calls from AngularJs(Frontend) , make it from NodeJs(Backend-server) which serves your angulas(frontEnd) code.
So kindly assisst me in this as to what exactly is the difference between making API call's from frontEnd to any server or from the backend(server) of the same frontEnd ??
What factors makes it more preferable over the other one ?
Is it proxy or CORS thing which effects FrontEnd based API calls ?
Thanking all in advance
Shohil Sethia
CORS is a policy that is voluntarily enforced by the browser (chrome, firefox, etc.). The decision to allow or deny a request is based on the presence of a certain header (Access-Control-Allow-Origin: *) in a response from the server. There is no equivalent policy in a server side setting, so you are free to make cross-origin requests all day.
From enable-cors.org:
[CORS] prevents JavaScript from making requests across domain boundaries
This is why I usually build a small server api in Node to grab data from external 3rd party servers.
When the user makes a request on the front end the request is sent to the backend function with optional parameters which the end-user specified.
Depending on the parameters supplied, different functions might be run before the backend queries the third party API.
3rd party API response is returned to the backend.
Backend either passes the response along or does more stuff before passing the response along.
Then the frontend does stuff with the data based on the response received (ie there were less than 5 results so adding pagination is not necessary).
If developed this way you gain access to the following which all benefit your application/website.
Keep any necessary credentials on the server. ( extremely important )
Obtain logs.
Validate on both the server side and the client side for an added layer of security.
Use the server to filter sensitive results if necessary before they reach the frontend.
Vary which parts of the heavy lifting are done on the server vs the device in order to improve the application performance.
I have a few components in one page.
Each of them fetches the same data from the server.
As a result, when the page loads, these components send the same request multiple times.
Is there any way to prevent this? Like caching the promise of the first request and returning that to the next coming requests (before the promise resolved)?
In order to make sure that the request is sent only once, you can keep track of the first HttpPromise you create, and on subsequent calls of the function, return that same promise.
This SO link might be what you're looking for.
When calling the $http service you can additionally supply a cache object. If you do so any additional requests will use the cached value. If the same cache is used then additional requests made before the first is resolved will not call the server but wait for the response.
$http.get(url, {cache:cacheObj})
Where cacheObj is from $cacheFactory
I've been diving into authentication between Angular and Express, and decided on using token auth with JWTs and the npm jsonwebtoken package. I've got everything set up on the server side and am receiving the token on the client side, but now I need to know how to make it send the token with every request.
From what I've found, most resources out there say to use an $http interceptor to transform every outgoing request. But people at work have always used $httpProvider.headers.defaults.common["Auth"] = token in a .config block, which seems a lot more straightforward to me. Here's a blog explaining how to do it both ways.
But the accepted answer on this stackoverflow post says it would be better to use interceptors, but he doesn't give a reason why.
Any insight would be helpful.
After a bunch more research and a conversation on Reddit, it seems like the best way to do it is through the interceptor. Doing the setup in the .config or .run blocks may be good for checking if the user is already authenticated when they first load the app (if there is a token in local storage), but won't be possible for handling dynamic changes like logging out or logging in after the app is loaded. I'm pretty sure you could do it through the $http default headers, but might as well just do it in one place.
Hopefully this helps someone in the future!
I want to test my code with real API calls (so I can test the API as well, and when I change the API I don't have to change the JS test as well, and a lot more benefits.) instead of the regular $httpBackend.expectPOST('http://api.com/login').response(200).
Essentially, I want to test a ProductsController that expects to be logged in through an AuthService.login() method and receive a list of products through ui-router's resolve feature.
In this case, the login method receives data that needs to be used to gather products.
From the $httpBackend documentation found here: https://docs.angularjs.org/api/ngMockE2E/service/$httpBackend
As opposed to unit-testing, in an end-to-end testing scenario or in scenario when an application is being developed with the real backend api replaced with a mock, it is often desirable for certain category of requests to bypass the mock and issue a real http request (e.g. to fetch templates or static files from the webserver). To configure the backend with this behavior use the passThrough request handler of when instead of respond
So, something like: $httpBackend.whenGET(/.*/).passThrough(); should suffice.
I have an AngularJS application that talks to various java services. In the application I have a global http header setting in an http interceptor. That means all the service requests from my application will get the header values.
Now the trouble is that all the services CORS settings won't allow this header value. Couple of services does, while others does not. The service calls to the servers that do not support the header fails, since the http interceptor always puts the header values.
Is there a better way to design, in the above said case, so as to avoid the issue stated?
Appreciate any help...
How about adding a response interceptor, looking for a 401 status? If you get a 401, attempt to do the same request again without the headers this time. If this succeeds, 'whitelist' this domain to make all following requests without the headers that you don't want.
Otherwise, if you have a limited number of services that you are making calls to, maybe whitelist them inside of your request interceptor? This would probably be easier, but it's not very elegant.