Placeholder Image

Subtitles section Play video

  • Decoupling Applications from Architectures - Jeff Hoffer

  • Hello, all right.

  • Thank you everybody for coming.

  • My name is Jeff Hoffer, and my talk is decoupling applications from architecture.

  • I gave a talk on this side last year and there was literally 10% of the people in the room

  • that there is now, so thank you all for showing up.

  • I really appreciate it.

  • The lights are really bright so I can't see anybody's face, which is probably a good thing.

  • All right.

  • So a little bit more about me.

  • I've been professionally developing software for 20 years, and I recently joined a company

  • called bluebeam.

  • It's for the design bid and build phases of projects.

  • You can find me on GitHub at @eudaimos, it's a word I made up, kind of.

  • It was inspired by Aristotle's eudaiminea.

  • The inspiration is my son Eric who's here with my wife this week, if you see us around,

  • he's nine now, please say hi.

  • So it's appropriate that I work in a software company for construction.

  • I notice that as human beings, we've been in the practice of building things for a long

  • time.

  • We built some amazing things that have stood the test of time, beyond which most of us

  • can even conceptualize the length of that time.

  • And with software we've come up with a single-most malleable thing which we've ever had to build

  • anything, and it's been pretty great.

  • But still there's something not quite right.

  • When I worked in Santa Monica, there was a lot of construction nearby all the time, and

  • as we were walking our VP of Engineering, my boss used to point out how quickly they

  • could build these buildings versus how long it took us to deliver software.

  • [laughter] So how do we keep ending up here?

  • [laughter] We either build it too slow, we build it wrong,

  • or both.

  • And how does that happen?

  • We get asks from people who don't really know the difference between building application

  • and building it well.

  • But they want to make sure that we don't build it well, sometimes.

  • That' d be great.

  • So we end up in this Kobayashi Maru scenario and for the younger folks out there who haven't

  • seen Star Trek II.

  • It's designed to be a no-win scenario.

  • It's there to determine how we will respond, and unfortunately most of our responses are

  • this.

  • [laughter] Where the needs of the many outweigh the needs

  • of the few, right?

  • And then we get back to our brittle code.

  • So what do I mean exactly by application versus architecture?

  • So we should probably define this.

  • And we can take a step and define it based on who defines each for our software.

  • Product team will define what the application does, engineers will build it, QA validate.

  • Engineers work with software architects to define the needs.

  • They build the architecture, QA validates nonfunctional constraints.

  • So I'd like to take this and define these as layers.

  • So we have an application we call that the development layer and architecture is the

  • architecture layer.

  • And if we can organize these into layers, then we can separate them like what Docker

  • was able to do for apps in DevOps.

  • There's also four aspects of software.

  • Taking another view here, what an application represents to a user, how it does its job,

  • where it executes, and when it does what it's designed to do.

  • Unfortunately, when working between the development and architecture layers, we commingle these

  • four aspects into a kind of a mess.

  • So let's go back to our layer definition and define them using these four aspects.

  • If we say the development layer is the what and the when, and the architecture layer is

  • how and where.

  • We can organize them this way and if we can organize them this way, along these layers,

  • and make them orthogonal to each other, then we have the decoupling we're looking for.

  • So if we take these aspects and graft them on to our layers, the development layer has

  • what the context of the application is for a user, when does a user go from one context

  • to another.

  • architecturally how will the app move from context to context and where will the code

  • reacting to this actually execute?

  • So if we get into the details of that so that it actually matters to us who have to build

  • this stuff, we can borrow some concepts from computer science where we say the what these

  • contexts are signals, when is triggering and the reaction to these signals.

  • And the how is -- and the where is a signal network and the implementation of where that

  • signal network will run.

  • So I want to introduce a few things for the demo first.

  • There's RealWorld.

  • If you haven't gone to realworld.io, it's beyond a standard to do app.

  • It involves conduit which is a Medium-like blog platform and there's lots of concepts

  • which are integrating different front ends and different back ends all doing basically

  • the same functionality as this Conduit app.

  • I also wanted to introduce TAO.js.

  • There's a project that I've been working on as a solution for this.

  • It has a meta language for defining signals that end up in the code, using trigrams.

  • It provides interaction primitives to determine when to interact with these signals

  • and it implements signal networks.

  • So a trigram, the library TAO actually comes from term action orient, so we want to describe

  • these contexts with these three dimensions.

  • So term is something, action is an action taking place, and orientation -- orient is

  • a perspective.

  • Three ways to interact and respond to signals is inline, do them in order.

  • Async, do it in parallel as a side effect.

  • And intercept is do it first and optionally you can interrupt the flow.

  • And implementing signal networks, it abstracts that away from the application code, and it

  • also has the implements a signal chaining, so that if you are reacting to a signal from

  • the network, you can provide it with another signal that will chain itself, so this gives

  • us very small bits of code that we can implement now as it -- using the signal network as the

  • medium for the interaction.

  • So taking this back to our notion of aspects to layers and now to TAO.js, what we're able

  • to do with the development layer using TAO.js is the powers that engineers use to define

  • these trigrams and define the desired behaviors when these are signaled in the signal network.

  • The engineers implement these behaviors in the code using these interaction primitives

  • on the signal network.

  • And the architectural layer, we allow the architect or whoever's implementing the architecture

  • to choose the signal network, and implement using that, and decide where that signal network

  • will run, so we've now abstracted away where the code has to run in order to interact and

  • provide the development layer with what it needs.

  • A quick note about trigrams versus an application context, so think of a trigram, it's a 3-dimensional

  • signal, also an event.

  • You can subscribe to trigrams on the signal network and it's like a class in an OOP where

  • ar application context would be an object in OOP, and so it's a specific context and

  • so it combines this trigram with the actual data associated with the event that's happening

  • the signal.

  • So when going through the real world conduit application, what we'll do first is define

  • the terms.

  • We have an app, user, article, comment.

  • We'll define some actions, init, load, find, exit.

  • We'll define the orientation so we have a portal and an anonymous orientation, so portal

  • is when you're logged in.

  • Anonymous is when you're not.

  • And then we'll define some paths.

  • This allows us to understand how to react to signals on the network, and then throwback

  • new signals in order to keep this chain going.

  • And this is why we also develop or define very granular actions, so that we can have

  • more granular chains and we can hook into these at any time.

  • So I'm going to go into the demo portion.

  • OK.

  • So we're going to start with our Conduit app.

  • And -- of course! [laughter]

  • OK.

  • Oh, I understand why.

  • All right.

  • Um, so this is working with their -- with the default API, which is using a service

  • somewhere.

  • And we're going to -- oops, wrong one.

  • Sorry.

  • Of course this all worked in the room.

  • (Whispers) now completely broken.

  • So I'm going to skip showing it as a ... because it doesn't seem to want to behave with Redux.

  • So it was a Redux React based application.

  • That still doesn't want to play nice.

  • Very sorry for this.

  • AUDIENCE: You got it!

  • >> Thank you.

  • I can't see who you are.

  • But thank you.

  • All right, let's just turn all of it on.

  • Anybody know which screen I'm on?

  • I can't imagine what changed.

  • Oh, I, yeah, now I know.

  • This is the best!

  • OK.

  • [applause]

  • Getting the applause for code you didn't write, it's, thank you!

  • [laughter] So this is Conduit.

  • This is the basic React Redux example I think probably the first one they did.

  • So we're going to modify this, time willing.

  • To use TAO.js.

  • So this is actually hitting the API for that, we can sign in, go to home page, so you see

  • there's all this functionality.

  • There's lots of ...

  • so this application has a bunch of reducers that we're used to, all the Redux boilerplating,

  • the components are React, they have a lot of baked-in Redux, so we've sort of embedded

  • all of this together, what these -- how we call the API, what to do on various -- within

  • various components.

  • So if we go ahead and -- I'm going to turn off Redux logging.

  • We're going to switch to using some alternative components and not all of

  • them are necessary.