 Our next speaker is John Blakely, he comes from Brighton. Another work camp that you should probably visit, it's a really nice one. Very good. Yeah, where it works as a senior technical architect at Pragmatic, which is a leading agency here in the UK based in Brighton. He discovered WordPress back in 2006 and never looked back. And he also worked in the film industry as a sculptor. I want to know more about that. That sounds really interesting. We should talk about this for blockbuster movies that you probably have seen. And today's going to talk about use cases for the REST API. Please give a warm welcome to Sean. Thank you. Thank you. Good morning. So I'm going to talk about when to use the REST API. So as Francesca said, my name's Sean Blakely. I'm from Pragmatic, a Brighton based UK WordPress agency. I've recently been involved with large enterprise level scrum projects. And I've been working with WordPress for about 12 years now. So who's this talk aimed at? Well, I'd like to talk about some use cases for the REST APIs and some of the cases in which we've used and found value in the REST API. I'd also like to talk about why I think the REST API is important. I'd then like to talk about an overview of what an API is. So a very brief flyover of what APIs are. And then start digging into when to use the API and use some examples of when we've used the API. And then very briefly we'll look at tomorrow. So some of the impact that I think the REST API will have for WordPress going forward and into the future. So why is the API, the REST API, important? Well, I think it's important for two groups. I think it's important for us as a community and obviously a lot of the community is made up of developers. And then secondly, I think it's important for the WordPress project itself. So WordPress as a platform. So prior to the API, WordPress was a monolithic application. So it was a sort of black box where nothing really came into the system, nothing was really able to get out of the system and it controlled that publishing flow really from sort of an end to end controls and beginning to end. Now, the API changed that. What the API did, the REST API, is that it allowed data to start coming into WordPress. So allowed data to start coming into the system, but it also allowed data to start flowing out of the system. And so what this did was really sort of a two-fold. So it liberated our data. So it meant that we could start moving data in and out of WordPress. But it also liberated WordPress itself that we could start integrating with other systems and start integrating and becoming part of a larger architecture. And secondly, why I feel anyway that the REST API is important for the WordPress project. Well, this is the dominance that WordPress has currently over other CMSs. So it would seem counter-intuitive that WordPress, that the REST API should be important to WordPress for its success and continuing success to thrive or even survive. But in fact, this very dominance potentially makes WordPress vulnerable. And that comes from some ideas introduced by Clayton Christensen. And he was talking about when a software or a company dominates the market to this degree, it actually becomes vulnerable to those smaller, more nimble, more agile participants who can innovate much quicker than this dominant party. And so start challenging that dominant position and challenging that key sort of position. So the answer to this and the way of addressing this at what's called the innovators dilemma is disruptive innovation. And now disruptive innovation is starting to challenge your own position. So that position of dominance that WordPress has within the CMS space at the moment to overcome that potential vulnerability to more nimble and quicker iterating organizations is to start challenging itself and challenging its own position via disruptive innovation. And that's exactly what the API is doing. The REST API is starting to challenge us as a community to start innovating within WordPress. And I would suggest that Gutenberg is exactly the same thing. It's starting to challenge ourselves to innovate and to move forward with our software. So what is an API? Let's have a quick sort of top level look at what an API is. So I often like to think of an API as an electricity supply. So in and of itself it really doesn't do very much. You can turn it on and it just sort of silently sits there. It's really what you can sort of plug into that electricity that is really sort of diverse and awe-inspiring and empowering. But the API itself is the electricity supply. Now, I'm about to visit Guatemala in a couple of weeks. My wife is Guatemalan, which in turn means that my father-in-law is Guatemalan. Now, I was thinking, as I'm sort of preparing for this trip, I was thinking about the API in these terms, that my father-in-law doesn't speak a word of English. So I can't communicate or I struggle to communicate with my father-in-law. And conversely, my Spanish is criminally bad. So I can't communicate at all in Spanish. So my father-in-law has something that I'm very interested in and that's Guatemalan culture or Latin American culture. So I'm interested in the music and the food and the pinatas and all the other things that are enriching about the Latin culture. And conversely, I have things that he's interested in. So he's interested in English culture and that might be warm beer and fish and chips. And he's obsessed with it. He thinks we're all pirates for some reason. So unfortunately, my poor wife is a sort of a conduit between my father-in-law and myself. So she has to translate from one to the other and this is the only way that we can access information and the information that we want to pull from each other. And this is kind of like an API, but I think we can do it a little better here. So let's imagine that my father-in-law and I resolved to learn a shared language and so let's suggest that that's Pigeon Esperanto. So now we have introduced this third language into the mix and we might not speak very much of this language, but as long as we've agreed, we've shared that information between us so we're sharing that Pigeon Esperanto, well now we can communicate in that shared language and so my wife can put her feet up and we can start communicating together. Now this is much closer to what and how an API works. So in this example, I might be a WordPress install and my father-in-law might be a 30-year-old Kobol piece of software. In fact, he might have been around before even PHP was created. However, because we have the shared Pigeon Esperanto and it's actually JSON in the REST API, we can communicate and we can share information. So let's have a look at when to use the REST API and look at some examples of when we've used the REST API. What I'd like to do is sort of home down on two particular areas. So I'd like to look at architecture and we're going to look at some examples of using the REST API as a tool within our architecture and then we'll look at data and we're going to look at some data manipulation using the REST API. So first I'd like to look at using the REST API to enable us to use WordPress as part of an overall solution within an architecture. So this is an example. This is a sports organization which we're just about to embark working with and what they'd like to do is utilize the standard publishing flow of WordPress. So the content team will be creating content within WordPress and then pushing out in a familiar format into a PHP template. However, they also want to ingest news and information. This happens to be an API but it's not via the WordPress REST API ingesting news into the system. They then want to curate that news so they want to decide which news they're going to push forward and publish on their platform and they'll likely summarize it and sort of wrap it in their own summary and information. Now, this is a proposal for an MVP structure but it presents us with a problem and probably a couple of problems. So the first is a performance. So getting WordPress to do this heavy lifting so ingesting the API, ingesting that data whilst also incidentally it's running a subscription area over here and it's also running an e-commerce area over here and so we're really starting to put pressure on WordPress as our key component of our architecture and so there's actually probably a better way of doing this and that's to offload some of that heavy lifting into the resource and that's likely to be a Node.js script running which what it will do is ingest that content so rather than coming directly into WordPress it'll ingest the content into a content API. That will be cached content so we'll be able to call that content into WordPress when the content team decided to ingest that into WordPress they can then enrich it within WordPress so within the WordPress interface there'll be adding taxonomies and metadata and all that other enrichment and then pushing to the front end and it's likely that what we'll do is push into a restricted area of the content API so we'll create a sort of a published area of the content API and then conversely our front end can pull that data down for the content API and it can also be pulled down from other services so it can be a newsletter and apps and so on so as you can see this portion of our architecture is separate from WordPress and whilst we're sort of engaging with WordPress and WordPress is communicating with this dedicated area it's not doing the heavy lifting let's have a look at another approach so this is using WordPress as an API delivery system now this was for an organization who are making available information about every single swimming pool across the globe so they have swimming pools in every major city and hotel swimming pools and you know sort of public baths and there's information around you know is it child friendly or pet friendly I don't even know if that's a thing is it you know the opening hours can you book in advance and all that kind of good stuff so what they wanted to benefit from is the sort of standard WordPress publishing flow so they wanted to interact with the graphical interface of WordPress, the back end they would then push that data into WordPress now the difference with this implementation is that there was no website at the front end of this implementation so what they wanted was a publicly queryable API so this information could be pulled into widgets, could be pulled into other sites and other sort of data sources around the internet and so all that was available was the data the pure data via an API feed now this was a good fit for WordPress using it as a delivery system because we weren't doing anything else there's no subscription, e-commerce and all the other things we were talking about previously the system wasn't doing anything else but delivering an API and delivering the data however there were still some performance issues that we faced and there were still some improvements that we felt we could make so there was a couple of things that we did one was introduced Elastic Search Elastic Search is a flat data storage so it distributes your data into a cluster and shards it into a cluster so you can retrieve sort of lightning quick queries it's very good at multiple query points so all those filters around dog-friendly pools or whatever we were talking about that's what you can do with Elastic Search it's unique sort of queries so we introduced this Elastic Search layer which gave us that data performance returning the API and also introduced an accelerator plug-ins this is a little must use plug-in that we wrote that enabled us to bypass the standard WordPress boot system so the sort of boot sequence in WordPress is even if you're serving up an API it's going to load the whole sort of boot sequence loading your theme and your plug-ins and so on so we built a little bypass must use plug-in that would just ascertain that it was an API call and of course in this model everything is an API request and then we would sort of send it send it into this plug-in this must use plug-in that would then bypass all of the plug-ins that the sort of the plug-in array and push it straight to the API constructor so the endpoint constructor so as you can see we were using WordPress as the solution but we were sort of building and enhancing some of those elements within WordPress let's have another look at another example so this is integrating systems now this example is Fairfax Fairfax are a large Australian publishing company and this is a project that Keeman May recently embarked on where they have an existing content API so they have a million plus existing sort of articles and data pieces and so they have a media API serving up their images, media and so on and then the content API which is actually receiving information so again you're seeing that similar model where we're ingesting information from somewhere else so this is the wires or the press association or Australian equivalent pulling data into the content API and then the existing sort of media API now what Fairfax wanted was that they wanted their journalists, their editors and other employees to benefit from WordPress and benefit from that graphical interface that WordPress offers on the back end and also part of that sort of publishing flow and so they wanted to integrate with those existing architecture and integrate with these existing APIs and that's exactly what they did they allowed the journalists to start pulling data and articles down from the content API so they could create data in the normal flows so that the normal sort of publishing flow they'd all recognise as you're constructing and creating an article or they could pull articles down and refine them from this content API they then set them to preview and that would trigger and there was a Slack integration where it triggers to an editor that there's an article that's ready for review and so the editor then pulls that down and they pull it down into WordPress they can then enrich it so they can be adding the meta and the really wanting their employees to have that benefit from the WordPress interface but it might be connecting with other services that weren't originally intended and the media API is a really good example of this because the journalists can upload their images to WordPress so in our sort of media uploader in the normal way however they get sort of hijacked if you like by the media API and it pushes out to a cloud and read service so it doesn't actually reside within the WordPress install so let's have a look at data and data manipulation and I like to think that data manipulation with the API is as easy as pie and so what I mean by that is that presenting and integrating and experimenting with data and this is really what the REST API allows us to do so let's have a look at some examples of these three areas so this is a plugin that I've been working on recently this is a plugin called Site in Numbers and what this plugin allows you to do is start drawing out big data from your website so it's intended to be sort of allow the site owner to pull out big data visualization opportunities around the sort of total word count on the site or the total read time it might be the publishing days of the week that you publish on even down to the sort of times that comments are made and so really starting to enable the site owners to see patterns in their own data as well as their potential audience to see patterns in the data so the way that we've structured this is it's sort of three-fold so it has an admin interface this is the interface for the site owner so here they can sort of select the sections that they want to add to display on the front end or sections that they want to pull out then in turn it has the API construction layers so this is where we pull together start constructing all those statistics start constructing all that information and then creating this JSON data object so this large object of data that is then pulled into the front end so this is a JavaScript layer it's pulling that JSON information in and then it's distributing those statistics those numbers into the relevant places around the site but then also as you can see it's using chart.js to start constructing charts so presenting that information in different and varied ways so this is really where the heavy lifting is being done on the server side so WordPress is doing the heavy lifting constructing that data, that big JSON object and then the processing is being done in the JavaScript and processing that information that comes through let's have a look at another project this is a project called IM Team GB this is a project we did for ITV the British Olympic Association and the National Lottery and among many things that we had to do for this project one of the things was we had to provide an inbox sorry an input box where you could put your location so it might be your postcode or your city of residency and then we'd show events that were relevant to you and we'd show them within distance order from your front door so we had many thousands of events that were being created that were actually being ingested in from another system again via the REST API and so we'd have those events and then we'd be needing to show the relevant events to that individual and where they've searched from so this is how we did it again we relied on WordPress as our interface we were actually ingesting those events into this WordPress site and I pulled out the JavaScript layer here because when we put in and so in that example I'm putting Brighton in which is my hometown that's then firing an API request to Google Maps we're looking for the longer-tuned latitude and so we might get an error back if we're not UK based we get that long-tuned latitude back into the JavaScript layer JavaScript is then via the API, via the REST API making a request back to our system and what we've done is we've split the UK into four sections and the reason that we've done that and we've split it into four endpoints the reason that we've done that is because we're dealing with large quantities of data and so we need to make that data manageable and we need to sort of narrow down our focus as to what data set we're bringing back so we did some calculations and four was about the right number and so the system would ascertain where your long-tuned latitude which sort of pot of this sort of region that we should be pulling that data back from so in this example it's number three we pull that data back via the API and in this instance the JavaScript layer is probably doing quite a lot of heavy lifting because we get this great big unordered JSON data object back and then the JavaScript has to sort those events and calculate the distance from your front door and then present it to the user and obviously all of that needs to be done in lightning quick time so let's have a look at another example this is integrating now the interesting thing about using the REST API to integrate systems and integrate with systems different software and different clients have different definitions of what integration means and so it's really important to define what's meant by integration and what we're trying to achieve by integration now a great example of this is SAGE now we're working with SAGE the global financial company and this is from the SAGE homepage so this is a site core site so site core is a .NET content management system but the content that you're seeing isn't coming from site core it doesn't reside within site core this is coming from a WordPress site and it's actually coming from SAGE Advice which is the blog section of the SAGE ecosystem and that's built in WordPress so how is this information coming across and what is this integration? well through discussions with SAGE we were talking to a number of sort of stakeholders SAGE and that was including the tech teams and other participants within the organisation it became clear that for SAGE integration meant displaying contextualised information in the right place so it's about being able to pull the right information in and then display it anywhere around the SAGE ecosystem so that's exactly what we did what we did is we created a custom endpoint so an endpoint where anywhere within the SAGE ecosystem they could pull contextualised data and pull information in and then display it within that sort of space within the ecosystem and incidentally as you're seeing on the end of this endpoint we have a number of filters and these are also really important because this was an opt-in so you could add and indeed they do add as little information as they want so our relevancy is quite low they might just add the category or they can start turning up that relevancy so really start adding the tags and other taxonomies that are available and so getting really relevant results depending on the information they provide because behind here resides a relevancy engine so when you hit this endpoint that data comes in so that request comes in and then the system starts allocating points if you get a tag match you get a point and then if you match the categories you might get three points etc etc and so it's really sort of constructing a league table of relevancy for the different posts around the system and then we know that we're returning just the most relevant results back to wherever that request has come now what this enables us to do is start making all these connections between the different systems so what you're seeing here this is a site core site and this is a WordPress site but because we're creating this interconnectivity what we're doing is creating a deeply integrated user experience there is no friction as somebody moves from site core into WordPress and back again and indeed they don't know that they're moving between systems and that's by using the REST API and our approach and so allowing all those touchpoints between the two different systems so let's have a look at experimenting one of the things we mentioned before is that one of the real value of the REST API allows us to start innovating and challenging ourselves and experimenting so here's some examples and some experiments that we've been working on now this is a recent thing that I've been playing with this is Ionic and this is an integration with WordPress so Ionic can create a native app can compile into a native app but it's data source where it's pulling that data from WordPress now this is fully crud to what that means is I can create and edit and delete information from the Ionic interface and it will actually persist down into the WordPress site so as you can see I'm adding Charles to Charles Darwin there and if we come back to the WordPress site so the data site sits behind it you'll see that that change has actually persisted into the WordPress site now this is really exciting because it enables us to start thinking of our content as dynamic and it can start being affected and change from around an entire ecosystem and this is just one example where it's being changed via Ionic over here on a mobile but it could be anywhere within an ecosystem and so we can really start thinking of our data as fluid and WordPress is just sort of the storage vessel for that data and we're affecting it across a larger ecosystem let's have another look at a different example this is where we sort of challenged ourselves to start thinking about WordPress in a different way so what could we do creatively with WordPress and particularly around the REST API what would it enable and so what I was thinking about was as a games engine I've never thought about WordPress as a games engine so I was thinking about how would you do that how would you go about that and so what I'd settled on was a football simulation or a soccer simulation for our international friends and so you would be able to think of like a turn-based game so you'd be starting to run that relationship and a progression of times there's a couple of things one was as you can see there's sort of shadow taxonomies here so shadow taxonomies taxonomies that don't really persist onto the front end so we're just using them to create sort of one to many many to many network connections of data so if you think a sort of football match it may have clubs it may have players and players may have agents and so on and so forth so there's lots of interrelationships between that network so that was one element of it but then the other was a time engine so thinking about the progression of time and how we could build that within a WordPress space and in DGS and REST API so that's exactly what we did we created Herbert after HD Wells and Herbert is a time machine that is essentially passing on time so the passage of time is moving on and Herbert is controlling events that are happening in that space so there might be certain events which are clock stopping which stop the passage of time and then other events which just persist in the background and they're updating the user so we're still very early but that idea, that notion of using WordPress and using the REST API to start constructing WordPress and manipulating data in an entirely different way is a very interesting approach and certainly if something that we've enjoyed thinking about WordPress in this different way so let's have a look at a more immediate example so this is the Gutenberg interface well it was the Gutenberg interface a couple of days ago it might have changed by now but in fact, Zach's probably talking about that right now so I've been interested for a while in the impact of Gutenberg of what it's going to mean to us all and one of the things that I have been interested in the while is that in WordPress we have this great big content area and it's this great big sort of imposing area that is impenetrable that we can't really get into the information that's in that content area now of course Gutenberg is changing that it's turning our content into discrete blocks so we're going to be able to start constructing and building out sort of pages from these sections and so what it enables us to start thinking about is potentially drilling down to that information and so rather than just accessing a post and sort of accessing information at that level we can actually start drilling down and looking at individual blocks within the content so what I've been thinking about is where we have post tags and post tags is where we tag at post level we can start thinking about adding content tags and so content tags might be tagging individual blocks you might have a paragraph about some sort of you know a topic over here and then an image in a post over here and you know a bullet point list over here but what if we use our content tags we can start forming those relationships as we've been talking about before that that network of relationships between data and so then we can start constructing these dynamic pages which is pulling related content together and really allowing us to modularise our content so as we developers often modularise our constructions we modularise our sort of SAS files and our JavaScript files well this is one approach where we might start being able to modularise our content and actually pulling it out and showing related and relevant content so I'd just like to say a few words around performance just some sort of things that we've found when using the REST API so the first is around transients and using the transients API I have to be careful obviously we're talking about the REST API the transients API WordPress has a number of APIs and the transient API is a really useful one transients are database storage there's ways of caching data objects now they're very useful for something like the REST API so if we're making requests and we're requesting data that may be persistent and other users are requesting then we can construct it into a transient and then it will cache it within the database and we're going to get a much quicker response time so as you can see here we were hitting about 5 seconds or so drop that into a transient and we're getting a huge slash I don't know if you could read that but we're down to 0.4 or 0.5 seconds now there is a caveat with transients and it's really a use case that you need to be aware of so if you have a high traffic site they are temporary storage and so your user may go to the transient and it doesn't exist and if the transient doesn't exist it blocks the transient for the user however that's true for all users so if you have 20, 30 concurrent users then they're all going to be constructing that same transient putting huge pressure on the database and on resources there are a few ways around this but one is asynchronous transients which is the plugin which I suggest looking at if you have those sort of racing conditions and big high traffic now the other thing that we did and I'd recommend and we mentioned this before is the accelerator plugin or that similar kind of architectural solution so this was a site that is dedicated to the API so it's just a delivery system but by default it's loading in our theme and our plugins and our other sort of resources so we use this accelerator plugin and it simply just bypasses the plugins and so it just gives us straight to the information that we wanted and we managed to slash that by about two-thirds so a huge saving just in thinking about how the WordPress boot structure works and then thinking about how we can manipulate that but in a secure way and so not sort of making any compromises on security I'm going to make these slides available I don't expect you to read all those but these are some dev resources indeed they're asynchronous transients and some distributor plugin is a very interesting project at the moment so there's some bits and pieces there I've also put together some other resources so there's a white paper and see the Slack channel is a very active channel around the API so what I'd like to sort of leave you with is just thinking about Tomorrow and where the rest of the API is sort of taking us to Murrow so for me I think we've opened up this opportunity and it's an opportunity to be innovative to sort of challenge ourselves as a community in particular as a development community I really start thinking about the sort of integrations and the opportunities that being able to have access to our data anywhere in different sort of services and different solutions what those opportunities present us I mean it's certainly we can start working and collaborating with different teams and different agencies that may have no relationship with the WordPress space but the API is allowing us to do that because our data then becomes platform agnostic the fact that it's originated from the WordPress makes no difference because JSON is platform agnostic so it allows us to start manipulating and moving data around and so for me it doesn't really matter where the API goes the rest API may be superseded by other API solutions but it's really it's not what's important what's important is we've enabled that opportunity for the community to start moving information and treating data and thinking about data in a very different way and so as we were talking about before that innovating into new space that challenging ourselves and challenging our own dominance I think that's exactly what the rest API does it allows us to start innovating into new space and taking WordPress into places that it certainly hasn't been before and so as we were talking about before as the API the rest API as an electricity supply well it's truly inspiring what electricity supply enables and all the myriad of things that you can do when you're given that power and that opportunity thank you we have five minutes for questions there thank you and then here thanks thanks for the talk question about the transient API are you using transients directly or do you go through the cache, get set etc so in our current structure we're using transients directly so we're creating a transient and the plugin that I was talking about the site and numbers plugin is constructing a transient directly some of the things that we were talking about around the compromises or potential things that you need to be aware of and so that's that current racing conditions as you have lots of users starting to construct those transients so looking at the asynchronous transients and so what that essentially does is sort of creates a full back transient so if the transient doesn't exist you go to a full back conversion so you don't have those construction pressures on the system and for me currently that solution sort of overcomes I think one of the key flaws of transients when you have that full back you no longer need to think about other solutions I think that's a good sort of fit for us just a related question how long do you keep the transients or how long do you set the expire on them that's a really good question so just to be clear transients expire so they're sort of temporary data storages and so by default you normally set an expiry date and so the transient sort of doesn't persist for too long I tend not to set the expiry date so you can actually set a non expiring transient and then you can start replacing the same transient and so as long as you use a naming convention which is the same name you don't then have to concern yourself with that expiry date okay follow up on that a non expiring transient is stored in the options table which is autoloaded which will put pressure on the memory of your server so as a pro tip you can set an expiry date on all transients to not kill your server with lots of transients I've run into that it's not good I can well imagine and in fact if someone were to be talking specifically about transients there's all sorts of little tips that you need to be aware of there are little caveats and gotchas and there's a really good one a really important one so yes that's very sage advice you do need to be mindful when using transients so that you have consequences to your actions we have another question here thank you you spoke a lot about the performance problem so my question is from someone that doesn't got inside this matter deeply in the past but looking from the outside do you think it's preventing this API system to be widely spread and used and do you think in the future that the WordPress core will improve this issue it's a really good question I mean so the problem that we're trying to overcome with that accelerator plugin is we're trying to bypass that boot sequence that WordPress does by default and that's an obvious quick win because if we're going to use WordPress in a different way and so as a delivery system then there really is no need to be sort of loading all this information that's not going to be utilized I mean it is it is a a concern to a degree or there's certainly something you need to be aware of but there are all sorts of caching layers that you can introduce so you can start making that more performant that transients we're talking about is one option to start increasing the speed and efficiency of your system but one of the things we haven't talked too much about today but is the opportunity it gives you to start introducing new front end libraries and frameworks into your architecture so things like react and view and so on and so the payoff is that you then have this whole other opportunity to start building and structuring things in a different way and so you can start thinking about the performance some of the performance savings we can make over here but this opportunity it presents us to sort of you know far outweighs the performance concerns we might have currently sort of you know over here this is it for us for this morning please let's give it up thank you lunch is served