?

Log in

No account? Create an account
Previous Entry Share Next Entry
Reactive Programming
device
jducoeur
[Yes, I do seem to be mostly posting programming-related topics nowadays.]

I just realized that, for all that I've burbled a lot about Scala and Akka and stuff, I don't think I've mentioned the element that ties it all together: The Reactive Manifesto. If you haven't read it yet, I commend it to you: it's not terribly long, and it is *extremely* important.

On the surface, it's not hard to dismiss it as simply a bunch of platitudes, restating a bunch of obvious principles. But when you follow its logic through, you wind up with a pretty important conclusion: the vast majority of software out there does *not* follow these principles, and that's a non-trivial element in why the vast majority of software sucks.

Heck, it's even topical: failure to follow these principles is almost certainly the main reason why the big federal healthcare website melted down so badly. Yes, there were many, many causes of why the problem was hard. But the fact that the site couldn't *cope* with those issues is, I suspect, largely down to old-fashioned design. My biggest headdesk about that entire fiasco was that I, and a number of other folks I know, could almost certainly have designed a system that, while imperfect, would have worked a good deal better from the beginning. Observation of the Reactive principles is precisely why.

Before you attribute this to simply being a Scala marketing tool, keep in mind that it was co-authored by several major players around the field, such as Erik Meijer, late of Microsoft (one of the main people to whom I credit the fact that the .NET stack is the best thing about Microsoft). Indeed, while I have a well-worn cynicism of Microsoft, their better people have been pounding parts of this drum for a decade now. Hence, the Manifesto is technology-neutral -- it's basically a public statement about where software architecture needs to be going, in order to cope with the realities of the modern environment.

So give it a read, and more importantly take the time to think about it seriously. Personally, I may well print out the diagram of the Reactive Traits and pin them on the wall of my desk, as a reminder of how things *should* work...

  • 1
what do you plan to use?
RxScala? scala-react? Dire? smth else?

Not sure what you're asking about. I mean, Querki is deeply Akka-based, so that's the primary answer on the back end. (Viewed from a certain perspective, Querki is kind of like a reactive front end to MySQL, although that grossly misses the point.)

For the UI, honestly, I think the tooling still needs work. I've just started really pushing for Typesafe to take Scala.js seriously, and my current long-term hope is to help them evolve some Typesafe-native frameworks for integrating a Scala.js front end with a Play back end, so that you can get something vaguely like a Lift approach in Play. (I actually chatted with James Ward of Typesafe about that last night, since he was in town giving a talk.) Play already has some of the key elements, like WebSockets -- now, we need an easier way to work with that.

But for now, I'm just hacking in Javascript and jQuery. Fortunately, Querki's UI requirements are fairly easy so far, but that'll change as we go along, and I have plans to gradually evolve the front half of my architecture towards something more consistently reactive...

ah, so it's not "reactive" in FRP sense, but rather asynchronous and whatnot

Correct. FRP is one approach to achieving the general goals of "Reactive", but there are a bunch of others...

I have to read up on Lift approach though!

It's worth taking a look at. I wound up standardizing on Play as Querki's web platform, but that was mostly for very mundane reasons like support and size of community. But Lift is in many ways a more interesting architecture -- certainly a more unusual one, with a lot of deliberate blurring of the client/server distinction...

Well, it's obvious, but people don't get it anyway.

  • 1