Closed dball closed 5 years ago
Hi @dball -- thanks for digging deeper into Vase and growing the ecosystem!
A few items that might help you:
:vase.api/interceptors
key. See this testing descriptor for an example.::http/interceptors
in the service map allows you to control the default interceptors across the entire stack (Pedestal and Vase). It's advised for production application on Pedestal to always specify only the interceptors you need, and not accept the default interceptors.If these don't fit your use case, you can add an additional key to your service map (as done with ::route-set
in the template), with a vector of additional interceptors for your Vase APIs. The in server.clj
, you can join in these interceptors when the Vase routes are expanded.
Would any of these approaches fit your needs?
Closing this issue since it's been idle for some time and the existing tooling provides multiple approaches to solving the problem.
Taking the proposition Paul suggested in the Cognicast to heart, I've been exploring what it would take to add action literals to do things not among vase's design goals, namely express sql queries and commands, with an eye towards higher-level routes that do CRUD operations on sql tables.
The implementation is fairly straightforward, but the stumbling block is that vase doesn't provide any affordance for interceptors offering access to novel resources to get mixed into the default interceptor chain. I realize that this is essentially one of your design non-goals, but I posit that most interesting and useful custom action literals will need this. Would you be interested in exploring what it might look like for vase to offer some e.g. declarative approach, or do you feel like it's just best in such cases to build a custom interceptor chain?