00:00:16.480
um if you don't know who i am my name is chris kelly if you thought this was brian's talk i think that's a
00:00:22.640
next door so i would recommend that one at some point in time it's probably a great talk
00:00:27.920
brian does a great job but hopefully you're here to see me and thank you for coming and giving me some time today i really appreciate that
00:00:35.600
um on the interwebs i go by amateurhuman and so you can hit me on twitter and
00:00:41.440
github and all the internets of various sorts at amateur human i'm open for anything i
00:00:47.360
love chatting and talking so that's usually twitter is a great way to kind of get in touch with me and if you want to have a longer conversation then
00:00:54.079
you know email after that i work for a little company called new relic um you might have heard
00:00:59.199
that we're hiring obviously um and i would like to promote that and i really
00:01:04.239
enjoy working at the company i'm a happiness engineer there and what that really means is i get to work on stuff that makes people's days
00:01:10.080
better and now i'm currently building out a labs group that really kind of gets to
00:01:16.159
look at stuff that's interesting in the world but doesn't have a direct relation to our current products and see how those might apply maybe in a
00:01:22.560
couple years but it's a lot of it's a lot about experimentation and fun so i'm currently
00:01:27.759
building that group out and having some fun times with it and we also have a party tomorrow night so
00:01:33.119
if you guys haven't signed up for that you should and come hang out with us and learn a little bit about us
00:01:38.880
so this is really a conversation um these ideas that you're gonna hear aren't solid i haven't said these are um
00:01:46.560
how i do things or how i always do things this is an evolution of some ideas you're gonna hear some things that are
00:01:51.680
kind of emerging um some there's going to be some buzz where bingo will play a little later
00:01:56.960
and so keep that in mind that we're actually having a conversation here and i want to continue this conversation i
00:02:02.000
want to hear about it later on twitter and want to know what your thoughts are how other people are doing it because it's very very new so um
00:02:09.520
most recently i um so i'm from san francisco and i gave this talk for the very first
00:02:14.640
time a week ago in uh in poland so at railsbury um that was a very exciting conference it was
00:02:20.959
its tagline was for curious developers and so this talk happened to fit really well into that and
00:02:26.400
um so i flew halfway around the world to go to that and as apparently as a tradition railsbury
00:02:31.680
and rails conf like to butt themselves up against each other after a week so then i have to fly across the world again um
00:02:37.599
and luckily for me i actually am speaking on ruby garbage collection in scotland so i have to fly across the
00:02:42.959
world again in a week after that um and then i'm going to spend a little time in poland again which will be my
00:02:48.640
second visit in poland um to go to djangocon um eu and don't don't hate me i'm just going
00:02:55.440
because i'm halfway across the world um so i'm gonna then fly all the way across the world again
00:03:00.959
and so that's about the next five weeks of my life oh and i stopped at denver a little after that so um i wanted to
00:03:07.200
get to know kind of what i do and where i go because a conversation is about building friendships about
00:03:12.720
understanding context and so i'm bouncing around the world and kind of meeting all these people
00:03:18.000
and getting these ideas um and that's really where a lot of this talk comes from is having interacted with a lot of different people
00:03:24.159
and kind of experimenting with that the first web browser i ever used was uh
00:03:29.280
lynx i'm not sure how many of you are familiar with links um nice i love it so it was probably as
00:03:35.920
usable as this slide is right now so um it's a text-based browser it
00:03:41.280
didn't have images i was using the internet before the image tag was even ratified yet in http um so you know that's good times and i
00:03:49.120
wasn't really excited about uh basic or computer programming or anything like that that wasn't what got me excited what got me excited was the
00:03:55.519
internet i really came into my own when it came to being able to browse online and explore what the world has to offer when
00:04:01.840
it comes to the internet that's really where i spend a lot of my efforts and a lot of my thinking so i'm very much internet
00:04:07.439
focused more than i am just you know software developer focused this is jif
00:04:12.799
it's a excellent peanut butter um that's animated jiff
00:04:20.239
that is not an animated gif i say gif other people say jeff we're
00:04:25.440
friends now we're having this conversation we're becoming friends we can disagree on that but it's animated gif in my world not animated jif
00:04:33.600
i also love ruby and this is important i call myself a rubyist not a software
00:04:39.440
developer because the tools we use play a lot of context in what we think right if i'm a rubyist that means i
00:04:45.840
think about tdd or i think about the interface of the programming language if i do python or java i think about
00:04:51.600
those things differently so it's important for you to know that i'm a rubyist and not just a software developer i care about the language and
00:04:57.520
i care about the things that it it kind of bestows upon me
00:05:03.280
thank you so you're here because you have a monorail you probably have an application that's
00:05:09.520
a few years old it's been you know growing and maturing you probably weren't thinking about oo
00:05:15.680
design three or four years ago when you started the thing um that conversation has really emerged
00:05:20.720
in the last 18 months or so and that's been very exciting for us as a community um you might have actually
00:05:25.759
built your monorail pretty well it might have some stuff living in the lib directory so you kind of got it isolated and
00:05:31.120
easy to test um and you're like this thing's giant and i
00:05:36.639
can't deploy it i can't deploy components of it very easily i have to do all this extra labor in order to get
00:05:42.880
it to scale i can't change it very easily and so you're like how do i get rid of
00:05:48.639
this how do i fix this problem and that's probably why you're all standing here in the back of the room um this isn't really a talk
00:05:54.880
about soa service oriented architectures i'm this is a talk about
00:06:00.319
that world but so has a lot of baggage with it right just like ruby has baggage so has baggage it comes
00:06:05.360
from you know the old worlds of java and whatnot um so i don't want you to think about soa when you're thinking about this
00:06:11.680
we're going to bring some new language in together so if you want to scale and you want to
00:06:17.120
deploy independently and you want to work on that what you're talking about is software architecture right
00:06:22.800
that is that is what this world is uh you're looking at when you're trying to break up this really monolithic rails app you want to do software architecture
00:06:28.960
and i know what you're thinking we're friends i can read your mind i did not go tell you to yourself
00:06:35.280
you guys are the ones that want to do software architecture you want to split up this application into its own little
00:06:40.479
components and that's what you guys want to do i'm here to just chat you about it um but software architecture is really
00:06:46.319
about partitioning systems it's about identifying components and identifying how those components communicate
00:06:51.360
together that's what software architecture is and so we have to deal with that and so
00:06:56.479
get the baggage out of software architecture the world of that um and think about it in in a different
00:07:02.240
way and for software architecture the biggest component that you need to care about is abstraction we want to figure out a
00:07:09.360
way to encapsulate this functionality into a single component and how those components will talk to each other so
00:07:16.720
i don't like the word soa i like the term network-based application software i think that
00:07:23.520
characterizes what we're actually doing better i don't know if we're building services i actually am building network-based
00:07:28.960
applications these are these components that all work together and have to kind of coordinate to
00:07:34.960
fulfill a request i'm not necessarily building a service i think i'm building an entire ecosystem and application and this is a
00:07:42.319
phrase from roy fielding um from his dissertation which you might may or may not have read and we'll get into more of that so
00:07:49.199
um when you're thinking this think about it from a network-based application software and think what that might mean first let's look at
00:07:56.080
what your application probably looks like right now right so you've got this monorail you've got some cache
00:08:01.520
hopefully you've got a caching layer and a database and then inside of that monorail you've got these objects that are pretty much behaving
00:08:07.680
pretty well you know you might have a god object or two that are communicating but for the most part you might even be using like service objects that
00:08:14.080
you know are working through other objects um most likely though your application looks something more like this
00:08:21.199
and that's okay there's nothing wrong with that this we're talking a four-year-old application if you're looking at code from four
00:08:27.039
years ago and you're not like that's the worst code i've ever written you're probably not doing it right
00:08:32.640
and so we have these things and that's fine there's nothing wrong with that this is just how we grew up but i'm your
00:08:38.560
friend i'm going to give you the benefit now it's going to look more like that um so what if we flip this image around
00:08:44.560
what if we look at our applications kind of differently what if we look at our applications as individual objects if there's a small
00:08:51.279
chunk of of application implementation within these different objects this is kind of how we function already
00:08:57.600
if you use anything from like facebook or twitter integration if you use zendesk or payment processor
00:09:03.600
uh you have legacy applications that you know from old java service that was written by somebody that's long gone
00:09:08.959
from the company you're probably already building an application that looks like this calling out to these external services
00:09:15.040
already look like network-based applications right so we're just going to take it to the logical conclusion instead of trying
00:09:21.120
to wrap all of our application into this large monorail why don't we split it out in the same way that we split out our
00:09:26.880
uh you know our graph system from facebook and our payment processor to braintree um look at it that way rather than
00:09:33.279
trying to think of like well i'm going to encapsulate everything in this one monorail and then have these services on the outside of it
00:09:39.920
now your application is probably a special snowflake everybody's application is a special snowflake we saw
00:09:45.200
what your application probably really looked like and the thing about snowflakes is that they break any time you change
00:09:50.800
them every time you move one little component it breaks
00:09:56.320
now some of us have you know spent some time in in physics you know you know understand crystalline
00:10:02.000
structures you move one little component and crystalline structure the entire thing will fold on itself right
00:10:07.200
and snowflakes aren't any different and that's what your application is doing but your application is a special snowflake it's falling in on itself
00:10:12.800
every time you make another change what we want is an application system that is modifiable right that is
00:10:19.519
malleable to making changes that's what we want to get to because my applications are never done no matter how many years i've been
00:10:25.680
working on them that application is never done my application will always be changing so
00:10:31.040
how do we do that so what ends up happening is you end up
00:10:37.360
with these dependencies right because if that if that crystalline structure has that one component moved
00:10:42.720
it's dependent on that one structure right the whole thing falls in on itself now we have these applications that are
00:10:52.399
communicating each other these objects are communicating to one another and these objects are passing messages back and forth
00:10:58.560
as we saw in that diagram earlier now each object has to know a little bit
00:11:03.680
about each other in order to pass the right messages which message are you sending which object so that coupling creates a dependency
00:11:11.200
and we have a system for managing these dependencies we call it object oriented design
00:11:16.640
um sandy metz has an amazing book on this topic if you haven't read it i think you should get up now and go read it
00:11:21.920
i won't be hurt but we want to look at object-oriented design we want to look at how objects can be applied
00:11:28.000
to our application layers object oriented design allows us to be make flexible applications so for those
00:11:34.959
of you that aren't familiar with objects and object oriented design we're going to go over that a little bit and then we'll get into some more detail
00:11:41.040
so an object is made up of two components first it's got state or data
00:11:46.079
you know it's got some information about it and then it's got behavior now this is all you need to know about objects right there right that graph
00:11:52.880
is entirely representative of all things about objects
00:11:57.920
then when we have an object oriented system we have these other objects communicating they're passing messages back and forth
00:12:03.600
now sometimes we have objects that behave badly sometimes object other objects communicate to our primary object and
00:12:10.160
manipulate its state directly that's a bad object we don't want objects that can manipulate state we
00:12:15.519
don't want objects that can manipulate data to other objects we want objects that are fully encapsulated we want to
00:12:23.040
the only way for state to be modified is through modifying through behavior through this external application
00:12:29.440
interface um that objects have to call in order to modify the state of another object
00:12:34.480
this is a more accurate depiction of what we want in object-oriented design
00:12:40.320
and you're like cool story bro we're not talking about objects we're talking about uh
00:12:46.720
applications right we're talking about how do we build these soa applications for lack of a better term well
00:12:53.120
this has already been thought about and like most things in computer science we're not the first people to think about it
00:12:58.160
this has actually already been done before long before us someone came up with the idea of http
00:13:03.440
object model this existed 20 years ago you probably don't know it it's changed its name it's called rest
00:13:10.240
that's the same thing so what we're talking about is rest that's how our applications and our
00:13:15.680
objects as applications can communicate to one another rest is a series of constraints being put on top of http
00:13:22.720
so as long as you're still with me we'll go over a little oo design now to understand that our
00:13:28.480
applications can actually function like rest or can actually function like applications
00:13:34.639
so we've got any number of things in oo that can help us do this things like dry and single
00:13:40.720
responsibility not everything in object oriented design is applicable to
00:13:46.240
application-based network-based application software mostly it comes around to doing patterns
00:13:51.839
you know the gang of four book is great but patterns are problem oriented and architectures
00:13:57.199
aren't problem oriented so you can't just go and take the decorator pattern
00:14:02.720
and plop it on a service and think that's going to solve anything that's not going to solve anything but there are some things we can use so
00:14:08.560
just be aware of that so first we've got single responsibility this is probably the cornerstone of good
00:14:14.000
or design single responsibility is you know do the smallest thing possible and nothing more
00:14:19.519
now you've heard this in other applications you've heard this in things like do one thing and do it well right the
00:14:25.920
part of the unix philosophy dieter rams you know a big inspiration for apple design
00:14:31.440
talks about doing simple design is do the simplest thing possible but not simpler sandy metz
00:14:39.360
talks about single responsibility on a system of cohesion and i like this because single
00:14:44.399
responsibility doesn't mean you have to do this one very narrow thing it just means that the things that it does have to be cohesive together
00:14:50.880
it has one sense of responsibility and that's what's really important
00:14:56.079
and then there's don't repeat yourself now don't repeat yourself often gets conflated with copying paste in code
00:15:01.440
and actually has very little to do with that um in the pragmatic programmer andrew hunt and david thomas talk about
00:15:06.959
i don't repeat yourself and it's about the where does knowledge exist where does
00:15:12.320
the information about an application exist um and what we want is a single authoritative source that's what the
00:15:18.639
don't repeat yourself is don't this object in this object cannot report on the same piece of information because if you ever change that
00:15:24.399
information then you have to change both objects so that's what's most important and then
00:15:29.920
we want to depend on behavior and not state or data as it may say so behavior
00:15:37.199
is invoked by sending messages between objects and if we've got a single responsibility object that has
00:15:42.880
one sense and we have that object that um has dry then that behavior exists in only one
00:15:49.120
place it's only on one single object so when we depend on that behavior
00:15:55.120
then we only have to change it in one place because it only exists in one object and it's always only going to exist there so that allows us to be much more
00:16:01.440
flexible and so that's what it means to depend on behavior and not data
00:16:06.480
dependency inversion is a weird one because i think the name isn't indicative of what it is at all um
00:16:13.680
it's about depending upon higher level model modules depending on lower level modules
00:16:19.199
in the end you don't want anything to depend on anything so this is really about building abstractions about building an interface
00:16:25.440
to your objects so that they don't depend on one another and so dependency conversion is something that we can use and
00:16:31.920
it sort of comes inherent with single responsibility and dry comes with that glove demeter or lav demeter depending
00:16:38.320
on your pronunciation um is also another component this one's a little trickier though because
00:16:44.399
this is more of a guideline as a if i was a pirate lobdemeter is about one object talking
00:16:51.199
to a second object to get to a third object now that's kind of contentious right because if i've got an account and i've got an address can
00:16:58.079
account not get to the city of that address is that some kind of violation this is very much a judgment call and
00:17:03.360
you're going to have to kind of work through that just be aware of it that's something that's going to be on your radar
00:17:10.559
so lastly we have dependency injection dependency injection is about stateless
00:17:16.480
functionality we want to pass along whatever information another object needs in order to get the
00:17:22.559
information to complete its request we don't want to cheat our way around it
00:17:28.400
and the biggest thing you'll probably see in application design is sort of a an anti-pattern so if
00:17:35.440
you've ever built applications and you're like i want to i want to cheat you probably have all these little services and they're all
00:17:40.640
talking to a single database you're like i'm going to be good these tables belong to that service and these tables belong to that service i'm not
00:17:46.960
going to cheat don't lie to yourself i've done it i've written applications that cheat
00:17:52.480
because i don't want to spend i don't want to deal with the network overhead of making a secondary request the database is already connected so why
00:17:59.120
don't i just grab that information eager load it into the the final object and deal with it so don't do that um and law of demeter
00:18:06.559
will kind of guide you on this it's sort of indicative of it but here's the
00:18:11.600
public service announcement that has to go along with this cash is king if you don't have a cashing strategy
00:18:16.960
when you start you're done for this application cannot go into production unless it has a cache because
00:18:22.880
network-based application software has so much additional overhead about the the network spin up times and the
00:18:28.799
multiple requests you're gonna have to keep making that if you don't cache that stuff you're gonna your application will
00:18:34.000
respond in four eight twelve fifteen seconds time out um we're not we're losing um sort of the the
00:18:40.559
adjacency that these objects normally would have and applying it across a network application so you need to have cash
00:18:47.600
you know networks have more application or have much more overhead than just making a single service call serialization is really
00:18:54.840
expensive and you don't want to do it if you don't have to um one of ruby gems biggest problems is
00:19:01.039
rubygems.org is the serialization of the objects and that's the most intensive component of the application itself to send them down
00:19:07.600
when you do a bundle install serialization is expensive so cache control and e-tags are your
00:19:12.960
best friend a lot of people use cache control in e-tags but they don't use them well this is something you have
00:19:18.240
to get very familiar with you have to understand in order to do this kind of thing and caching needs to be a first order
00:19:23.520
feature again public service announcement do not put this into um production without some
00:19:29.760
kind of caching already established putting ten thousand lines of code into production and then saying like i'm gonna put a
00:19:34.799
caching layer in later you're never to put it in you're never having to like spend all that time
00:19:40.320
re-implementing it it's just a giant painting this i've done it don't do it we're friends learn from me so we spent
00:19:47.600
a lot of time talking about how to how to group our classes together right are objects
00:19:52.880
but really oo design is a message and message passings and we have messages in a network-based
00:19:59.679
application software right we have these things already they're called apis but this is not an api
00:20:08.720
how many people have done this how many people have done response to json and now i've got myself an api
00:20:15.120
it's okay friends here we can admit these things there's nothing wrong with that that is something that we just did um
00:20:21.919
but it's not an api for a number of reasons it's not an interface an interface is something that's thoughtful something you considered
00:20:28.480
building when you're designing an interface for a web browser you know if you're doing uh css and html you're building an
00:20:35.039
interface and you're thoughtful about it you just dump on the screen this is not thinking about what that
00:20:40.480
interface is going to look like it's also not really an application
00:20:45.520
right this is a database access interface that's all that is and we're looking for application
00:20:50.880
programming so we want to do we want to think about the interface we're building we want to build an interface that allows you to do
00:20:56.240
application programming not database access so interfaces are all about nouns and verbs
00:21:03.360
um in oo our objects are often nouns and our messages are often verbs so you know
00:21:11.440
to use a basic example user.create i've got a user object a user now and i want to create
00:21:16.720
something right it's very very classic but our apis rarely have verbs in them
00:21:22.000
unless you were in 2002 writing php and you ended up writing things that look like that
00:21:28.159
or if you happen to be using any kind of jsp or asp shopping cart system if you ever looked at like the checkout
00:21:34.320
process and watched the url structure it looks a lot like that um i'm not talking about building this i'm not
00:21:39.520
saying hey let's get a get rid of this restful structure that we used to do and start going back to this i'm not saying that at all
00:21:46.080
but this is not what we're talking about this is not the verbs we're looking for http already does have some verbs right
00:21:52.799
we've got uh you know the get post put and delete that's pretty cruddy right create read update delete thank
00:21:59.520
you for the laughter on that i'm good at bad puns um
00:22:04.880
so if you've got a user you know if you've got a a get account 173 then that's kind of like a you know
00:22:10.880
a read right that's that's a verb and that's a noun that's kind of close but then all the interface would be
00:22:17.679
entirely limited to those four verbs and a couple other extraneous ones that don't really matter but we don't build
00:22:23.360
interfaces that way we want an interface that's more verbose than that so those verbs aren't going to do us so
00:22:29.360
you're probably thinking i know because we're friends what about hypermedia i've heard of this
00:22:34.559
this hypermedia thing is coming out right this hypermedia thing is pretty cool and i am talking a little bit hypermedia
00:22:40.559
this is what we're talking about hypermedia is a series of constraints that fielding put on top of rest and it's really what
00:22:46.240
he was thinking when he wrote the rest paper um his art his dissertation uh the architecture of
00:22:53.520
application network-based applications software um is the somewhat close to the title of
00:22:59.520
his um dissertation no offense to roy fielding um
00:23:04.559
so what we want to talk about is how can we apply the how can we apply the the true nature of
00:23:09.919
rest um to these message systems to our apis in order to create this a much more object-oriented design
00:23:18.000
and this is not your rails rest um rails does a fine job at rest it does a fine job at building restful
00:23:24.240
resources like this but it mostly stops there if you look at rest inside of the rails guides it's actually inside of the routing
00:23:30.720
system and that's about building uris now that's fine but a uri is not an
00:23:36.559
interface the uri is actually an implementation detail the the nature that orders are embedded
00:23:42.480
inside of accounts is an implementation that i my application if i was consuming that uri
00:23:48.000
i would have to know that and it will always be that way i would probably construct some client that knew how to construct this uri
00:23:54.000
and now i've got this really tightly coupled implementation to implementation detail not to behavior
00:24:00.320
i want to tie it a behavior this is implementation so
00:24:05.760
what do we do hypermedia is a uh restful system that combines a media
00:24:10.880
type and link relations perfectly clear right it's like clear as mud let's take a look at an example of
00:24:17.520
this so um a media type is really a for lack of a better phrase a schema of
00:24:24.320
how an application payload is released so this is a hal json which is a schema or a media type for
00:24:32.880
hypermedia and so you can see two major components you've got the top component which is the uh the links array and then below
00:24:39.919
that we've got this embedded orders right so we're delivering two different things we've got a series of links and link relations and
00:24:46.320
then a series of data now this is pretty important because this looks a little like state and
00:24:51.679
behavior right if i want if i got this back and i had an application interface that was able to
00:24:57.360
go to the next order right because i'm returning a series of orders i want to go to the next order
00:25:03.120
i can look that up i know exactly where that is i'm not dependent upon what the structure of this account order
00:25:09.679
system ever looks like if that ever changes all i need to know is inside of the links uh array i've got a
00:25:16.480
next ability and then i also deliver myself state i've got my state i've got a number of
00:25:22.000
orders right so there's one order in this example totaling uh one through three seven um and it's got itself it's got
00:25:28.080
its own behavior along with it right it's got its own link relation payload with it um and now imagine a
00:25:33.440
world in which you had something that looked like that what if i want to cancel an order now i know where to find that
00:25:40.320
um that would be a pretty cool world i think so let's take a look at an example um i
00:25:46.240
don't know if there's any githubbers in here when i was at railsbaron they gave this talk there were like 11d githubers in the room
00:25:52.080
um and so i was really worried like they're going to get really mad at me because i'm using them as an example but they do a decent job of hypermedia
00:25:58.080
at least they proclaim that their api is hypermedia so we're going to look at it a little bit and kind of see what future we might
00:26:03.440
might behold so this is getting a single issue you can see this is all from the documentation
00:26:08.960
basically copy and paste it and then you know putting a weird font so getting an issue is pretty easy you
00:26:14.799
can see a number of components the thing about hypermedia with github's api
00:26:20.000
is that anything within underscore url key is a hypermedia link so their client
00:26:26.320
consumers basically search through the keys and find these underscore urls and that's their sort of link relations that they can follow so
00:26:32.240
in this case there's only one link relation it's the html endpoint let me see this
00:26:38.159
this uh issue is currently open what if you wanted to close an issue if you were building an object oriented system and you were like
00:26:43.760
i have these issue objects and i want to close it you would probably call what dot close on it makes sense how do i close this
00:26:49.919
issue according to the api documentation i have to send a patch request to a url
00:26:55.919
with a with a payload of state being closed well that seems
00:27:02.799
quite a lot like manipulating data and not implementing implementing behavior right
00:27:08.799
what happens if the state has multiple states what if i'm what if we're using bugzilla
00:27:13.919
and it's got like 7 500 different states to exist conveniently github currently has two
00:27:19.919
states open and closed but now every client that implements this api has to remember and has to know
00:27:25.520
what states can and can't exist what happens if state moves somewhere else inside of the issue itself
00:27:31.279
then our clients are now becoming very tied and very dependent upon these implementations so anytime they change
00:27:37.279
their api my client has to change and that's exactly what we don't want to do
00:27:42.320
so let's take a look at another example getting a pull request so similar situation here but we've got
00:27:50.240
many more urls to uh pull from um patch issue diff but none of them are closing or merging
00:27:58.159
this pull request right what happens if i want to merge that seems like something i want to do
00:28:03.520
as an object as a as a pull request object i feel like i should be able to merge it that's behavior i think i want to implement
00:28:10.240
so how do i merge a pull request using the api well this is the merge button api
00:28:17.840
and so you can see the url structure is different here so they they put a verb on the end of the url
00:28:24.640
and then you put an optional payload of message yellow obviously
00:28:30.399
um but is this truly hyper media or is it a an effect of the
00:28:36.559
fact that they're not manipulating data right there's not a database backing this this object merging a pull request isn't
00:28:43.440
something you can say like oh i'm going to change this state from open to closed or did they really think through it as
00:28:48.880
as hypermedia would it have been better to have a a url here that said the merge url and
00:28:55.919
then given that to me and then i would know how to call that so i'm not sure i haven't had a chance to
00:29:02.559
really dig into it with any of the epi team at github to find out what they were thinking on that but i think that's i do like the notion
00:29:09.520
here that you know i've got a verb acting on some objects i've got some nouns i've got poles and
00:29:15.840
i've got a verb acting on it that's the world we want to get to so some of the things that are
00:29:23.600
kind of going on in this space um first we're already seeing this happen right the world is already kind of
00:29:28.880
implementing some hyper media um there's a uh
00:29:33.919
i don't know a movement i guess a a called hadios which is hyper hyper media application
00:29:40.720
what is it hypermedia as the engine of application state now think about that parse out that phrase for a second
00:29:46.799
hypermedia is the engine for for application state it sounds like
00:29:52.399
behavior to me right haydeo sounds like it's behavior and that's really important something
00:29:59.840
really interesting here though is that how many of you work on mobile apps have a a client a you know native mobile app
00:30:06.640
that is installed somewhere or has a company that does that okay that's that number will probably
00:30:12.240
double next year and the year after that it'll be everybody um the problem with things like native
00:30:18.640
mobile apps is that their clients are already installed what happens if you change your api
00:30:24.799
you can't force an update to that application that client will always be on that mobile phone and never being able to get
00:30:30.960
rid of new relic has a series of our agents have a have a long history and there's a number
00:30:37.279
of agents that weren't very smart at the very beginning they didn't know how to talk to our collector network in a very smart way and we can't force
00:30:43.520
our users to upgrade we're not going to say like sorry that agent is no longer supported you can't report data to us
00:30:49.279
we have to have all this infrastructure put into place in order to still allow these old agents to go and talk to our collector network
00:30:54.799
i'm through this proxy system so if you've got a mobile app that has a changing api because
00:31:01.519
applications are never done wouldn't you want something like the ability to do a merge what if your
00:31:08.960
client what if you built a client inside of your mobile app to be able to navigate this structure um like we see in hal over however so
00:31:16.320
what if we all you have to care about is that the the cancel link always exists and then your application
00:31:22.559
your client inside of that um inside of that mobile app can just call the cancel whatever happens to be
00:31:27.919
delivered that is how you will cancel this order forever and and ever that sounds pretty
00:31:34.000
nice you have to keep dealing with these versioning systems on apis and keep dealing with this mess of a
00:31:39.600
junk drawer that probably is your api directory we want to we want to live in a world that's much much more akin to that
00:31:47.519
so you can build custom media types that's awesome but that's also pretty awful
00:31:54.880
um it's awful because it's hard to find client libraries for these things how do you build a client library that
00:32:00.159
everybody can use how do i how do i publish a gem that adheres both to the github style of
00:32:06.399
of hypermedia as well as the hal style of hypermedia i can't and that's a problem i'm not
00:32:12.480
saying that we have to um we have to unify i don't think that's necessarily the case
00:32:17.840
but be aware that you'll probably be building your own client consumers and in that case um make sure
00:32:24.240
that's when hypermedia becomes really powerful when you can control the client for some existence or how the client consumes an api that's
00:32:31.600
really what we care about there's collections json there's hal json there's the github custom version
00:32:37.440
so that's part of the bad and the ugly is that there aren't any http verbs
00:32:43.039
along with these requests how do i know in this if there was a a merge url how do i know if that's a
00:32:49.919
patch request a put request to get most of that is missing out of most hypermedia specifications currently
00:32:56.399
um and so we need to start thinking about that a little bit more i'm not suggesting we put new verbs into the http spec
00:33:01.600
i'm suggesting that we need to follow along and maybe this needs to be a tuple that has the the verb along with it that gets
00:33:08.159
paid it's sent along with the payload so we know how to um complete this request um
00:33:14.720
i think our apis and our api consumers can be much more oo designed i think it seems like that's an awesome
00:33:21.679
world in order to that i don't have to do these versioning systems on my apis i've done that i had to maintain them they're terrible
00:33:28.080
i've i've made i've made api proxies that that translate an old api into a new api
00:33:34.000
and that's awful i want to be able to just call cancel and that order will be canceled no matter what the url
00:33:40.080
for that actually ever ended up being so i want to say thank you very much for
00:33:45.200
listening and let's continue to chat i'm on twitter's at
00:33:50.840
amateur.human
00:34:29.520
you