ohpauleez
commented
7 years ago Hi @dball -- thanks for digging deeper into Vase and growing the ecosystem!
A few items that might help you:
- It is possible to add interceptors to single Vase API using the
:vase.api/interceptorskey. See this testing descriptor for an example. - Action literals and standard interceptors can be composed within a Vase descriptor using a vector. For example, see this testing descriptor
- Vase just expands into a collect of routes/interceptors that get concatenated onto the existing Pedestal routes. Specifying your own
::http/interceptorsin 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?
ddeaguiar
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?