This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-20
Channels
- # admin-announcements (1)
- # bangalore-clj (4)
- # beginners (176)
- # boot (38)
- # cider (9)
- # clara (1)
- # clojars (9)
- # clojure (290)
- # clojure-belgium (25)
- # clojure-berlin (2)
- # clojure-dusseldorf (10)
- # clojure-italy (1)
- # clojure-russia (141)
- # clojure-sg (1)
- # clojure-spec (40)
- # clojure-uk (38)
- # clojurebridge (19)
- # clojurescript (148)
- # code-reviews (37)
- # community-development (7)
- # cursive (27)
- # datomic (71)
- # editors-rus (3)
- # events (1)
- # heroku (1)
- # hoplon (16)
- # jobs (5)
- # lambdaisland (3)
- # lein-figwheel (211)
- # luminus (3)
- # off-topic (52)
- # om (18)
- # onyx (49)
- # overtone (3)
- # pedestal (48)
- # protorepl (7)
- # rdf (2)
- # re-frame (61)
- # reagent (3)
- # timbre (2)
- # untangled (69)
How is an interceptor fundamentally different from a handler, other than the format of "context" versus "request/response"?
My service needs to make a call to another service which could take anywhere from 500ms to 1000ms, and I want to go async instead of blocking and tying up threads. Should the call to the 3rd party service go in an interceptor, or in the handler?
@joshjones Handlers are special case interceptors that operate on request maps and return response maps. I typically create Interceptors for things like validation and any other pre-processing needed for request handling. Refer to http://pedestal.io/reference/interceptors for more info
If the implementation requires some sort of post processing (i.e., transformation, etc...) I'd probably implement the 3rd party call in an interceptor, put the result on the request map and perform the transform of the result in a handler.
I'd also prefer thread
vs the go
macro because the backing thread pool used by the go
macro is limited
@ddeaguiar is it possible to share such interceptors (validation etc)?
@ddeaguiar I mean, can you please share them? 🙂
But think of it this way, these are the same operations you'd perform in ring middleware
The neat thing about interceptors is that you have access to the interceptor chain and you can manipulate it
@kirill.salykin The Pedestal docs site includes an example of an interceptor that performs request pre-processing (http://pedestal.io/reference/interceptors). The db-interceptor
associates a db to the request. In that example, the database value is stored elsewhere in a global var.
I am just looking for the good intereceptor + validation db interceptor seems simplier to me 🙂
would really approciate if you can share it with me
not urgent
thanks a lot!
Hi everybody, im gonna start implement security in my pedestal app, is friend the best framework to do that?
@lellis check out https://github.com/propan/geheimtur or https://github.com/funcool/buddy
Thank you @ddeaguiar for the info. Since the 3rd party request will take maybe 500ms and our processing will take significantly less time (probably 30-50ms max), it somehow feels strange to put the 3rd party request in an interceptor, when it will take much longer than the actual handler — but it’s what makes sense, I think, if I’m reading you correctly.
Potentially dumb question about pedestal — since the handler is the last “interceptor” to run, and it takes a request and returns a response, how to I do post-processing on the request? The interceptors seem to be pre-processing, but they work with context maps, and the handler works with req/resp maps. So how can I post-process the response map?
@ddeaguiar @joshjones Handlers can't return channels, but interceptors can.
After the context map is delivered, then the rest of the :leave functions will be called as normal
But I thought the :leave
operation accepts a context map, and returns a context map — not a request or response map
@joshjones That's right. When a handler returns a response map, Pedestal just attaches that response map to the context map, then starts calling the :leave functions with the updated context map.
Our app currently serves a few thousand requests per second, and I’m trying to improve latency by going async and hopefully pedestal will help with that — I think the best thing for me to do here is to write a simple app that utilizes the functionality of some of these pieces, and then I’ll be better informed to ask questions 🙂
1. If the interceptor returns a channel instead of a context map, then that channel can only deliver 1 value, which must be the new context map. That's the "async" case.
2. If the interceptor returns a context map with a response whose body is a channel, every value delivered by that channel is streamed to the caller. That's the "streaming" case.
Hi guys, I saw that are several ways of building routes on pedestal, this could be verified on this test file: https://github.com/pedestal/pedestal/blob/master/service/test/io/pedestal/http/route_test.clj
So my question is, how I choose the better way to express the routes of an application, is there a guideline?
Hi @marciol! The different flavors of routing syntax are there because we've had some "evolution" over time. The "verbose" syntax is not something that anyone should write by hand. It is the most expanded form, mainly intended for internal use by the routers. The "terse" syntax is good if you need to express a deep tree of routes and you want to take advantage of "inheritance" down the tree for interceptors. For most uses, I would steer you toward the "table" syntax. It is the easiest to read and write, at the cost of some redundancy from row to row.