This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (7)
- # beginners (80)
- # boot (134)
- # cider (11)
- # cljs-dev (5)
- # cljsjs (3)
- # cljsrn (19)
- # clojure (144)
- # clojure-austin (2)
- # clojure-berlin (3)
- # clojure-greece (6)
- # clojure-italy (3)
- # clojure-russia (95)
- # clojure-spec (57)
- # clojure-uk (120)
- # clojure-za (2)
- # clojurescript (71)
- # component (1)
- # css (1)
- # cursive (22)
- # datascript (2)
- # datomic (101)
- # dirac (9)
- # docker (3)
- # emacs (10)
- # events (2)
- # immutant (3)
- # leiningen (2)
- # om (63)
- # om-next (1)
- # onyx (6)
- # pedestal (55)
- # portland-or (3)
- # protorepl (2)
- # re-frame (30)
- # reagent (10)
- # ring-swagger (1)
- # rum (31)
- # spacemacs (5)
- # specter (9)
- # untangled (90)
- # yada (2)
@curtosis Depending on when you last used it, the big story is probably breaking out some parts so they could be used independently of the web framework. E.g., interceptors can now be used in any Clojure application. Pedestal has also grown logging and metrics in recent times. Oh, and 0.5.2 was released today.
When using interceptors, would it be an anti-pattern to add stuff to the beginning of the queue by recreating it with existing items at the end?
I have a situation where I want to do thing A or thing B based on the resulting context from a previous interceptor basically
@martinklepsch i don't understand your first sentence but I have made a authenticate-interceptor-->authorize-interceptor chain where I put user data in context inside authenticate-interceptor and the authorize interceptor do things differently based on the rule and user data put by the previous (authenticate) interceptor
@mtnygard thanks … I think I last played with it a few months after the app side went away. So it’s been a while. :slightly_smiling_face:
@mavbozo What you’re describing is Interceptor A influencing the behavior of interceptor B. What I’m trying to figure out is how the result of Interceptor A could influence wether interceptor B or interceptor C is used.
> When using interceptors, would it be an anti-pattern to add stuff to the beginning of the queue by recreating it with existing items at the end?
Agreed that this probably wasn’t very clear. :slightly_smiling_face: The
::queue in the interceptor context is a FIFO queue which means I can’t add things to the beginning without recreating it completely (I think). Does that make it any clearer?
as far as I know you can change interceptors queue, similar to what router currently doing
I dont understand this, but maybe it can help you: https://gist.github.com/ohpauleez/15522bc408d8e09cd7657dd768643a5f
You’re right about the router modifying the queue but it adds interceptors to the end of it not to the beginning
@mtnygard thanks for replying! do you know what’s the most common way to test it, even if not using the mock requests from io.pedestal.test?
I think would get it working so I’m mostly wondering if I’m setting myself up for failure with this kind of thing
maybe you can always have these intercepters, but they will work only in case of some attr attached to context map? (I assume you want them triggered in :leave state)?
(I want them triggered in :enter but I don’t think that’s too important… not using them in the context of HTTP reqs)
Posted to the mailinglist: https://groups.google.com/forum/#!topic/pedestal-users/j4Sbjmw2cd4
@martinklepsch interesting, according to this old guide https://github.com/pedestal/pedestal/blob/94632d306fdaac5411a0a1ae13b7c0ce987883e9/guides/documentation/service-context-reference.md
there is a key
:io.pedestal.impl.interceptor/stack inside context which is - A PersistentList of interceptors which still need to be executed during the 'leave' stage. So long as this value is not empty, the tail of the list will be removed and executed.`
maybe inside B interceptor you could push the new interceptor X to
i.p.i.i/stack so that the leave chain become for example A <- X <- B <- C
I’m curious where/why people are picking pedestal to build on these days. Sort of a meta “where does it fit in the current landscape” question.
@curtosis I feel pedestal features makes my code easier for me to understand. routes as data makes specifying routes and generating url in html pages unified--I don't have to hard code url in html template.
routes as data makes me easier to specify different interceptors for each part of the website inside one route data. for example: my web-app could have different interceptors inside /backoffice and /api path while the rest of the paths /* are for customer
injecting dependencies become easier--just put the required components inside context instead of putting the required components inside :request or :response map. It feels cleaner
just my personal feeling about pedestal. I never used modern framework such as Django, RoR, CodeIgniter seriously. Before using clojure, most of my time I maintained and developed non framework PHP web apps.
my recent experimenting has been mostly in untangled, which is more of a om.next-centric story
(not to take anything away from untangled-server, of course; it’s just first and foremost conceived as a backend for the untangled om.next-based front-end)
I’m trying to get a better mental map of where pedestal sits today compared to, say hoplon or luminus (to pick two that come to mind)
Hi everyone, beginner here. Im going through the beginning tutorials on the pedestal website (http://pedestal.io/guides/hello-world) and I have question about restarting the web server in a repl. The guide says I can just press Ctrl-C and it will kill the server which it does, but when I try to restart the server using (hello/start) it says the port is in use. Is there a different way to kill the server which releases the port so I can easily restart it?
@dfcarpenter can you try again the steps but after you press Ctrl-C, please check whether the server is really killed by accessing the
/greet url in the browser
@dfcarpenter I typically bind the server to a var when starting. I then stop it using
http is an alias for
@mavbozo It looks like it isn’t. When I run the curl commands I get back a response.
@ddeaguiar Ahh good idea. Ill try that. No i’m using the boot repl configuration in the tutorial
In the next part of the guide it tells the reader to restart the server based on changes but it isn’t clear how to do that well. Maybe I should open an issue for it to be to clarified (like using a var for (hello/start)?
you can still using the guide but add
::http/join? false in the http/create-server function
@dfcarpenter the guide should be updated. If you don't bind the result of starting the server to a var then you can't stop it without killing the repl
At the risk of being pedantic, I'd extend that to
(alter-var-root #'my-server io.pedestal.http/stop)
hmm, just saw Paul's response on the pedestal mailing list. I think I'm going to close this PR