 It's a pleasure to be organizing this dev room. It's the first year of Nilek Sirjadlan, our friend's dev room. Our first speaker, yeah, before announcing the speaker, we'll be having an after-party at BrewDog at 9 p.m. So if you want to join us, you're welcome. We'll be shortly be talking about the beam and some very geeky stuff. So our first speaker is Luwak, by butchering the name right off the bat. So he's the creator of Cowboy, which probably 99.9% of us have used, and he's going to talk about his new project, Far West, so Luwak, take the stage. Thank you. So you may have heard of a Far West project that I started a few years ago that went with one project in production and then was completely shelved. So this Far West project is what happened after I sought for a few years and finished and decided starting with experimentation. So Far West is a framework that applies the HATES principles. So basically what this means is that the server will send everything the client needs to perform any operations it needs. So the client doesn't have any knowledge of the server except a few things that we will see. Everything is based around standards as much as possible. So for REST APIs and frameworks, there's always some holes in the standards that you have to fill yourself. It's a little difficult at times, but it's getting better. And it's built on top of Cowboy. So what it means is that there's the Cowboy server, then Cowboy REST, which is an HTTP state machine, and then Far West on top that drives this state machine directly. So there are a few building blocks. So you have the resource modules, so that's the Arlong code that you will write. You have URI and URI templates. So that's how you know which resource you want to access. You have media types, of course, and you have operations. So in HTTP, you have methods like get, put, post. But then you have this post method, which does many things at once. It can do pretty much everything you want. So in Far West, there's a small concept of operations on top of methods that allow us to define, for example, append, replace, things like this. And then you have a metadata, for example, for caching resources, for providing signatures, and so on. Far West is not only a server, but also client libraries. So currently, it's only target Arlong and so all the BIM languages. But in time, I want to have one client per language or platform, depending on what's the most appropriate. And this one client should be the only one you need to access any API written using Far West. So you don't need to have, for example, if GitHub and Facebook were both using Far West, you wouldn't need to have a separate client for GitHub and a separate client for Facebook. And so this is not, I'm not writing a separate HTTP client, I'm writing just helper functions that you can use with existing clients. So it should be usable with the client you already are using. So far, I've mostly been working on putting links everywhere, basically. So there's an HTTP header that is called the link, which is standard. And it's basically the counterpart of the HTML link element. And then you have also links in the response bodies. So the links in the headers would be links between the resource you access and directly related documents. And in the response bodies, you can have a more fine grained links. I'm using URI templates. So that means I had to write a new router. Cowboy has its own router, but it's not using a standard format. So I wrote parser for URI templates, and then a router based on this. I'm thinking of moving Cowboy to this router in a future release as well. Variants, that's, there's a problem when you access a resource. Which is that you don't know what media types the resource will serve. So variants will tell you the different media types you have, the different languages, and so on. And yeah, I started with a very bourbon client library for now. And then for convenience, I wrote some HTML generation. So by default, well, with very little code, you can have an HTML version of your API. So you could test it with a browser like a normal website. It has skeleton forms. That means that if I have a document and I want to edit it, I have to edit the document as a whole. There's no one field per value currently. And I also have a binary format that is much easier to process by automated clients. And currently it's based on a long binary format. So when you write a resource module, you will start by giving a URI or URI template. So I will show some examples. You also define what operations are available. So usually you will have your GET, maybe PUT, maybe DELETE. You also want to associate different media types to your operations. So for example, GET will output text HTML and PUT will accept maybe image PNG. And links, so you can define links between the documents. And the operations, as I mentioned, are configurables, even though I did not do much in this area yet. So you can basically configure the HTTP method at this point. But in the future, all the semantics will be configurable. So you would be able to create as many operations as you need. So there's a demo available online. It doesn't show very well, but that's OK. So this is how you would describe your resource module. So URI can be a normal URI or a template. So in this case, it's an entrepreneur, just such. You define media types, but here you only define aliases. So it's simply easier to refer to HTML instead of the string. And then you define your operations. So this resource only does GET. And it outputs HTML and the binary along format. And then you have links. When you link with Far West, you never need to give the URI. You simply give the resource module you are linking to. And the Far West will get all the information it needs. So here we link to two child resources. And this gives us this when you look at the headers. So you have the link header, the bigger three-lines header with two links we defined, one to processes and one to tables. And for each link, you can see the variants, which gives us what media types are provided by this resource. And so currently, variants, it's not a standard. It's a draft. So that's why it's a variance-06. And for the resource itself, you have also variants which can give you HTML or bed. And currently, variants key, you receive HTML. And so then you would implement the GET function that retrieves data you will convert into a representation. And so this demo, it's basically a long observer tool, a web version of it. So we get the information and we return it. We don't do any formatting at this point. Then Far West will keep this data. And when it needs to convert it to a representation, it will call the function to representation. And here you can see the HTML and bed. So these are the media types you will need to convert this data to. And currently, so there's an automated HTML generation. So that's a Far West HTML from term here. And this gives something like this. So it's not very pretty currently. But you have all the information that you also have in observer. And all this HTML is generated. And at the top, you have the toolings that we saw before. So it gives a small navigation. It's enough for an IPA anyway. But it's not exactly the best user experience, apparently. And then similarly on a different resource, so if we follow the tables link, we also have the link header at the bottom with the link to the parent, the first resource we saw. And then separate header Far West link templates. And here I give the templates to the children of this resource. And this resource, it's a table of ETS tables. And so the template refers to all the links that you have on the left here to access all the ETS tables. And I had to do a separate header because the link header does not accept link templates. Otherwise, it works more or less the same. And if we continue, yeah, first. So these links in the body are created automatically in the long term that we give to Far West. We use a special table for West link. And here, again, we never link to a URI. We tell Far West to create a link to our resource. And we give some information to field URI templates, values. And so this is the table ROM server. And here you can see at the bottom there's already a button. It's cut off, but delete. And we have all the values in the table. And the description looks like this in this case. When you click on one of the values, you will reach a resource that is described like this. The URI template at the top with the table name and the key. So that's the value that you want to access. And you have different operations. So you have get, which outputs HTML in this example, and put, which takes a term. And the term is this, a long term written as a string. And delete doesn't take anything. And so this gives us this. You can edit it at a 0, and it will update the data automatically. And it does so by calling this function. But for each operation, you will implement one function. And this function takes the request body, converts it, and stores it in ETS. And similarly for delete, we take what we want to delete, and we call ETS delete. OK. And so there's a lot of work left, especially around discovery, because it's the big first part that I want to get right. There's a lot of questions. You have some of them here. Of course, the most important is getting cash caching, because otherwise you won't get good performance from the API. For generating response bodies, I want to provide the ability to use templates instead of generating everything. And so we would be able to replace only some specific templates. And of course, adding more formats automatically generated. And then there's the big second part, which is semantics. So the first part, we would know what resources are and how to access them. And the second part, we want to know exactly what values in our data we want to use. For example, if I have a person, I want to know their name, their email. I need to be able to do so without knowledge of the service. So that will be the big second part. And so probably using schemas, but there's a lot of research to be done there. And once we have this, we can generate forms with many fields instead of having the bigger long term. And also expand the URI templates. Clients, improving the client, nothing much to say. And that's it. So if you want to try it, you are welcome to send me a lot of emails. I'm looking for doctors. And yeah, thank you. Any questions? It's for cowboy. What? Thank you for cowboy. Yeah. Thank you for cowboy. No problem. So it would have, yeah, it's about schemas. So the schema would have to be transferred in some way, provided by the API, at least. But the client probably needs to know at least some things about the schema. For example, if you write a client to manage users, all the interaction doesn't need any beforehand knowledge, but you need to know what you are doing with the data. Any other question? You mentioned briefly schemas. What is your, can you comment more on that? Yeah, so can I comment more about schemas? So the idea is that currently I serve data, and you don't know what is inside the data without manually looking at it. Schemas, you would be able to map the data and retrieve the information you want. For example, if you have the page with the list of ETS tables, with schemas, we would be able to say inside the document, this is an ETS table. And so we don't need necessarily to follow this link, because maybe the data we want is inside this document. So this is what it's about. It's like for modeling data, like finding a principle to the finding data, and it's like a principle. Yeah, it's, first phase is finding the data, and second phase, modeling, accessing, manipulating it. And yeah, it's, for now I leave it, I want to get everything else right before, because that's a very big subject. Any other question? OK, thank you. Thank you. Thank you. Thank you.