On Wednesday, July 1, 2015 at 4:35:35 PM UTC+1, Daniel Jomphe wrote: > > Chris, this is definitely interesting. Quickly pluggable metrics & swagger > & trapperkeeper componentization sure are useful integrations. > > Doing a quick review, it surprised me a bit how many dependencies you > brought into comidi > <https://github.com/puppetlabs/comidi/blob/master/project.clj> > [dependencies]. >
I *believe* that the only "real" deps there are the bidi/compojure ones, and that the rest are just there to try to resolve transitive dependency conflicts (we use lein's :pedantic? flag). I will double-check that, though. > This looks more like a pragmatic, compromise integration library than a > pure new offer (just like you said you need at Puppet Labs). > That's definitely a fair characterization! > Nevertheless, since you deviate from Compojure's API, I was very surprised > to still see you depend on it. And then I remind myself that you're in > there for meaningful, but quick, wins. > The compojure dependency is because I still found Compojure's "rendering" capabilities to be really useful, and didn't want to re-invent them. But it is a compromise to have a dependency on both, to be sure. > > There was a discussion between most of the authors of the popular routing > libraries when Silk was introduced, including bidi's Malcolm, which came to > be very interesting too. > When you titled `comidi` as being "a committee approach to defining HTTP > routes", I wondered if you were following up to that discussion. Here's a > link I kept to the middle of it > <https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ> > [discussion]. > Yes, I did read that discussion before working on this stuff. In an ideal world or with a greenfield application, I think we might have just used bidi or silk directly (and, it is a goal of mine to try to make sure that our metrics stuff will work on plain-ole-bidi routes just as well as it does on comidi routes), but we have a *lot* of existing services built using compojure. In order to be able to re-use our metrics stuff across all of those existing services, the only realistic option was to try to make it as simple as possible to migrate from a compojure route structure to a bidi-backed one. > In any case, thanks for contributing to this field. > np, thanks for the feedback! > > [dependencies]: > https://github.com/puppetlabs/comidi/blob/master/project.clj > [discussion]: > https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ > > On Wednesday, July 1, 2015 at 5:45:40 AM UTC-4, Chris Price wrote: >> >> Hiya. >> >> >> We really like the syntax of compojure for defining HTTP routes, but have >> had some trouble with use cases where we'd really like to be able to >> introspect the route tree, and aren't able to do so because the nested >> functions are pretty opaque. >> >> After spending some time trying to workaround that, and giving up, we >> decided to look into bidi, which has been awesome. The data-driven route >> tree is really, really useful. >> >> However, a wholesale port of all of our existing apps directly from >> compojure to bidi seemed daunting. Enter `comidi`: >> >> https://github.com/puppetlabs/comidi >> >> This is a small library that uses bidi to build up route trees, but >> provides a compojure-like syntax for defining the routes, and uses >> compojure's "render" capabilities to support flexible syntax for specifying >> your individual handlers for each route. >> >> We've also got a related project that integrates comidi with our >> Trapperkeeper framework and the dropwizard metrics library, to give you >> middleware that will automatically track request metrics for each route in >> your bidi/comidi route tree. >> >> This is all a work in progress: notably, we had built up some prismatic >> schemas around the route structures, but since the latest release of bidi >> ships with its own schemas, we'll probably try to upgrade to that and >> reconcile the differences soon. >> >> We also have some plans for improving the ability to wrap middleware >> around the route tree at various levels, and to look into some ring-swagger >> integration soon. >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
