how to implement a "after-route" policy

[tjwebb]

I like how policies separate my controller logic from guard logic. But I need a policy to run after the request has been handled by the controller, but before the server responds to the client.

I have a policy use-case that requires the result of the request in order to answer the question; I'd like to run it on every request, so implementing in each controller handler isn't feasible.

[RWOverdijk]

That's currently not possible.

You can, however, use responses for this. Simply create a new response in api/responses and use it via res.myResponse(data). It has access to the request and response so you can go nuts with it :)

[sgress454]

The recommended practice at this point is to use res.ok() as the go-to response in your controllers. Then when you want to transform the outgoing data in some way, you can just modify the ok response in api/responses as @RWOverdijk notes above.

[RWOverdijk]

@tjwebb Correct. That's what I'm saying. All controller.actions, by default, use res.ok() for successful responses and res.negotiate() for errors. res.negotiate() figures out if it should call badRequest(), serverError(). There's also a notFound() response. The convention is to use one of these for your response (in favour of res.send() or res.json()).

[leejt489]

res.ok() only takes a json object right? What if we need some model metadata, for example to re-format the response to adhere to a spec such as the JSON API spec?

I'm currently using an additional config file for api format, using a service to do the formatting, and overwriting the blueprints to call the service res.ok(), but I'd love a cleaner way!

[CWyrtzen]

Can anyone update this with an answer to @leejt489 ?

[leejt489]

From my understanding, res.ok() only takes a json object. The JSON API spec requires that the response put the data under the key [model name], as in {post: {...}} or {posts: [{...},{...}]}, which requires passing some metadata about the model. Additional customizations such as sideloading relationships also requires model metadata. So one way or another just usingres.ok()` doesn't enable a clean way for to customize the response. Currently it is necessary to override blueprints or update all controller actions. Generators or libraries like https://github.com/mphasize/sails-ember-blueprints make this easier, but the problem I see there is that it could make the application more difficult to maintain; namely by overriding blueprints, the burden of ensuring all of the rest of the code in the blueprints shifts to the developer (every time I update sails I manually go in and check to see if anything has changed in the blueprints). Probably not the most critical issue, but I think it could be improved.