There are many articles out there that recommend using ngrx/effects for handling async actions such as http REST calls. Instead of using effects, why can't we just use a regular service to make the http call and then take the result of that http call and dispatch an action? Doesn't that simplify things?
You can perfectly use a regular service and then dispatch an action, like this on a component.
this.store.dispatch({
type: "SAVE_DATA",
payload: data
});
this.saveData(data) // POST request to server
.map(res => this.store.dispatch({type: "DATA_SAVED"}))
.subscribe()
#ngrx/effect just abstracts this logic away from the component. By doing this with a functional programmic aproach (pure functions), code remains very easy to test.
I really recommend reading this article, since there are many solutions to problems that abuse effects
Post
Using ngrx/effects makes life more simpler than using service to make http call and then take the result and dispatch the action. As following
Effects provide abstraction to the service layer. Our components don't need to know about the services(http) layer. Components will only dispatch actions to get things done.
As Effects are basically service, code is written once and reused multiple times.
Related
Potentially "subjective" question : what is a sweet spot for introducing reactive programming (rxjs, bacon, etc...) into an existing, "old-school- MVC-jquery" client side application ?
For example, Promises shine the most if you introduce it in the "API calls" layer of an application (and you can do it one function at a time, returning a Promise instead of accepting a callback - they, it tends to disseminate once everyone in the team gets a few benefits.)
From most of the tutorials I could read, I do not really see where rxjs would shine most. In the widgets (returning stream of events instead of having a 'listener-based' API ?)
Any experience welcome.
It is hard to say where it will shine the most…
For me, the key feature, is that it allows to describe code in more declarative way instead of writing complicated state machines(as it often happens when working with async logic).
In general, it can be quite useful for anything async for example in UI, or for API calls layer implementation as you mentioned about Promises, but better(promise is just a limited version of observable, except the fact that observable is lazy).
In case of implementing API calls layer, in comparison to promises it will have at least following benefits:
subscription to observable is cancellable(disposable) - for example, you can switch between subscriptions for api results without worrying about race conditions with previous api requests... it is as simple as results = queries.switchMap(q=>doApiCall(q))
it can return multiple values using the same interface - you can easily replace ajax call with subscription to web-socket, and you will not need to change code that is using this.
better error handing - it is quite easy with rx to do things like retrying operation n-times before throwing an error, or handling timeout.
I suggest you to watch Netflix JavaScript Talks - Async JavaScript with Reactive Extensions by Jafar Husain, there is great examples about where RxJS can be helpful. And likely it would be mostly an answer to your question.
How do I send POST/PUT/DELETE calls to a rest source using Atmosphere 1.1.0+ in a conventional RPC manner? (You are guessing right, I want to employ pub/sub and RPC style in my project)
serverside: register a #Path (e.g. /member), mark with #POST/#PUT/#DELETE, process the method body and return the value. Seems straight forward. Even with JSON en-/decoding.
clientside: How would you kick a POST request with the wasync library? All atmosphere examples use "GET" and recommended to use GET only. Why is that?
RequestBuilder request = client.newRequestBuilder().method(Request.METHOD.GET).uri("/member")
Can one expect this synchronous server response when invoking the fire method? e.g.
Future future = socket.fire(myMemberObject)
Thank you for hints and comments on this approach (also thoights on pairing RPC and PubSub are welcome).
wAsync is using POST once the connection is established. wAsync is asynchronous by nature so you need to use Latch if you want to make it blocking, or use AsyncHttpClient with Future.
i have a rather general question: How to call a method in RESTful web service correctly?
The method is supposed to do only a transformation in the database and return nothing (so no GET?!). However I also send no values from the client (so no PUT/POST?!?).
So far I am using GET. Put i read thats not the proper way to do it...
Thanks in advance!
REST stands for "REpresentational State Transfer". If you're not transferring state representing the thing you're working with (in one direction or the other), it's pretty much inherently not RESTful, and there's no correct way of doing it and still calling it REST.
If you want RPC, then do RPC. Just don't call it RESTful. :)
The way you do it is through RPC. REST is good for state transfer, but not for triggering actions that have nothing to do with state transfer, such as operations that affect a large number of records. Most systems I've seen use REST for 99% of the work in supporting a UI, and RPC for that last 1% -- operations that do not involve state transfer, bulk update operations, that sort of thing. Your goal should be to express as much of the business logic as possible as reaction to application of state, reserving the corner cases for RPC.
There's really no "correct" way to do this if you're not transfering any kind of data. You're simply calling a method, so REST does not really apply.
These days PATCH with a "JSON Patch" payload might be a way to go - but it's STILL not RESTful.
Calling it an RPC is more appropriate and no reason it cannot be in the same API as long as it is documented. Document your API with your RPC methods and REST resources separated.
E.g.
See:Understanding RPC vs REST For HTTP APIs
HTTP requests made with NSURLConnection are event driven. This makes things a little weird when you need to issue say three requests one after another, where each request uses information returned by the previous one.
I'm used to doing it like this:
response1 = request1();
response2 = request2(response1);
response3 = request3(response2);
But the only way I could find how to do this with NSURLConnection is to have connectionDidFinishLoading: make the next request. But when the number of sequential requests grows, this can get messy.
What's the idiomatic way to handle sequential HTTP requests with cocoa?
You could wrap the requests in an NSOperation and then define operation dependencies, so that each request must wait on its dependent requests before executing.
From the Apple Docs:
Dependencies are a convenient way to execute operations in a specific order. You can add and remove dependencies for an operation using the addDependency: and removeDependency: methods. By default, an operation object that has dependencies is not considered ready until all of its dependent operation objects have finished executing. Once the last dependent operation finishes, however, the operation object becomes ready and able to execute.
I would advise you using a 3rd party library called MKNetworkKit. It can handle the hard work for you, so you can focus on the key aspects of your application. You can find it here.
You can and should use NSOperation and NSOperationQueues.
A good tutorial can be found here: How To Use NSOperations And NSOperationQueues
Does anyone know if it is possible to write to the response stream in OpenRasta rather than returning an object as a response resource? Alternatively, am I able to implement an HTTP handler but still leverage OpenRasta's URL rewriting?
Thanks
Chris
You can always keep an http handler on the side to do specialized things, but that ties you to asp.net and will prevent your code from being portable on other hosts. If that's something you're ok with, any handler that's registered for a specific route will get executed before openrasta on asp.net.
that said, codecs are the ones writing to the response stream, so provided you have a custom IMediaTypeWriter you can write the resource instance on a stream whichever way you want.
Say for example that you returned an IEnumerable from your handler, as those get deferred executed, you can just start the enumeration of those in your custom codec without any problem.