We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Farwest Demo

00:00

Formal Metadata

Title
Farwest Demo
Subtitle
A website/API for a document oriented database in 20 minutes
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Farwest is an Erlang framework for building RESTful Web applications and APIs. Well written Farwest applications apply the HATEOAS principles and as a result can be interacted with using a single client. This removes entirely the need to write a separate client per API and lets servers decide how the data is best consumed by everyone. This demo will show how to use Farwest to write a simple API to a document oriented database.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
DatabaseLogicDemo (music)DemosceneEmulationRight angleCoefficient of determinationRule of inferenceData storage deviceProjective planeCellular automatonGoodness of fitLecture/Conference
Demo (music)DemosceneSoftware frameworkErlang distributionStandard deviationModul <Datentyp>Template (C++)HypermediaType theoryForm (programming)Operations researchBlock (periodic table)BuildingClient (computing)Computing platformFormal languageLibrary (computing)EmailLink (knot theory)Router (computing)Skeleton (computer programming)Dependent and independent variablesReverse engineeringClient (computing)HypermediaLink (knot theory)Projective planeDependent and independent variablesEmailDifferent (Kate Ryan album)ParsingType theoryErlang distributionFlow separationFunctional (mathematics)Router (computing)FacebookFormal languageDirection (geometry)Standard deviationOperator (mathematics)Finite-state machineRepresentational state transferModule (mathematics)Library (computing)Block (periodic table)BuildingFile formatSoftware frameworkCodeTemplate (C++)Server (computing)State of matterProduct (business)Computing platformRule of inferenceProcess (computing)Power (physics)Electronic signaturePrincipal idealOptical disc driveArchaeological field surveyOrder (biology)MereologyTwitterMultiplication signBit rateDisk read-and-write headMathematicsComputer animation
Bit rateDependent and independent variablesForm (programming)Skeleton (computer programming)Erlang distributionBinary fileFunction (mathematics)HypermediaoutputMilitary operationTemplate (C++)Link (knot theory)Magneto-optical driveOperations researchComputer configurationSemantics (computer science)CloningDemosceneType theoryProcess (computing)Table (information)Server (computing)Representation (politics)State observerInformationTerm (mathematics)Convex hullOptical disc driveCondition numberFunctional (mathematics)Link (knot theory)Presentation of a groupPoint (geometry)WeightEmailInformationRevision controlWeb 2.0Binary codeSource codeForm (programming)RootStreaming mediaElectric generatorType theorySemantics (computer science)Information retrievalKey (cryptography)VarianceTablet computerProcess (computing)State of matterPower (physics)WebsiteState observerBinary fileCASE <Informatik>Bit rateData managementComputer clusterAreaRing (mathematics)Set (mathematics)Row (database)Group actionDefault (computer science)Operator (mathematics)Representation (politics)Function (mathematics)Web browserHypermediaTerm (mathematics)Template (C++)Line (geometry)Associative propertyOcean currentField (computer science)Demo (music)AutomationEmbedded systemString (computer science)Module (mathematics)File formatMedical imagingDifferent (Kate Ryan album)Computer animation
Link (knot theory)Server (computing)Template (C++)DemosceneEmulationEmailLink (knot theory)Descriptive statisticsServer (computing)Point (geometry)Time zoneGreatest elementDigitizingCountingScripting languageArmTable (information)InformationOrder (biology)Term (mathematics)Bit rateSubsetTemplate (C++)TupleFlow separation
Type theoryHypermediaOperations researchFunction (mathematics)Term (mathematics)DemosceneDescriptive statisticsCASE <Informatik>Term (mathematics)Functional (mathematics)EmailTable (information)String (computer science)Template (C++)Finite differenceComputer animation
Binary fileTupleObject (grammar)String (computer science)ParsingElectronic mailing listUnicodeDemosceneControl flowCache (computing)Operations researchFinitary relationLink (knot theory)WebsiteDependent and independent variablesTemplate (C++)Data typeReading (process)Numbering schemeForm (programming)Semantics (computer science)Client (computing)Erlang distributionFunction (mathematics)Demo (music)Template (C++)Dependent and independent variablesMereologyData storage deviceFunctional (mathematics)EmailField (computer science)Electric generatorTerm (mathematics)Service (economics)File formatForm (programming)Semantics (computer science)Client (computing)OctahedronOperator (mathematics)Multiplication signComputer animation
Demo (music)Client (computing)Electronic mailing listWeb pageInformationInteractive televisionRight anglePhase transitionTable (information)Group actionNumbering schemeMereology2 (number)Game theoryLecture/Conference
FacebookPoint cloudOpen source
Transcript: English(auto-generated)
It's a pleasure to be organizing this Dev Room. It's the first year of an Elixir deadline for our friends, the Dev Room. 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 surely be talking about the Beam and some very geeky stuff. Our first speaker is Loic, butchering the name right off the bat. He's the creator of cowboy, which probably 99.9% of us have used.
He's going to talk about his new project, Far West. Loic, take the stage. Thank you. You may have heard of 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.
Far West is a framework that applies the H2AS 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 on 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 Erlang code that you will find.
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 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, I only target Erlang and 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 would not need to have a separate client for GitHub and a separate client for Facebook. And so 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 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. 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 barebone 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 a URI template. So I will show some examples. You also define what operations are available.
So usually, you will have 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 an image PNG.
And links. So you can define links between the documents. And the operations, as I mentioned, are configurable, 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 entry point, just search. 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 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 big three lines header, with two links we defined, one, two processes, and one, two tables. And for each link, you can see the variance,
which gives us what media types are provided by this resource. And so currently variance, it's not a standard, it's a draft.
So that's why it's variance-06. And for the resource itself, you have also variance, which tells you it can give you HTML or bed, and currently, variance 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 observer, the 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 toRepresentation. And here you can see the HTML embed. 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 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 currently.
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, oh 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 tuple Far 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 fill the URI template 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, it's this, a long term written as a string.
And delete doesn't take anything. And so this gives us this. You can edit it, add a zero, and it will update the data automatically. And it does so by calling this function, put. So 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.
Okay. And so there's a lot of work left, especially around discovery, because it's a 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 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 a big second part, which is semantics. So the first part, we will 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 yeah, 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, yeah, generate, like, expand your 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 adopters. And yeah, thank you.
Any questions? It's for cowboy. What? Thank you for cowboy. Yeah. Thank you for cowboy. No problem. The schema and stuff like this, will you also transfer automatically if the schema is wrong, something like that?
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. 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.
With 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.
So we don't need necessarily to follow the link, because maybe the data we want is inside this document.
So this is what it's about. It's like for modelling data, like finding a principle to the finding data? Yeah, the first phase is finding the data, and the second phase is modelling, accessing, manipulating it.
For now, I want to get everything else right before, because that's a very big subject. Any other questions? Okay, thank you.