Author of bidi here.
In his blog article, REST Litmus Test for Web Frameworks -
https://www.innoq.com/blog/st/2010/07/rest-litmus-test-for-web-frameworks/
- Stefan Tilkov asks of REST libraries:
"Is there an easy way to produce links that "point back" resources
identified by whatever means the framework exposes (such as some form of
routing)?"
The idea of bidi came out of a discussion I had with Philipp Meier about
Liberator's support for hyperlinks, to meet Stefan's litmus test. Philipp
argued that while he felt Liberator should remain independent of the URI
routing layer, any routing layer that was part of a proper REST API should
make it easy, and reliable, to produce hyperlinks. Now that REST APIs are a
mission-critical part of many websites, I believe that producing reliable
working hyperlinks is too important to be left to *ad-hoc* string
concatenation, however disciplined. If the community are to standardise on
a routing library, I feel it should be one that support isomorphism (as
Pedestal, bidi and Silk do)
The design of bidi was heavily influenced by my experiences with Pedestal
routing, which demonstrated the value of a data structure over macros.
Unfortunately, I felt that Pedestal's integration of routing with its
interceptor definitions meant that you couldn't extract an independent
routing library from it. I also didn't really like the terse versus
expanded format, and wanted bidi to have a single format, one that would
strike the balance between being easy to write by hand and easy to
generate. I'm still a fan of Pedestal but wish it had been offered from the
beginning as a set of independent libraries which worked well together.
'All or nothing' is never a great choice.
Silk was heavily influenced by bidi, as Dom has described earlier in this
thread, and if you compare their source code they are very similar. Now
that bidi supports ClojureScript, the key difference is in syntax and the
fact that bidi routing is hierarchical, whereas Silk allows you to dispatch
at a number of levels, as far as I can tell. The syntax differences are
such that you could probably create some records and record constructors,
satisfying the bidi protocols, that allowed you to layer Silk's syntax over
bidi, a sort of 'silk-flavored-bidi' if you will.
The hierarchical design of bidi was driven by the desire to support
modularity- when you have multiple people or teams working on different
parts of a website, it helps to be able to 'remount' one of the parts
without anything breaking. Also, bidi excludes support for dispatching on
differences in query parameters, as I believe that query parameters
shouldn't, by definition, determine which resource is identified by the
URI. Opinionated? Maybe!
Until recently, the way that you did isomorphism in bidi was to use a
handler as an argument to path-for, which would return the route. That
required URI-forming code (like views) to have access to all the handlers
in the system - not great. I played around with using keywords, with some
funky record injection in the route structure to convert them to handlers
during dispatch, but then I looked at Secretary's 'named routes' and
slapped myself very hard on the forehead (doh!). Since then, bidi has a
'tag' function that you use to tag a handler with a keyword, from then on
you can use that keyword when forming routes instead of the handler itself.
bidi will undergo some rework when the new reader conditionals of Clojure
1.7 arrive out of beta, which I expect will replace its use of cljx.
Otherwise, bidi itself is going to remain fairly stable. It is relied on by
many production websites, such as https://www.onthemarket.com/, so can't
change radically. However, building on protocols opens up numerous ways of
extending bidi. For example, we're working on a new REST library
(http://yada.juxt.pro) which combines bidi routing structures with resource
maps to generate published Swagger definitions. This is achieved by adding
a couple of new small records which satisfy bidi's protocols, demonstrating
the endless flexibility of Clojure's protocols feature. So I'd hope that a
'standard' routing library would be built on protocols too.
So, in summary, I think it would be useful to have a single 'default'
routing library in Clojure that supported isomorphism and was built on
protocols, as a minimum. Now that Clojure is attracting so many new users,
it would be great to discuss the outstanding differences between all the
routing libraries and try to drive some consensus as to what a combined
library would include.
On Saturday, April 11, 2015 at 1:08:30 AM UTC+1, Daniel Jomphe wrote:
>
> This thread over Silk, Bidi and Secretary has been very interesting. I
> looked at the three projects to see how they evolved after this thread
> started. Any cross-pollination or progress worth sharing now that I've
> missed?
>
> From what I could gather:
>
> * Secretary is evolving towards a conservative 2.0 and won't, after all,
> be re-implemented on top of Silk. This may be a good thing: not bringing
> more transitive dependencies in all projects using Secretary. Thus,
> Secretary would remain the first stop for Compojure-like easy routing in
> ClojureScript apps.
> * Bidi was already quite mature and comparable to Silk and remains as
> attractive as it was, especially with regard to its established production
> usage and corporate backing.
> * Silk's development slowed for some time and this may make for a good
> occasion to reflect on its state and the value of its ambitions (which
> seemed quite interesting to me).
> * I would add, from distant memory, that Pedestal's isomorphic routing is
> planned to be extracted into a self-contained library. Judging from the
> advent of Clojure 1.7's reader conditionals and Om's model 2 for which I'm
> expecting an announcement in a few weeks, I suppose Cognitect may start
> providing again their leadership on the front-end. Either they start
> recommending something like Bidi or Silk, or they (more probably)
> reader-cond-port their routing lib to ClojureScript.
>
> I'm watching this space and thanks for any comments.
>
> On Sunday, October 12, 2014 at 11:28:13 PM UTC-4, Dom Kiva-Meyer wrote:
> > Thanks for the experience reports, Dylan!
> >
> >
> > Colin, Silk is Ring-compatible and meant to be used as a single
> replacement for both Compojure and Secretary (or any other server/browser
> routing combination with incompatible syntax and semantics). But, as Dylan
> said, it's totally fine to use it in conjunction with Compojure instead of
> replacement. Silk should also work fine with all Ring middleware.
> > In the next version, Silk will have a more familiar and mostly
> Compojure-compatible syntax for defining routes. My hope is that this will
> make it easier to translate Compojure examples/code to Silk.
--
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.
