babashka
Think more about errors in interceptors
@borkdude not sure the full context of what you're exploring, though have you had a look at Papillon at all? https://github.com/lambda-toolshed/papillon/
there's still some rough edges we're working through, but it was created out of a need for a more portable and actively maintained interceptor library, and borrows ideas from the major pre-existing ones. it's a work in progress, but it's been great in production (heavy nodejs AWS lambda use) so far.
@1100001-jones Error-wise I think it should behave like how pedestal interceptors work, with an explicit :error handler, and if not present, the interceptor is skipped. But I have yet to encounter a case where the current behavior isn't desired as to have a good basis to verify the behavior. As for papillon: I'll take a look, but I prefer this library to remain dependency free.
@borkdude cool, yeah, wasn't too sure what all you were going for here (adding a lib dependency, or borrowing ideas from one).
papillon uses the same concept from pedestal with an explicit :error key for error handling on the interceptor, though the expected function signature is slightly different from pedestal. we tried having it be an isolated interceptor lib that's an intersection of the best bits of what existed.
Worth noting that papillon allows for async interceptors which might allow the request/response path to be extended closer to the actual underlying (async) provider.
papillon allows for async interceptors
this library currently also allows for that. an interceptor is allowed to return a CompletableFuture
though the expected function signature is slightly different from pedestal
not sure what the signature is in pedestal, but in general the response and request are threaded through the interceptors in this lib and I can image that there could be an exception key or so in there as well
this library currently also allows for that. an interceptor is allowed to return a CompletableFuture
Right. I may be missing something, but the current model requires each interceptor to be coupled to the output of the immediately preceding interceptor -and so on recursively. Papillon manages the realization of the deferred context/request/response and thus interceptors will always receive a realized value.
This is similar to the pedestal model (and sieppari too IIUC) and is substantially more involved (necessary complexity-wise) than reducing over a collection of interceptors.
Writing an interceptor that does not block on a deferred context/request/response might offer some performance improvement but the associated complexity would be substantial.
not sure what the signature is in pedestal, but in general the response and request are threaded through the interceptors in this lib and I can image that there could be an exception key or so in there as well
the main difference is that a pedestal :error fn has a signature of [context exception], while in papillon it's just [context] with a key of :lambda-toolshed.papillon/error having the error itself (I'd wager similar to the exception key you mention). so that it's always context in, context out for each interceptor fn, and this are "healed" just dissoc the key. apologies for any confusion/opaqueness.
but the associated complexity would be substantial
right, I don't think that's necessary for this library, but thanks for the interesting perspectives, really appreciate it @cch1 and @1100001-jones !