 He's going to talk about hypermedia and he's beyond how this should be done with more path and react frameworks. So if you've never met Martin before but you have ever used XML with Python, chances are high that you are using his code but I will let him talk about other things. All right. So yeah, I'm Martijn Valser. I'm from the Netherlands. My wife is Singaporean which is why I'm here on a regular basis. Happy New Year. So yeah, I'm a developer and a consultant. I've been a Python developer and a web developer for a while. I was very much involved with soap. If you want to read about me not being involved in soap anymore, the history about soap, I blogged about it. It's called my exit from soap, helped create or initially started creating, started it, the GROC project which was a web framework to try to simplify some of the soap technologies. I wrote a client site, a sort of model view framework nobody ever heard about. I called OVL but you'll hear about more later in this talk and most recently I've created yet another Python web framework called MorePath and I talked about it last year and I will talk a little bit about it again this year. I also was involved starting the European Python series of conferences and I was board member of the soap foundation for a while and yeah, the software that most people use that I've written. I haven't been, there's been a very competent other maintainer, Stéphane Benel since almost the beginning when I did start the project, it's called LXML which is, if you use XML in Python in a serious way then you're likely to run into it. So yeah, initially I said I will talk about MorePath and React when I was writing this talk, of course I'm sort of talking about what I'm working on right now so it focuses around hypermedia so I'll talk a bit about what is hypermedia, why would we want a hypermedia-driven UI, I'll go into what that even is later, some ideas towards a framework for constructing hypermedia-based UIs and we will talk about MorePath and React somewhat so it will still be about that. This is a bit of a dangerous sign, usually I talk about stuff that sort of works already. Some of the stuff I'm going to talk about now is speculative, ongoing work, just got started, etc. So let's talk about extensibility first. Extensibility, so when you write design a application or a framework for extensibility you try to have an implementation that takes future growth into consideration and when you do this you can of course change the behavior of a system by just changing the code and that's often fine but often if you want to reuse that code it makes sense to follow the open close principle which is this idea that you have a core code base and you plug in plug into it or extensions or you override bits of it and by that way you extend the behavior of the system and you try to avoid, of course you can't always do it, just always changing the same core code base over and over again because you want to reuse it in multiple settings. Do we need extensibility is sort of the first question you can ask about this. Well in many cases we don't, if you write a script perhaps it doesn't need to be extensible or a one-off web application that's very fixed and presents a very fixed user interface doesn't really need to change very much over time or you're fine by change but if you need to change it you just change its code base you don't need to extend it you don't have multiple deployments of it. If you make a smartphone app typically they don't need to be extensible as well but you know those tend to be the applications that everybody sees and talks about because they're very visible to the general public but many much software development I would say most software development is sort of underwater which is sort of the iceberg of custom applications for businesses or in-house software etc. There's a lot of software development going on there and you also have the general business model where you have some core system like CMS or in ERP system and you want to deploy it for multiple customers and those systems tend to need extensibility very much and that's just there's a lot of work going on in that and another sort of more abstract reason why you might need extensibilities if you want to build an application that you want to last for a while you want it to exist not just like a half year but maybe in a furious time or even ten years which is an enormous time span in the lifetime of software. So how would you make applications or frameworks more extensible and one way to do that is to follow the hypermedia architectural pattern which is what I'm going to talk about now. So hypermedia is as well as it looks all very sounds very abstract perhaps but role-familiar with it is the web is sort of the most familiar and most successful hypermedia platform and it consists of all different kinds of media a lot of it is text or some kind of mock-up there's also graphics and audio and all that stuff and there are links between these resources on the web. And what are sort of the essential ingredients you need to add to a architecture to make it into an hypermedia architecture so I think there are just a few basic things you have these resources and they need to have some form of content type you need to be able to go to resource and then find out and it can it tells you what kind of resource it is I am a PNG file or I am adjacent file is sort of the content type system that's part of the HTTP but you can also be a bit more model oriented like I am an address or I am a customer that kind of some more application specific content type and then there are hyperlinks between these resources and how is hypermedia extensible while you can add new kinds of content to it and you can reconfigure the links like what places the links point for instance like at some point the web didn't have PNG support and then you know that they added the PNG content type to web browsers and now suddenly everybody could use that and you can also you know extend the application that people see by just adding new links to it and then suddenly you can go to two different parts of the application. So this general principle of hypermedia is that the hypermedia drives the application state and that has a very wonderful acronym that I don't know how to pronounce I'm going to do it anyway so I'm going to say hate or us maybe that's all wrong but I don't know whether anyone can do it right so the idea is that the hypermedia system drives the state so what does that look like in practice well consider a web browser when you use the web you go to some start URL often it's like Google and then you get links and you click on some links and then the state of your web browser changes and it's based on what link you clicked on and then the content type that you get maybe you get an image or get HTML or whatever that determines what you then see in your web browser and then there's more links and then you can go on and drive the application state that way so so in that sense the hypermedia the links and the types drive the state of the applications you see and it's actually constrained it's not like a feature or something it's a constraint on how you design software and the constraint is that the client in this in our example the web browser has no hard-coded knowledge about the structure of the URLs on the servers when you go to a particular website we go to the PayPal website your browser does not know what URLs exist on the PayPal website it has no idea it's not hard coded into the browser because that would be ridiculous and the web would not be very extensible right we would have to download a new version of browser as soon as we wanted to access a new kind of website so instead this information is sent by the browser as this state and as links and the client that the browser does not construct URLs so so that's another way to express this constraint URLs are not constructed but they are retrieved from the server that's sort of a way to think about this rule there is an exception of that there could be like a general link construction mechanism that the servers can exploit and that the client knows about and the web form for instance constructing a query string is an example everybody sort of knows when you go to Google and you type something you press enter this query string will appear behind URLs so in that case the client the web browser is constructing a URL but it's only doing this in sort of a very well-defined way it's not a new way for each website so what are the benefits of following that architectural principle well the server can be in at least partial control of what you see in the user interface and if you reconfigure the server that means the UI becomes different so you you can you don't have to change the web browser in order to have a new website you can just change your web server and when you're developing you can have a looser coupling between server and client which is sort of a general software architecture principle and and you can create user interfaces that are extensible platforms so this whole core application again with plugins or that you can figure in some way and the web browser itself is an example of such an extensible platform and then sort of the most abstract sort of ideas that it supports the long-term evolvability of applications and why feeling who sort of came up with some of these principles and there's been a vault in the web for a very long time sort of thinks about this kind of stuff and and he attributes these principles to sort of why the web has been around for relatively long time in software and is still able to keep up and evolve without breaking everything right so all the websites generally still still do something so let's talk about hypermedia API so I know how to pronounce this word rest stands for representational state transfer and the idea is that you know we have this web architecture that we know works well for for websites and we've been working with it for a very long time so the idea is to try to gain the benefit of this architecture the extensibility and the the long-term term evolution but for for API's for client server API's where you were some software in the web browser or maybe a custom client you're writing Python is the client and then the API is an HTTP server and so yeah it's HTTP for API is not for UI so an API in a way is is a user interface right I mean it's a user interface for developers that need to use it but it's still a user interface just a very particular one so so the idea and then we see this a lot on the web is this HTTP API so the client accesses data through the HTTP it goes through some URL then the server typically returns JSON or it might be XML or something else but that's kind of data format and it's good practice to use like HTTP methods like get and post and put and delete and to risk data for the server to send back proper HTTP status codes there's 244 which most people know about with all kinds of weird ones as well that you can exploit in your architecture so people are very familiar with this and and this kind of API is often called a rest API but most of these API's aren't actually rest API's if you go by the original definition of rest so because they don't have hate or us and it's a requirement for rest you cannot actually according to by the original definition of rest that was written in a paper by Roy Fielding back in I think 2000 or so it's an explicit requirement for for the way rest is supposed to work but most of the API's just have one content type or maybe very few content types some of them add content types but it's maybe all application slash JSON and most importantly if there are no hyperlinks in many of these these supposedly rest API's and I keep running it to new rest best practices documents everywhere on the web let's say this is how you should develop a rest web service arrest API and they don't even mention hyperlinks they just leave out the whole word hyperlink entirely which is astonishing if you think about the original definition of the word so people decided to just give up on this original definition has been hopelessly she shifted their meaning polluted so people say rest API mean HTTP API we just give up I give up but we'll call this this thing that's actually the real rest API will call that something else just to have a way to refer to that so that's a hypermedia API so that's a HP API that follows all these rest best practices plus hyperlinks and and content types and the idea of that is that you will then gain the full benefits of the web architecture for API's should you need to have those benefits and one sort of for the standard that's relatively recent it's a little over a year oldest called Jason LD that extends Jason because Jason is kind of a limited format this is also why it's so successful because it it doesn't do very much and it's very easy to use in languages but it's very limited that there's no notion of a content type in Jason and there's also no notion of a link in Jason you can of course put a URL in a Jason document there's no knowledge that is actually a URL could be anything so there's this standard called Jason link data and that sort of extends Jason builds on top of Jason to let you do stuff like that and it does all kinds of sort of scary stuff but the sort of the important stuff for this talk I'll mention here so here I have an example of Jason LD now Jason LD as a context will completely ignore that for this discussion Jason LD documents have an special at ID property and that is a reference to the canonical place the conical URL where you can find this resource sort of the place that you give to other people to find a particular resource so here we have a Jason LD document that describes an animal and so that ID says this is where I'm from basically this is where if you go to that URL you can find you can find this document and the other important bit is the type the ad type and that's another URL doesn't have to refer to anything could just be just a URL pointing into the void there's no particular thing that has to be there sometimes can be an HTML page that describes sort of what it is and that type is just the way so we actually can see what kind of animal or what kind of object we have here in this case we have an animal and I just came up with this this URL could be anything but the idea is that we know that if you get a document with this type then we know we have been expected and things about it and in this case we expect that it has a name and a title in the description and a list of friends right so in the context you can describe I said I wouldn't talk about context I'll talk a little bit more about it in the context you can actually describe that in this list of friends there are links there are hyperlink so the client can automatically deduce there are hyperlinks there so basically just as for the purpose of this talk an ID and a title to Jason in a standard way so yeah let's talk a bit about so that's a way to do types and I should mention of course you can do the content type header you can use that to transfer type information to the client the problem with that I mean I'm sure there's other people who think it's the best way ever but the problem I see with it is that if you have a nested object you have a Jason object that contains another Jason object then then that type information you cannot express that in a single content type so if you embed it in the file itself in the document itself you can you can express that information so yeah how do you build a hypermedia API while you use just about any web framework that you can use to build a rest in a new sense of the term API you can use any web framework but it can of course be done better there are better web frameworks to build this kind of stuff and of course I'll mention more path which is designed to make it easy and natural to make to build hypermedia APIs in particular to make links between between items so more path can make hyperlinks for you in I would I think is a better way than what most web frameworks do which is not very much you can just link to a Python object and as long as you've described for its class like where that what kind of path in URL that the instances of that class have it can make the hyperlink for you automatically and the other thing we talked about extensibility more about big takes extensibility very seriously it's a micro framework is very small but it still allows I think more ways to to construct and to compose and to inherit applications then I've seen in any other Python web framework and it's very well documented so if you want to learn more about it you can go to robot dot with the docs.org so now let's go into the sort of the more speculative part of this this talk which is hypermedia user interfaces of course we have again the web as a great example of a working hypermedia user interface that's the server produces HTML somehow and there are links in there and some forms that can help you construct links and it's been going strong since 1990 right so it's a very successful example of a hypermedia user interface it does have limitations if you want like a highly interactive application it feels more like a desktop application going back and forth to the server for even small updates in the in the web page can be very clunky even though we did do most of that I mean many web applications are still constructed that way and they work fine but it can be clunky for for a whole range of purposes so that's why we have seen in the last decade the rise of single page applications where you send a bunch of JavaScript or other something compile the JavaScript perhaps to the client which then updates the user interface dynamically on the client instead of reloading a page and the question is how do we build hypermedia user interfaces in this context we know how to do it for the classic web where you have server HTML but how does this work in in the rich clients of the application because generally they don't rich client site applications generally are backed by new style rest API which don't have hyperlinks they don't exploit hypermedia at all they often hard code the links to the to the server in the JavaScript directly of course that you can think of that as hypermedia which is just sending a JavaScript from the server as well but it's not really a hypermedia client if you change the structure of the link on the server or add a new content type of whatever the JavaScript client just will have to be updated otherwise it just won't work so so yeah why would you want to have hypermedia driven UI well we need a UI that's extensible so you have a core application platform and you want to be able to plug in things easily when you want to UI to be reconfigurable by changing stuff on the server without having to change code but just rearranging the data when you want looser coupling between client and server so not so much hard coded dependency of the client code on the server code and if you want to design a UI for the long term and that often I mean that relates a little bit to this core application with extensions idea because often sort of the business idea behind that is that you have this core application platform and you deploy it in multiple places but you know it this application platform hopefully supports the business and will be around for decades perhaps so it's a very long time so yeah rich client application describes with the basic idea so the UI code JavaScript runs in the browser they use Ajax calls to talk to the HTTP API on the server they manipulate the DOM in some way to update the state of the browser and there are tons of frameworks out there and I'm half introducing a new one now but and yeah that's sort of the state where we are now so back in 2010 this is this is the monolith above Jupiter in a movie 2010 the documentary about this was not a documentary but anyway otherwise it would be light outside now actually Jupiter is probably out anyway so 2010 back in 2010 I was building which client-side web applications for customer and I took rest seriously so of course my back ends were real rest APIs hypermedia APIs who would say now so there were links and all that stuff and types and I needed the client-side web framework this was 2010 so I had his ideas like let's create a web framework for the client side and have model view on the client and templates on the client and then it turned out you know as time went by that I wasn't the only one with that idea and then you know backbone came around and various others amber angler and all that stuff so the time was ripe for this kind of framework but I created this thing called OVL that nobody uses that's also one of those frameworks but it's a very good way to learn about the trade offs in create your own framework is a good way to learn about trade-offs in other frameworks right because you have done it already so how does OVL work so you have a you have a model object it's just some kind of JavaScript of Jason object and it has a an I face property because there was no Jason LD back then so I made up my own but this is effectively like that ad type in Jason ID LD that I described before so that identifies what kind of model I have here I have an example model here and example model has a name and then you can define a view in OVL you can say four example models this is how I'm using a template language this is how you show it on the on the web page so you render it in a PTAC with hello and then the name of the hello of the name property in there so that way you have some kind of dawn where it has an ID food in there and then you say I sent a jQuery you render the model which I defined here on the top I want to render that model in the ID food there what it will do is insert it will look up the view based on the interface based on the type will look up the view see that needs to use that template hello and then interpolate name in there and then it will insert that into the into the web page so that's sort of the basic principle of OVL and I mean as you can see sort of it supports types right that's sort of the one half of hypermedia support is here within the service aspect type OVL knows how to respond to it and show something and the other half is sort of the hyper hyperlink support so OVL supports rendering a URL like an object so instead of giving it a JavaScript object you can just give it a URL and it will load a URL from the server for you and then when it gets it it will look up the type and look up the view for its type and then render the thing there so that that's sort of the other idea there and then this way you can construct nested you can have a JSON object that points to other ones and then you can sort of render it in a nested way you can render all using the face type so let's you build hypermedia driven UIs even though that term didn't come up to me now or then now I would call it that way and the idea is that your application that you build with OVL just needs to starting URL you just give it one root URL of your your your data source and then it just follows links from there and it constructs the whole user interface that way and the server can change sort of its entire URL structure as long as the links are still the same the types of the same the application will still work and you can also reconfigure the behavior of the user and face by changing the type that you give back from a particular URL or by changing the link to point somewhere else you can change the behavior of the UI on the server quite quite well and and I use this sort of the idea that you're changing I had this particular use case during a customer project that I had to change all the URLs in the application because I needed to embed some more state information in there I didn't have before and I mean I used the predecessor of more parts it was very easy to do it on the server as well so I changed it on the server I had to change one sort of configuration file one Python file of code and the client just worked as before it didn't have any hard-coded URLs except the starting point which is also got from the server of course and then after that it just follow links so all those links were all different but the client still still work but our flaws with OVL besides that nobody ever heard of it so but it has problems as a hyper media UI framework so one of the problems of OVL is spamminess so it follows these links to construct an application so if you have a lot of linked objects to build a UI we'll need to do a lot of requests to the server and that's very spammy lots of small requests and responses back and forth and that works for smaller applications that don't need a huge amount of users but when you need to scale up a little bit that becomes a bit slower another problem is that OVL just replaces all parts of the DOM in a very coarse-grained way even if very little changed in it so it was not very efficient we got around but that by using all kind of jQuery plugins that could do updates sort of with themselves with data sources they didn't really use OVL but if you really wanted to update like one little bit that could get a little bit expensive and and the biggest problem in OVL is that there was too much knowledge about the UI needed to be in this REST backend so even though it was a hypermedia backend the hypermedia backend we need to learn about we need to know about information of the user interface it would send back Jason saying I want to display a menu here and the menu entries are you know are behind these links but then you're speaking in the language of user interface in your REST backend that it doesn't it's not really neutral anymore to what front-end you use it's really specific to that particular user interface so even it's data-driven and it is RESTful it is it is a hypermedia API it's a very specific one and the backend should really be UI agnostic if you design it well and it should have types to describe what kind of content you're dealing with more than what kind of UI concept you're dealing with right I have an animal here a human on address in some cases that really if your application is about UIs or you have this particular subsystem for constructing forms it might be entirely okay to construct UIs from from types you send back from the server that might be a perfectly fine use case but you don't want it to be sort of the everywhere in your your HSP API you only want to do this when you really need it not not all the time so I started thinking about how to resolve these issues so started thinking about a hypermedia UI framework so the idea is that creative framework like OVL that allows you to build hypermedia UIs that solves the problems of UIs and we can now we're in 2015 so we have newer technologies like flying cars and stuff like that right back to the future to flying cars everywhere pizza rehydrators I'm sure they were used for the pizzas here right so they came in this big into the office and then they put them in the machine and they become this way so so we have more modern technology now so so we can do cool stuff so we have Jason LD now and Jason LD actually I realized can help you solve this feminist problem so the idea here here we have this our pigeon again Fred the pigeon and Fred the pigeon as a friend Bob the elephant I just made it one friend in this case very lonely pigeon I guess but otherwise I won't fit on the screen so in this in this case if you have a UI that wants to display Fred the pigeon and then all the all Fred's friends who need to load the elephant from its URL so that that is an extra HTTP request one to get this one you know to Fred the pigeon that URL and then to Bob the elephant that might be okay but it might not be okay if you display a complex page this is where it falls off page you can imagine what what's at the bottom so yeah the idea here is that instead of actually putting a URL in there with Jason LD you can express this nested thing there so you see there Bob the elephant the idea is there the type is there and then information about Bob the elephant is sort of in there and then this ends so if we could send this from the server then the UI could just display ball or Fred the pigeon and Bob the friend in one go without having to do another request right so if you could send this back that would be cool so any idea how to do this is to Jason LD has this kind of interesting algorithm and there's a bunch of implementations in Python as a pi LT library there's also a JavaScript library for Jason LD and and there's a standardized flatten function which defines how you take a nested structure of like we have here of objects with the objects and turn it into a flat tree and and all the the nested objects are basically replaced by their links but you have a list so you get a flat list of the items so you get Fred the pigeon and you get Bob the elephant but you get them in a list and Fred the pigeon still points to Bob the elephant but it's just a reference for the URL but you have both of them already on the client so you can build a store and I started working on this this store that stores these flatten objects and then the server can just choose okay we're having a user interface and we see here that we have a lot of requests happening when we display this particular page of our application how do we reduce this while we can embed some more objects instead of hyperlink them we just embed the object right away and then the store is in charge of all the loading so it also hides away all the because if you would do this in straight-up JavaScript you would get perhaps kind of nested asynchronous callback hell and all that stuff in UI code so I abstract all of that stuff in the store so you just say give me Fred the pigeon and please already preload if you don't have it already preload Bob the elephant as well preload all the friends and then the store will automatically do one or more requests to the server depending on sort of what what it got whatever he has and the client code otherwise doesn't need to change so the server it gets modified it embeds extra objects reduced parameters and the idea of the store abstraction is that you can then still have the same client code and it just simply makes less requests but it still works in the same way so more path is cool because it supports this use case in more path is a one-line code change so if you want to change a link to an embedded object it's like going from request dot link for the object give me the link for that object for the elephant or whatever it is giving me the JSON representation of that object is for the second line so it's a one-line change on the server as well to make it less funny so then we have the course grained DOM updates store problem that I described and well there's a great solution for this these days is called react which is the most obvious like of web frameworks I think because it's also decomposes the UI into small components and it's really great at rendering views much better than OVL was because it uses this virtual DOM strategy to minimize DOM interactions the basic idea of react is that if you want to present some user interface you basically just pretend like you're rendering the whole web page in some kind of fake tree of JavaScript objects that represent that web page but it's not the real DOM you render it very fast and then you compare that with what you have in the real DOM and you only update the bits that have changed and that way you can really program the client like you did on the server right if you send back a whole new HTML page you just replace everything this is a way to do the same thing almost re-running the whole page but then very efficiently update the DOM so you still have that fast interactivity that you want so yeah change the whole UI and just just redraw the whole thing fast that's sort of the one of the core ideas of react consequence of that idea is that it's you don't have to make all kinds of complicated relationships like if this part of the UI is updated and this part of the UI also should be updated with react to just redraw the whole UI all the time anyway and if you draw the UI correctly the first time then when something changes the change version will also be correct so you don't have to express which many other these clients that we have for instance make you do this you have to express all these dependencies in your systems like if this thing changes and that thing also needs to change and can get very messy and complicated react you just have to worry about redraw the whole thing I don't have to think about it kind of stuff so the idea okay we this hypermedia UI framework of the future let's build it with with react to solve this problem and then we have the sort of the biggest problem the the knowledge problem that the server UI has to know about all these user interface concepts a bit OVL so OVL is this entirely server-driven view lookup system that's what makes it hypermedia you get these types back from the server and then it looks up the the views based on those types react is an entirely client-driven view system so you have these sort of hard-coded names so just JavaScript names and you use them in some kind of not quite template language called JSX that's embedded in our JavaScript but it looks very much like HTML and you can refer to these high-level concepts so here I'm using a few things from the react bootstrap library which sort of embeds all kinds of bootstrap the HTML's we can talk in these high-level UI concepts and this gets emitted as HTML in the end when the DOM is updated so and that actually is a great way to do these UI on the client where it belongs right it shouldn't be the server knows about this button toolbars and panels that should be the job of the client so you basically want one on both well here is how to create a react component so you you create this kind of class-like thing you given the name animal here and then if you want to display the animal and then Fred the pigeon or something like that you just use a little template JSX template there and then you can just use it like a tag so that's the react side of things and ending thing I propose to build on top of that is this special component called hyper render and hyper render with hyper render you can associate a react component like animal that we just defined with a type URL so you say okay if I want to render things with that type URL types animal then I use the animal react component so I store it in a registry somewhere and then when the server gives back this thing with type animal well I can just render whatever whatever I get back from the server so I just say render this particular model and we'll look up the appropriate react component for you based on the type of what you pass in and then dynamically put in whatever bit of the view you have there and that's what what makes the UI hyper media driven so the idea is to use a hybrid system to use normal react components where you're talking about the UI and use hyper render where you want to be parts of UI you want to put in slots that you want to be driven by server state you want to be so if the server sends back an animal then you want to show an animal there but if the server shows back an airplane type then you want to show the UI for the airplane type there you have a list of animals and suddenly there's an airplane in there that will just work because it will also just it will use the airplane rendering an airplane view there and it will be that will be server driven so I started working on this I call the project hyper state and the idea is to have a client type web framework that's based on react adjacent LD that allows for this kind of hyper media driven UI and has this hyper store to take care of the spamming this issue and abstract way further loading and use hyper render to do the to do the hyper media type driven story and I'm still thinking about how to do client-side routing in this kind of scenario you want still want URLs to change even if you I mean normally when you use a server-side web application the URLs changing can bookmark them press the back button all that stuff works soon as you do everything in the client that that's completely broken you need to have a system that brings that back again and there are various routing solutions that the various client-side frameworks offer but I think for for hyper state we'll need something slightly different because you know the whole architectures so I'll show a sort of a hand-waving example of what what a very simple hyper state application might look like in the future when there is actually is a code base called a hyper state that actually works so so here we have some some data we have two objects that sort of describes some characters in the Terminator 1 movie so we have the T800 cyborg there which is of type cyborg and it has a designation and then somebody wants to kill and somebody wants to protect nobody in Terminator 1 as far as I know and they have Sarah Connor who has the same URL unfortunately as the as the kill URL in the in the T100 800 so the T800 clearly wants to kill Sarah Connor and has a type human right so that's Terminator 1 and now we're going to define a few views for them using fictional hyper state API which is very similar to React it just adds this type story here so what we say for the cyborg type we want to render the cyborg and in a div with the designation of the cyborg I actually should write this dog prop star designation my apologies when you see this dog as a nation should be this same with this dog name below that's react so and then for human we want to show the human and a name of the human and then we want to have also a special detail view which has a different name than the main view for the cyborg that display places details of the cyborg in our application and we want to show the the the designation of the cyborg so we just re-render the are if we render a cyborg object with a details view we say okay well first render at the top hyper render object is this dog props I should put it in curly braces you see with fictional code it doesn't work so when you when that first hyper render happens it will look up the non details view so the first view here for the cyborg and it will show the cyborg and then the designation of the cyborg and then it will show the target of the cyborg will show the kill prop property and it will automatically resolve that URL for you if you configure right and you show the protect what the protect link points to as well here and then when we say okay please render the th h100 URL and using the details view now what it should show is well cyborg th on 800 and then the target is Sarah Connor and it protects nobody so now we have sort of reconfigured our server for Terminator 2 because in Terminator 2 that the link structure is different right we still have the same types we still have cyborgs and humans but it's different now we have John Connor as a new character besides Sarah Connor also a human and they have a t1000 and the t1000 is trying to kill John Connor protect nobody and we've reconfigured on the same URL that we had before if you configure the t800 the t800 now wants to wants to kill the t1000 and protect John Connor right so that's changed quite a bit but we can still reuse our same views right so if we now render the t800 then we'll see that the target is the cyborg not a human anymore so that's where you see it's really type-based right so it's not hard coded that the target was a human and in the previous example the target was just whatever you link to as the target as long as we can render something for it it will show the right thing so the target is a t1000 and we want to protect the human you know we want to protect somebody in the first place the human John Connor right and if you have a Terminator 6 and you know the t800 is trying to kill another t800 or whatever that would all still be possible with our with our existing views and of course we could extend if Terminator 6 happens to have kind of a new kind of character that's a zombie or whatever zombies are very popular then you know we could we could add in we could add a zombie type right and then you could start using it so that those are ways to reconfigure your server to change the behavior of the client and to extend applications so we have a state of hyper state of be thinking about this for a while and I started to write a code actually seriously this week so the store the hyper store sort of getting there to actually test and I have a prototype version of hyper render and I'm thinking very hard about a routing system now what I haven't really written any code yet but I'm quite familiar with routing systems after my soap career and then more path and all that stuff that I have some ideas so yeah in conclusion I hope you you learn a little bit about hyper media from this talk at least and that I interested you in the possibilities that hyper media UIs can can give you and if you're interested in this kind of stuff and you want to talk about it and brainstorm or whatever then please talk to me and thank you are there any questions as well so the idea is that yes so so so the idea is that you and I didn't show this here that you can you can say so you get you start with one URL right that's type of media idea so you start with one URL that's a root of all your data that might point to other sort of parts of your application and then you look at its type you look up a view for it and then sort of it nests that way through to build user interface but what you can express is so so in and if you implemented it naively there would be a lot of requests to load up a whole page and yeah when it gets a URL in there it will need to go to the store and say please give me this URL if the store doesn't already have something for that URL will have to go fetch it and you'll have to wait until that part of the user interface updates but because we have this store we can solve that speminence problem by saying okay we have an initial page maybe we'll have to request some of I mean maybe it's more than one request but that's very simple K initial page if it was give everything nested already or just a list of additional objects that you know the initial page needs due to that flattening algorithm it can store all of them preload them into the store already so as soon as it tries to access those additional URLs it looks at the store and say hey I already have that so I'm just giving you back that instead of having to go off again and that way you can transparently reduce the spammingness of the user interface so that's the basic idea and you can express per type which thinks so when you have a type since it gets flattened all the nested objects are gone again but you can express per type how you which ones you want to reconstitute basically or maybe per view I'm not sure yeah per read yeah per view I think so you register per view that I want all the friends to be loaded as well automatically and actually be in there as soon as I start wearing the view but yes as long as the server is just gives you optimistically gives you extra information that it just knows you need anyway the client doesn't have to be waiting for anything yeah yeah I mean there's this whole discussion in the JavaScript world about isomorphic things where you're already pre-wender the UI in HTML on the on the server for initial loads that's important for like really Google scale applications for the applications that that you see well beneath the I price work I think that's a concern that's a little bit over you know it's given a lot of importance but for many applications that's not really that important so that's simplified and when or anything on the side yeah yeah I'm rather yeah the audience there are these approaches to do I mean there's even htb2 right I mean there are these sort of new protocols and various sort of things proposed and already existing they'll let you preload static assets basically so that that's similar but but not the same because these are much more dynamic assets that you're getting anything else I was that clear or unclear so you mentioned like the view and object which can be like simple and then I can tell you but often we have to deal with stores which deal with the collection of objects so some like they say give me a list of addresses right but because again you don't want to actually don't want to pull all the data out right you have like pagination issues like a filtering sorting this kind of stuff are like standard operations on the list of objects which are also views in themselves so my thinking in that sort of when you're talking about so so one one way to do deal with large amounts of data on the server is to deal with is to do pagination and pagination is just a next and a previous link and then you know you can I don't think that that is a big issue for the store and yet but the other sort of aspect is is queries right where you have a query with some dynamic information and you want to construct the query that's where you sort of you get into territory of the client constructing URLs and there is this this RFC that lets you that's called the URI template RFC that sort of helped so the idea is that the server would send the URI template template of a query to the client and then the client can then inspect that and use that to dynamically generate queries very much like HTML form works but maybe that's not exactly your question I don't think it's a big issue if you just give back you know you don't want to give back all data all the time right you don't need all data on the client you just give back the data that that actually needed uh-huh right right right right so so the idea is that yeah yeah you connect that so you hook it all up to the type right so the view needs to know about this stuff but the view can rely on so as long as you your view knows that it works for certain type it can assume all kinds of things about these objects there are like standards in the works like Hydra which is built on top of Jason LD to try to and there's a whole bunch of other proposals that try to really abstractly specify REST APIs type media APIs with collections and all that kind of stuff there's a lot of different stuff going on there but you don't need it I mean it would be useful to have this kind of stuff but you don't need it to construct a hypermedia UI because you can rely on as long as you know the object description type you can make all kinds of assumptions on what's in the object after that you don't need to I mean it's nice to be able to introspect information and all that stuff about particular types and then know what's there but it's not necessary to do that you could hard-code that you're still hard-coding a lot less than when you're hard-coding both the information about the types you expect from the server which you do in a traditional HTTP API as well and the URL structure of the server you will hard-code that in the in the client if you do it sort of the non-hypermedia way in this case you'd still hard-code information about types where you don't hard-code information anymore about URLs so you're still more loosely coupled mysterious acronym to be pronounced heinous heinous hate us yes well I didn't come up with the acronym it's somebody else so we invented that one I maybe there is a established way to pronounce it but I didn't know why I deliberately didn't look it up anymore because you know I just thought it would be funnier if I didn't know I do have a bonus slide if there are no more questions so it are questions very good OVL stood for object view elements so the idea is to associate objects with views and elements you have to come up with some name right so so that's why I think hyperstate sounds cooler but it's you know I just came up with it so that this sounds better anyway yeah hyperstate oh yeah yeah sounds like an elf from from Lord of the Rings you back there hate hate the us okay hate but doesn't hate aeos but it's an O there anyway yeah okay well that's not the the singlish pronunciation of that word right aha hate this okay all right fine it was another hand somewhere no there yeah so I could you code duplication between server and that instead of right so so the idea is to do everything on the client side there's anything to do with you why it's right so there's no HTML generated on the server at all so that's one way to avoid the code duplication yeah it would be when you want to build an interactive sort of more desktop application like thing then then a traditional website and there are very good use cases to make a website with multiple where the server generates html and where you enhance it with a little bit of JavaScript I mean there are great reasons to do this so this is more oriented towards building these interactive modern web applications with still getting some of the benefits of the web that we've sort of lost along the way right we're getting them back again the hypermedia benefit I need to log in again if I want to show my bonus slide right so I'll go to the special bonus slide now so last year somebody here asked me about more path performance you know it's the question everybody always asks about web frameworks and then we have this extremely insightful and accurate hello world test that really tells you nothing right it's a benchmark so so last year when I measured it I just started measuring it and it was as fast as flask which was the it's about six thousand requests per second on doing hello world so flask is actually people tend to be surprised about it but flask is one of the slower web frameworks out there people think flask is pretty lightweight and easy so it's pretty fast too but it's not it's actually one of the slower one out there jango is faster than flask so half a year ago when I done some optimization work it was faster than jango at about 9800 requests per second and I did some more refactoring and now it's at fourteen thousand five hundred requests per second I measured it today priority I mean of mobile does not performance I think the performance I mean since nobody complains about flask performance for the more path is more than fast enough where you see a lot of sort of noise about performance of web frameworks you really want a high performing web framework that's boring and doesn't do anything nice for you that's just like all the other ones you need to go elsewhere and they're much faster than more path at the low world but if you want the extensibility and the linking and all that stuff you know that's why you should go to more path not for performance but since we had this question here last year and that put me on the old performance trail I thought I'd get back to that okay thank you