James might be too modest to mention this as an exemplar as he's the maintainer, but for me, Ring <https://github.com/ring-clojure/ring> is a great example of the success of data-as-API. HTTP requests are represented as a nested map with well-known keys, and middleware works with these fields or even adds new ones.
On 18 October 2014 16:50, James Reeves <ja...@booleanknot.com> wrote: > On 18 October 2014 08:28, Mark Engelberg <mark.engelb...@gmail.com> wrote: > >> Yeah, it's hard to deny the convenience of Clojure's keyword lookups and >> standard assoc mechanism for getting and setting stored values, but I think >> Bertrand Meyer's Uniform Access Principle reflects some pretty deep >> thinking about the kinds of complications that arise in maintaining large >> programs. Although the Clojure community mostly rejects the Uniform Access >> Principle right now, as people start writing larger programs in Clojure, >> and need to maintain them for longer periods of time, it will be >> interesting to see if the pendulum swings back in favor of uniform access. >> > > You make it sound as if structuring an application around data, rather > than APIs, is untested at scale. I'd argue the opposite: the only > architecture we know works at scale is data driven. > > The largest systems we've developed, including the web itself, are data > driven. Above a certain size, they have to be, due to latency and > consistency concerns. Structuring a large system into isolated services > that communicate with data is a tried and tested architecture. > > There may be a place for the Uniform Access Principle at the medium scale, > where an application is large, but not so large it can't be hosted on one > machine. I don't think the relative merits of data-driven vs. api-driven > approaches has been proven at this scale. > > That said, I think there are reasons for betting on Clojure's approach. > Ultimately it comes down to whether we try to *manage* complexity or > *remove* complexity. The Uniform Access Principle falls in the former > camp, along with OOP and encapsulation. They're tools to manage connections > between components of a codebase. > > Clojure takes the more aggressive stance, and suggests that rather than > managing complexity, we should be focused on getting rid of it wherever > possible. For instance, where OOP languages try to manage state change > though encapsulation, Clojure just removes mutable state entirely, or at > least places it in confinement. > > Where complexity *can't* be removed, then we start to get Clojure code > that begins to look similar to OO designs. Stuart Sierra's components, for > instance, look somewhat similar to stripped-down objects. The difference in > Clojure's approach is that these constructs are a last resort, rather than > the norm. > > - James > > -- > 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. > -- 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.
