Fork me on GitHub
#pedestal
<
2017-09-14
>
kommen10:09:07

I have a rather basic question regarding interceptors:

kommen10:09:12

(defn attach-database [uri]
  (let [conn (db/connect uri)]
    {:name ::attach-database
     :enter #(assoc % ::connection conn ::db (d/db conn))}))

kommen10:09:27

but later:

kommen10:09:28

> A handler does not have access to the full execution context. Therefore, it cannot manipulate the interceptor queue or stack.

kommen10:09:34

so how is the handler supposed to use the database? the way I’d do it would be to then just to assoc the db onto the request instead of the context, but I was wondering what’s best practice for this

martinklepsch11:09:16

@kommen hey 🙂 I haven’t used Interceptors for HTTP much but the request is just part of the context. When you define your handler, can you tell where the :request is taken out/put back in?

martinklepsch11:09:39

@kommen I skimmed the docs for a bit but couldn’t find any places where this was done implicitly

martinklepsch11:09:54

@kommen here are some examples of injecting a db-connection also http://pedestal.io/guides/your-first-api

kommen11:09:22

@martinklepsch yes, the request is just part of the context, but I was wondering because of the example above if adding it there is considered good practice

martinklepsch11:09:16

@kommen I don’t thing there’s anything inherently wrong with it but you may want to restrict handlers to only receive the request so that they cannot meddle with the queue/stack

kommen11:09:10

doing all the processing in the interceptors as in the your-first-api example is interesting, but really doesn’t sit right for me as it seems it loads the routes table with a lot of logic

kommen11:09:43

@martinklepsch ok, thanks a lot for your opinion!

martinklepsch11:09:00

> it loads the routes table with a lot of logic not sure I understand - the table is still just data but the processing of requests is done with interceptors, right?

martinklepsch11:09:39

as far as I understand all “processing” is done via interceptors — unlike with middleware there isn’t really this one function at the center of things

kommen11:09:15

I meant that routes end up like this:

kommen11:09:19

["/todo/:list-id"           :get    [entity-render db-interceptor list-view]]
     ["/todo/:list-id"           :post   [entity-render list-item-view db-interceptor list-item-create]]
     ["/todo/:list-id/:item-id"  :get    [entity-render list-item-view db-interceptor]]

kommen11:09:18

which seems to me it will be easy to miss stuff here. but I might also be missing something still

martinklepsch12:09:01

@kommen I’d expect there to be ways to add interceptors to a selection of routes but even if not you still can use functions to provide the list of interceptors