Fork me on GitHub

@ddeaguiar Where should I start reading the code base to better understand what's going on?


@alanspringfield I’d start with the io.pedestal.http ns. Basically work you way back from create-server ( to see things are initialized. Where you go from there is up to you. Good candidates are the io.pedestal.http.route ns ( or the io.pedestal.interceptor ns (


The code is really clean so it should be pretty easy to follow. Keep an eye out for abstractions as you go through it


Just having an understanding of what’s going on in io.pedestal.http goes a long way imo


Knowing what default interceptors get wired up when is super useful.


hope that helps


anybody using pedestal sse for broadcasting?


Hey all, checking in mid-week during spring break here. Catching up on the conversation, so I’ll be shotgunning out on some different topics.


@rafaelzlisboa Yes, we’re definitely using SSE for broadcasting events.


what’s the best way to set it up? what i’m doing is using a mult and tapping the individual channels into a broadcaster main channel, with a watchdog to release them when there is a timeout. just wondering if there’s an easier way to implement it


I’ve not had good luck with mult and tap in the past. There’s something about them that I don’t understand. I keep a map with the connected clients. The start-event-stream function lets me identify a disconnect function that I use to clean up the map.


hmmm… then go through the entire map whenever we want to broadcast?


Yes, with a doseq.


It’s a map from a per-client key to the channel for that client.


nice! I guess right now we’re at the point of not having good luck with mult and tap hahah. it randomly stops working somedays


Yeah, I didn’t track it down far enough but it seemed like I couldn’t effectively isolate errors/slowdowns on one tap from others.


thanks for the tip


@alanspringfield Vase builds on Pedestal, so learning Pedestal is definitely a good start. Going through the HTTP namespace as @ddeaguiar suggests is the “outside to inside” approach. Depending on your learning style, you may also benefit from an “inside to outside” approach… that would be starting with the interceptors module. Pretty much everything that makes Vase interesting is about building interceptors out of data.


@alanspringfield As you get started, please take notes of anything that bites you. Or anything that just bites. The notes from @deg on doc deficiencies have been great. Each time someone goes through the process we can learn from anything that makes them stumble.


@bradford I know a few people have done multipart forms that include uploads. IDK if that means multiple parallel uploads. The multipart form upload ring middleware is probably the quickest path to done.


@deg The “self contained” part of Vase is meant to refer to dependencies. There is probably a better term for it. As far as the #vase channel… I don’t know who started it and didn’t know there was one until you mentioned it.


This channel is normally friendly enough and low volume so I’d rather not split attention there too.