I'm using the DataCache API that is part of the Windows Azure Caching Nuget package and I was wondering why there isn't a way to make non-blocking calls against the constituent methods. Am I missing something? I understand that the latencies on these calls are going to be low but it's still a network call - if you're not using the local cache setting.
Suggestions, thoughts?
Thanks!
If you want to understand why the library is this way then I'd have a read of this article on exposing async wrappers for synchronous methods. TL:DR; There are two distinct reasons for wanting to do async, scalability and responsiveness. You really only need an async version of a method if it will help with the former, the latter you can leave to the consumers of your API because it's easy.
EDIT: It seems people have missed my intent in this answer, so I'll try adding some more clarification.
Yes, the cache client may make a network call and MS are trying to get everyone to make all their network calls in a non-blocking manner so that apps remain responsive. However this is a cache and it is designed to be very fast. If you make a request to the cache and the item is not in local cache (according to Scott Guthrie) the response should take 1ms. Given that the response is so quick (and if you are using local cache it will be even quicker), they would have likely added more overhead by creating tasks to run it in the background than they would have gained.
Related
I didn't find any posts related to this topic. It seems natural to use Lambda as a getstream backend, but I'm not sure if it heavily depends on persistent connections or other architectural choices that would rule it out. Is it a sensible approach? Has anyone made it work? Any advice?
While you can build an entire website only in Lambda, you have to consider the followings:
Lambda behind API Gateway has a timeout limit of 30 seconds and a Payload size limit (both received and sended) of 6MB. While for most of the cases this is fine, if you have some really big operations or you need to send some really big datas (like a high resolution image), you can't do it with this approach, but you need to think about something else (for instance you can send an SNS to another Lambda function with higher timeout that can do all this asynchronously and then send the result to the client when it's done, supposing the client is capable of receiving events)
Lambda has cold starts, which in terms slow down your APIs when a client calls them for the first time in a while. The cold start time depends on the language you are doing your Lambdas, so you might consider this too. If you are using C# or Java for your Lambdas, than this is probably not the best choice. From this point of view, Node.JS and Python seems to be the best choices, with Golang rising. You can find more about it here. And by the way, you can now specify a Provisioned Throughput for your Lambda, which aims to fix the cold start issue, but I haven't used it yet so I can't tell if there is any difference (but I'm sure there is)
If done correctly you'll end up managing hundreds of Lambda functions, while with a standard Docker Container under ECS you'll manage few APIs with multiple endpoints. This point should not be underestimated, as on one side it will make changes easier in the future, since lambda will be small and you'll easily find the bug and fix it, but on the other side you have to move across these functions, which if you don't know exactly which lambda is responsible of what can be a long process
Lambda can't handle sessions as far as I know. Because after some time the Lambda container gets dropped, you can't store any session inside the Lambda itself. You'll always need a structure to store the session so it can be shared across multiple Lambda invocations, such as some records in a DynamoDB table or something else, but this mean that you have to write the code for this, while in a classic API (like a .NET Core one) all of this is handled by the language itself and you only need to store or retrieve items from the session (most of the times)
So... yeah! A backed written entirely in Lambda is possible. The company I work in does it and I must say is a lot better, both in terms of speed and development time. But those benefits comes later, since you need to face all of the reasons I listed above before, and is not as easy as it could seem
Yes, you can use AWS Lambda as backend and integrate with Stream API there.
Building an entire application on Lambda directly is going to be very complex and requires writing lot of boiler plate code just to enforce some basic organization and structure to your project.
My recommendation is use a serverless framework to do this that takes care of keeping your application well organized and to deploy new versions (and environments).
Serverless is a good option for that: https://serverless.com/framework/docs/providers/aws/guide/intro/
I've recently been trying to refactor some code that takes advantage of the global batch requests feature for the Google APIs that were recently deprecated. Currently, we use the npm package google-batch, but since it dangerously edits the filesystem and uses the deprecated global endpoint, I'd like to move away from it before the endpoint gets fully removed.
How can I create a batch request using (ideally) only the Node.js client? I want to use methods already present in the client as much as possible since it natively provides Promise and TypeScript support, which I intend to use.
I've looked into the Batchelor package suggested in this answer, but it requires you to manually write the HTTP request object instead of using the Node.js client.
This Github issue discusses the use of batch requests in the new node client.
According to that thread, the new intended method of "batching" (outside of a poorly listed set of endpoints that support it) is to make use of the HTTP/2 feature being shipped with the client- and then just to make your requests all at once it seems.
The reason "Batching" is in quotes is because I do not believe this explanation matches my definition of batching- the client isn't performing the queuing of requests to be executed, but instead managing network traffic better when you execute them yourself.
I'm unsure if I am understanding it correctly, but this HTTP/2 feature doesn't actually batch requests, and requires you to queue things yourself and instead tidys up some TCP overhead. In short, I do not believe that batching itself is possible with the api client alone.
(FWIW, I would have preferred to comment with a link as I'm uncertain I explained this well, but reputation didn't let me)
I am fairly new to programming with the Play framework as well as Akka, although I've been reading about them for a while. I am now starting a proof-of-concept application on the default/basic Play environment. My question stems from the web service client api in Play (http://www.playframework.org/documentation/2.0.1/ScalaWS).
This application basically needs to mediate calls to a remote SOAP web service in as scalable and performant a way as possible. Browser makes ajax calls in JSON, Play app needs to transform them to SOAP/XML and vice versa on the response.
If I used the play web service client directly through the controller, these calls can be asynchronous, which is way better than what we do now (blocking). However, I'm not clear on how this exactly this would behave under heavy load. Will the concurrency/thread-management be largely left to the underlying Netty server? Do I have any way to tune it?
An alternative would be to use an Akka actor system from the controllers, where I can control the routing policy, pool size, fault-tolerance etc. If I take this approach, would it still make sense to use Play's async WS client? If so, would this approach ( of composing Futures?) be the recommended pattern?
Another factor that seems to make the Akka approach more attractive is that this application would eventually have several other responsibilities, so we could control/tune the resources allowed to this ActorSystem and reduce risk of the entire app getting dragged down by the SOAP service.
The two options you are detailing would work :
Use the play API for WS to handle requests/responses asynchronously
Use Akka to do the same thing and manage your WS call synchronously in your actor
First, there is no right or wrong solution.
The Play! WS API solution seams the easiest to implement and test. Many people in the community rely on it (I do).
On the other hand, even if the Akka solution seams heavier (not that much) to set up, it brings you more flexibility in the future. You can simply use Async play! blocks and work with promises for async computation. There is also implicit conversions between play promises and akka future. Finally, to monitor your actors you can have a look at Typesafe console.
If the big thing is performances, premature optimisation often leads to more (and unnecessary) complexity. As far as I am concern, I would begin with the API WS and if required in the future move to the Akka solution.
I'm working on the design of a web app which will be using AJAX to communicate with a server on an embedded device. But for one feature, the client will need to get very frequent updates (>10 per second), as close to real time as possible, for an extended period of time. Meanwhile typical AJAX requests will need to be handled from time to time.
Some considerations unique to this project:
This data will be very small, probably no more than a single numeric value.
There will only be 1 client connected to the server at a time, so scaling is not an issue.
The client and server will reside on the same local network, so the connection will be fast and reliable.
The app will be designed for Android devices, so we can take advantage of any platform-specific browser features.
The backend will most likely be implemented in Python using WSGI on Apache or lighttpd, but that is still open for discussion.
I'm looking into Comet techniques including XHL long polling and hidden iframe but I'm pretty new to web development and I don't know what kind of performance we can expect. The server shouldn't have any problem preparing the data, it's just a matter of pushing it out to the client as quickly as possible. Is 10 updates per second an unreasonable expectation for any of the Comet techniques, or even regular AJAX polling? Or is there another method you would suggest?
I realize this is ultimately going to take some prototyping, but if someone can give me a ball-park estimate or better yet specific technologies (client and server side) that would provide the best performance in this case, that would be a great help.
You may want to consider WebSockets. That way you wouldn't have to poll, you would receive data directly from your server. I'm not sure what server implementations are available at this point since it's still a pretty new technology, but I found a blog post about a library for WebSockets on Android:
http://anismiles.wordpress.com/2011/02/03/websocket-support-in-android%E2%80%99s-phonegap-apps/
For a Python back end, you might want to look into Twisted. I would also recommend the WebSocket approach, but failing that, and since you seem to be focused on a browser client, I would default to HTTP Streaming rather than polling or long-polls. This jQuery Plugin implements an http streaming Ajax client and claims specifically to support Twisted.
I am not sure if this would be helpful at all but you may want to try Comet style ajax
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
what is the cleanest way to clear cache on ColdFusion 8 server
do i don't have problems with old Stubs when i create
web service client?
ty very much for your response
Adobe Documentation for cfInvoke
Specifically, look at the refreshWSDL argument.
It's not something I'd call every time, since it adds a good bit of overhead to your WS instatniation. However, having a scheduled task to clear and recreate a stub that may change, or using it during development of the webservice might be beneficial.