Recommended
More Related Content
Similar to Language & APIs: Building the Robot Apocalypse
Similar to Language & APIs: Building the Robot Apocalypse (20)
Recently uploaded
Recently uploaded (20)
Language & APIs: Building the Robot Apocalypse
- 1. Language and APIs: Building the robot apocalypse
- 8. Rorohiko
- 12. Television Greek: tele (far) + Latin: visio (thing seen)
- 13. Our skin helps us describe people…
- 15. … he needs to be handled with care…
- 16. He’s just not thick-skinned enough to take criticism…
- 17. … when you speak to him, don’t mention the thing, we don’t want to rub him the wrong way
- 18. I’ve got a feeling about how we can approach George about this…
- 19. What about our eyes?
- 20. Alice “saw” a great solution to this problem,
- 21. Great ideas are considered “brilliant”, invented by really “bright” people
- 22. I think that Alice is really clear- headed, how else would she come up with that?
- 23. Even our mind has geospatial properties!
- 24. When I came up with this presentation, I tried to put the thought of brains out of my mind
- 25. … minds are quick, or slow…
- 26. But some people’s minds think deep, and are open minded, unlike those narrow minded folks…
- 28. Whilst part of what we perceive comes through our senses from the objects around us, another part (and it may be the larger part) always comes out of our own head. - William James, 1890
- 32. Your average API is pretty boring…
- 33. Your average API is pretty boring… HTTP METHOD RESOURCE
- 34. Your average API is pretty boring… or is it?
- 35. Do we really post data to a resource? If I modify the data, do I really patch it?
- 37. A modern API is a bit smarter…
- 38. A modern API is a bit smarter… HTTP METHOD RESOURCE Self- Describing Code gen (Semantics)
- 39. Wait a sec… HTTP METHOD RESOURCE Self- Describing Code gen (Semantics)
- 40. A future API could be much more than just a set of calls…
- 42. HATEOAS RDF/OWL Deep Learning FaaS Defined verbs Defined entities On-client cache
- 43. HATEOAS RDF/OWL Deep Learning FaaS Defined verbs Defined entities On-client cache
- 44. HATEOAS RDF/OWL Deep Learning FaaS Call relationships Call batching Compound verb substitution
- 46. The API Economy becomes the Function Economy
- 48. There is still the problem of code…
- 49. RPC over hTTP REST over HTTP RPC over HTTP/2
- 50. ...
Editor's Notes
- Intro: Who am I What is this? How we are, in our own way, paving the way for the robot apocalypse. Caveat emptor: This talk is meant to be entertaining, so please take all of what follows with a large pinch of salt… This picture was sent to me by cofounder, it’s rather perfect for this talk…
- Who here has heard of Julian Jaynes?
- What about this? Who’s seen (or read) westworld? Well, for those that don’t know - Crichton used Jaynes’ theory to explain the bootstrapping of AI consciousness
- Back to Jaynes… Who was he? A psychohistorian Really fun ideas about how consciousness works In particular, he had A great understanding of how language develops…
- He wrote this extremely verbosely titled tome. Before you say it – it’s actually a fantastic read, he has a lovely way of explaining concepts, if you enjoy reading anything by Carl Sagan, you’ll like this. Cost about a dollar from Amazon US, can’t get it in the UK strangely enough. To boil it down to a few lines Proposed that human consciousness, boils down to how language interacts with both hemispheres of our brains, more importantly, that the brain literally, over centuries, bootstrapped it's way into becoming conscious that before that point in time (the breakdown), humanity had a very different conscious existence.
- But that’s not what I want to talk about here – I want to talk about language – Jaynes had a great idea about a linguist trick we all use – the metaphor. What is a metaphor? More importantly, Jaynes believed that the metaphor is the constituent ground for all language We use metaphor all the time, and those metaphors have *become* language, they become independent words for concepts. We literally use metaphors to build up vocabulary and meaning in terms of other - well known – things In the lab, both adults and children will use strained metaphor to describe nonsense objects to those who can't see them It’s a unique quirk of how we work with language that helps us generate *more* language Maybe some examples to illustrate…
- I live in New Zealand, where Maori is an official language This is the word for… anyone?
- That’s right – computer… but it’s actually a metaphor. Well, it’s a compound word that has become a noun. Translated literally it becomes…
- Electric brain… This is a simple example, and might seem a bit too obvious, but most words we use today are compounds of other things that are like things
- Ink, such a simple thing, but when the context of the origin of the thing is external, like with the Maori, a closer, simpler literal image becomes the idiomatic meaning for another thing. English does it too, but in English the metaphor is pulled from older languages…
- In linguistics this is called a “Borrowing”, from a lending language to a host language But we do this intentionally all the time And that’s how language is made… and it gets really weird when you try to be conscious of it…
- The idea that your mind has physical dimensions is ridiculous, but when we discuss concepts with one another about things we cannot be conscious of or perceive, we use abstract metaphor to convey meaning in a reference space that another can understand. What’s important is that we cannot actually, ever truly describe these things except with the accurate language of physics. But where is the beauty in that?
- Think about the statement: "snow blankets the ground". The metaphor is "blanket", but it conveys an enormous amount of meaning, not just the physical qualities of the snow: it's thickness, weight and pervasiveness like a real blanket, but also the intangible qualities of a blanket become associated with the image of the metaphor, the associated concepts of warmth, comfort, serenity all become imbued in the image of the snow Through a series of associations, these ideas trickle back to you from a single word: "blankets". That's poetry right there... crap poetry, but nonetheless the essence of something. What I'm trying to get at here is that metaphor is really powerful, and at it's core, it naturally compresses and generates *more* language. A metaphor links back to more metaphor, that eventually links back to something that is essentially and innately "you".
- As a side note, I think William James had a good point: You might know a more popular one “Perception is reality” which gets misquoted a lot. But William James had this amazing romantic concept of perception: that what we perceive is always tinged at the edges by the emotions and memories of our past, so “rose tinted glasses” are essentially the norm when it comes to our interaction with reality. The way we perceive reality – which is in part through spoken and written language, is permanently tinged with personal, structured semantic data.
- Ok, so we haven’t really been talking about APIs have we? Well let’s change that. I wanted to prelude with the concept of compressive language, because it’s pertinent to how we use tools, and how a hierarchy of tools makes complexity possible For example…
- I want to open a coconut I can smash it with my hands against a rock I can use a smaller rock to smash the rock into the coconut I can sharpen the rock to do it with less force I now have sharp rocks, I can use these to open other things With my sharp rock, which I have modified, I can now open many coconuts easily I now have the inside of a coconut and the hard shell I can use the shell to hold water I now have cutting tools and vessels If the shell can hold water, can I use a closed coconut to hold water by draining it? I now have a portable water supply I can now innovate with cutting tools and vessels – for example, I can now travel greater distances for food Or I could write assembly language…
- We as developers take advantage of this every day We work in high-level languages, on the basis that a lower-level tool provided us with the capability My favourite example: Using the Go compiler to compile a new version of Go, when it used to be compiled by a C++ compiler With language, we increase complexity and diversity through the compression of concepts to metaphor, with tools we use a previous tool to make new tools that allow us to innovate, and more importantly, solve more complex problems. And when we talk about APIs, we are talking about language…. The language of machines.
- Whether it’s an RPC call, a RESTful call or via gRPC, it’s pretty much always a request/response Yes, there are streaming Apis and other fancy stuff now, but I would argue a large percentage of Apis are just that.
- The behaviour of the client is completely fixed in a specific pattern. (Which admittedly, is what we want!) But…
- There is something cute (and it’s pretty obvious): Specifically for RESTFul APIs (and maybe this is why they are so popular and easy for people to comprehend) use a subset of language. We use methods (verbs) to send payloads to resources (nouns)
- And the verbs we use are metaphors of what they actually do! I mean, there’s no way they *couldn’t* be, unless we used something like malbolge or some other esoteric language…
- (That’s hello world in Malbolge, btw)
- But that aside… regular APIs are pretty dull. Modern APIs that care use Hypermedia as the Engine of Application State Audience question: Who has actually ever implemented an API that makes use of HATEOAS principles? If not many: How many people here know what HATEOAS is? Quick intro if nobody knows…
- It’s pretty cool as it enforces certain traits that can make the API self-descriptive But then we also have Open API Spec (Swagger) And based on that, we can have client code generators and SDKs (whether you support that or not)
- Semantics is not something we’ve seen much of, but it’s been around since the WWW consortium was founded I’m talking about the concept of the semantic web, RDFa, OWL and the global data graph that can help describe the data about an infinite network of entities We mentioned HATEOAS earlier… This is where HATEOAS really shines, because it insists on using Hypermedia as the payload layer, it can embed RDF data into it’s payloads, so they become self descriptive Unfortunately we don’t see this often… and it *is* elegant. And the two things: the semantic web (and it’s tools) plus HATEOAS are a great match but as we move from web to more diverse clients, we need to be able to make those clients smarter...
- Future APIs (and their clients) could be a whole lot smarter So smart in fact, that they might not even be Api clients anymore, but generic service clients. This is where you can start putting on your tinfoil hats by the way, because it’s going to get imaginative. Let’s start with some existing tech, and build up a (hypothetical) smart client…
- Lets start with HATEOAS principles, because they provide a ready-made transport for a smart client Here we have hypermedia-enabled payloads and a self-describing / discoverable API interface for the client to use
- As part of the discoverable hypermedia links and actions, we add semantic information that can provide more information about the nature of the data in the payload And more importantly, the nature of the actions that are attached to the discoverability interface Basically my payload describes itself in terms of the data being presented and the actions that can be take with this object One key innovation here, we’re introducing an on-client cache for this RDF data
- So we have a very verbose hypermedia API, and this API can describe itself in terms of it’s nouns and verbs What we are missing, and this is where we want to get to, is the compressive nature of metaphors So we need something that will help us find patterns We don’t need imaginative leaps, we need compression, in other words: correlations, the kinds of linkages that deep learning models are good at
- So our deep learning layer begins analysing call relationship on the fly: client usage patterns It finds those relationships, and generates batch relationships between calls There’s a key step missing here: experimentation: since we can’t have the client fail for real users But what if it had sample data to work from? It’s a correlation to achieve an outcome – so a genetic algorithm could experiment with a correlated compound payload set until it arrived at the most efficient data and field transformation? When we identify a compound call batch, we can compress those actions into a compound verb and feed them back to the on-client verb graph. The client has effectively compressed an abstract, new (to it) set of actions into a single verb, the verb is a metaphor for a learning model (strictly speaking we do not need the verb, that’s for us humans because we need labels), for the client, a set of inputs trigger the option to use the new verb instead of waiting for the client to continue executing the next set of actions This is, in API terms, a metaphor: the client has compressed a complex set of actions to a familiar input pattern, it can now use this input pattern (or the output of that pattern) as a short-cut into the next set of patterns So, this is all very high-level, sci-fi stuff, but the above is essentially all a good deep learning model should do: Take a large set of inputs Compare them with a large set of outputs Feed those outputs back into the model to generate intermediary inputs and repeat The deeper the model, the more abstract the inferences get All we are doing here is adding a functional element to it. But this is where we start getting into the scary bit: capability.
- Functions as a Service: a pretty cool concept. No applications, just nano-sized services that do very specific things. We usually see this model as an application development model: build your applications, or parts of it, as a FaaS. But lets turn that inside out…
- The API Economy, a nebulous term, boils down to creating innovation and new services off the back of capabilities offered by others as metered services. Value begets value as innovation moves up the chain to create ever more complex applications that rely on a network of APIs to create new things That’s really cool. But it’s old hat When we move to microservices, and especially Functions as a Service, we stop seeing the group of capabilities offered by an API (e.g. the Soundcloud API, the Facebook API or the NYSE API) as the valuable offering, but the processing cost of an individual function, for example, base64 encoding a string, or calculating an addition operation, or looking up data in a database Imagine a marketplace of functions, capabilities to do all sorts of things, from the very simple, such as comparing two objects), to the complex (move a servo motor). Now mark up that marketplace with a semantic graph, so capabilities can be codified and traversed by a hypermedia enabled client.
- Our smart Hypermedia client can now not only use precursor data to generate metaphors for client behaviour But the very calls it makes are based on a semantic web of functions, of verbs. What can I do when I have an almost unlimited, well defined set of functionality at my fingertips and the capacity to compress chains of actions into shorter ones? You get a *very smart* API client. In fact, your API client no longer needs to be coded to work in a pre-defined way, it can be entirely coded to use the semantic functional web to build it’s initial capability, and then self-optimise towards a goal. However now that it can compress and re-codify the very definitions it uses, even it’s verbs the actual precursor actions to any newly created metaphor can be compressed. Ideally through experimentation across the functional graph – but that would need to be a different process.
- All of these capabilities still imply that the client can *call* the methods that are provided by our Semantic FaaS cloud And that it can hook those calls up in a meaningful way… But we’ve already solved that haven’t we?
- Microservice architectures are increasingly being built with protocols such as Thrift and Protocol buffers, more specifically, we’ve seen gRPC dominate We’re almost kind of back to the days of SOAP! Anyway, the important thing about something like gRPC, is that clients can be generated on-the fly, much like you could with an OAS document, but because we are in strongly-typed territory, these clients are more suited to machine use than human use. Even with gRPC, you still need to code up the use for the client, but if you have a standardised interface (or interfaces), or even a semantically defined interface style, then you can create loaders that can import functionality on the fly. And what if that functionality were really simple, like an if statement, or a loop? Example: gRPC Proxy for Tyk Ultimately, code generation, in a cloud of functions, especially if those functions are so low-level to be turing complete, with semantic linkages across them, mean a long chain of lolgic can eventually be compressed down to a metaphor, and that then add to the complexity graph of the system, making the system more capable of complex action
- So what has all this been about? We talked about how language compresses and begets more language We talked about how an API client can use this feature of language to optimise itself, and essentially, to extend it’s capability We talked about how the Function Economy and Semantic web could enable a “generic” client, that seeks out capability and builds on it based on semantics And we talked about how that client can use existing technology to implement and import FaaS provided function clients to bootstrap more functionality And all of this ties together existing technologies, that exist now…
- The APIs we’re building now, and the way we’re building them, are all inadvertently geared towards making our systems smarter APIs are a form of language, currently – they are a subset of one we understand But as APIs grow in complexity, and require lower latencies, they move towards formats that are designed for machines As those languages become modifiable by our services, and become compressed into functional (cognitive) short-cuts, so does the capability of the system We are building the languages of robots. And some day, those robots might write poetry, that only they can understand with the metaphors they’ve made.
- And that’s it – thanks for listening! Please do follow us on twitter, visit our site, come find me by our stand