I'm running ServiceStack version 4.x and I've created a custom Request Filter Attribute (it inherits from RequestFilterAttribute).
I have some class methods using this custom attribute with ApplyTo parameter. Whenever I use normal HTTP calls the filter gets executed perfectly, the problem comes when one of my services calls internaly a method from another service, the filter then is not executed.
According to the documentation that can be found here:
Order of operations
For non HTTP calls, Request filters with priority >= 0 will be executed right before Action filters.
I have no idea why this is not working, maybe is a bug on the implementation or I misunderstood the documentation.
Any idea how to solve this or a workaround?
Note the non-HTTP Global Request Filters is linked to the Messaging Global Request and Response Filters docs which refer to the MQ Request Filters, i.e:
appHost.GlobalMessageRequestFilters
appHost.GlobalMessageResponseFilters
Only the appHost.PreRequestFilters are executed everywhere, i.e. for every Raw HTTP Handler, HTTP or MQ Service, etc.
Related
As far as I understand, in a CQRS-oriented API exposed through a RESTful HTTP API the commands and queries are expressed through the HTTP verbs, the commands being asynchronous and usually returning 202 Accepted, while the queries get the information you need. Someone asked me the following: supposing they want to change some information, they would have to send a command and then a query to get the resulting state, why to force the client to make two HTTP requests when you can simply return what they want in the HTTP response of the command in a single HTTP request?
We had a long conversation in DDD/CRQS mailing list a couple of months ago (link). One part of the discussion was "one way command" and this is what I think you are assuming. You can find out that Greg Young is opposed to this pattern. A command changes the state and therefore prone to failure, meaning it can fail and you should support this. REST API with POST/PUT requests provide perfect support for this but you should not just return 202 Accepted but really give some meaningful result back. Some people return 200 success and also some object that contains a URL to retrieve the newly created or updated object. If the command handler fails, it should return 500 and an error message.
Having fire-and-forget commands is dangerous since it can give a consumer wrong ideas about the system state.
My team also recently had a very heated discussion about this very thing. Thanks for posting the question. I have usually been the defender of the "fire and forget" style commands. My position has always been that, if you want to be able to move to an async command dispatcher some day, then you cannot allow commands to return anything. Doing so would kill your chances since an async command doesn't have much of a way to return a value to the original http call. Some of my team mates really challenged this thinking so I had to start thinking if my position was really worth defending.
Then I realized that async or not async is JUST an implementation detail. This led me to realize that, using our frameworks, we can build in middleware to accomplish the same thing our async dispatchers are doing. So, we can build our command handlers the way we want to, returning what ever makes sense, and then let the framework around the handlers deal with the "when".
Example: My team is building an http API in node.js currently. Instead of requiring a POST command to only return a blank 202, we are returning details of the newly created resource. This helps the front-end move on. The front-end POSTS a widget and opens a channel to the server's web socket using the same command as the channel name. the request comes to the server and is intercepted by middleware which passes it to the service bus. When the command is eventually processed synchronously by the handler, it "returns" via the web socket and the front-end is happy. The middleware can be disabled easily, making the API synchronous again.
There is nothing stopping you from doing that. If you execute your commands synchronously and create your projections synchronously, then it will be easy for you to just make a query directly after executing the command and returning that result. If you do this asynchronously via the rest-api, then you have no query result to send back. If you do it asynchronously within your system, then you can wait for the projection to be created and then send the response to the client.
The important thing is that you separate your write and read models in classic CQRS style. That does not mean that you cannot do a read in the same request as you do the command. Sure, you can send a command to the server and then with SignalR (or something) wait for a notification that your projection have been created/updated. I do not see a problem with waiting for the projection to be created on the server side instead for on the client.
How you do this will affect you infrastructure and error handling. Also, you will hold the HTTP request open for a longer time if you return the result at once.
I want to map multiple actions to a single HTTP verb like this
"/product"(controller: "product"){
action : [POST: ["save", "clone"] ]
}
Is there any way in grails 2.2.4 to achieve this ?
Yes, it is trivial to do - but not directly in UrlMappings. Implementing your example would make the request/response lifecycle confusing, where and how is the response built?
Here are two possible approaches to accomplish the same thing, depending on your circumstances:
Have a primary controller method (action) that handles request and response and just calls the other action(s) as a side effect. This is the way I usually see something like this implemented, mainly because it is obvious where the request and response is handled.
Have a delegating controller method (action) that does nothing but call the other actions. The other actions are together responsible for handling request and response. This is more similar to what you're trying to do in your example.
I'm working on a GWT project which calls the server via RPC. A typical RPC calls the Server and passes some information and then recieves the answer as an ArrayList.Now we noticed that with a growing database we should use pagination to not overcharge the client with to many objects.
The problem is that there are at the moment many existing methods which are using RPC and each of them would must be modified to provide the necessary information for pagination (Count of Objects,Current Position ) . If i would change every method i would have to edit the Synchronous Interface,the Asynchronous Interface, and the Server and Client class which are using/implementing them.
I tried to create a generic Wrapper class, but i couldn't make it suitable for out project,because each object must be casted back in the original type. Is there a way with less effort to provide pagination without editing many methods?
Is it possible to create a proxy object in the client code without using any request context?
I want this behavior because I want to send the object to the server multiple times and I cant do so if its associated to single request context.
You can create your proxy with one RequestContext and send it. Once the response is received, the object is frozen and no longer attached to a RequestContext, you can thus send it with another RequestContext (as before, you'll have to wait for the response before being able to use it yet another RequestContext).
I'll investigate if these constraints can be relaxed in a future version of GWT.
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.