 Thank you. So, when to use the rest APIs. As Monique just said, my name is Sean Blakely. I'm a senior technical architect at Pragmatic, which is a UK WordPress agency. I work largely on enterprise scrum-based projects and I've been working with WordPress, as Monique said, for about a dozen years or so. So this talk is aimed mainly at people who are considering using the API in their projects or, indeed, tentatively using the API in their existing projects. So, what I'd like to look at is why the API, the rest API, is important. I'd then like to look at what the... Sorry, guys, there's some animation on these slides. Is it possible to put it into presenter mode? I'll carry on talking while I'm just waiting. I'm going to talk about what an API is. So we'll look at an overview of a couple of metaphors of what APIs are. And then we'll move on to look at when to use the API. So we'll look at some examples of when we've used the API. And then briefly, we'll look at what tomorrow may mean. So what the rest API may mean for WordPress tomorrow. So why is the rest API important? Well, I think it's important for a couple of reasons. So firstly, it's important to us, the community, to developers. And secondly, it's important to WordPress itself. So prior to the rest API, WordPress was a monolithic application. It was essentially a black box where data wasn't able to come in. Data couldn't come out. It controlled the publishing sort of process, end-to-end process from beginning to end. Now, the rest API changed that. The rest API allowed us to move data into the system, but it also allowed us to move data out of the system. So it really liberated our data out of that, out of WordPress itself and made it platform agnostic. So we were able to start integrating with other services and other systems. And then why the rest API is important for WordPress? Well, this is a breakdown of adoption of content management systems. And so WordPress has a seemingly unassailable dominance in the marketplace within CMSs. But counterintuitively, this actually creates a vulnerability for WordPress. So these were some ideas introduced by Clayton Christensen, who talked about the innovator's dilemma. And what he was saying is that when you dominate a market to such a degree, you actually become vulnerable to the agility of these smaller pieces of software or smaller organizations that are much more nimble and much quicker to disrupt the marketplace and being the dominant player, you're not able to adjust quickly and you're not able to adjust your position. And so you become vulnerable to that agility. And so his recommendation, his solution for that problem was what he called the disruptive innovation. So that's where you start challenging your own position. So WordPress starts challenging its own dominance and deliberately disrupting its own position. Now, that's exactly what the rest API does. Starts challenging up. And indeed, it's exactly what Gutenberg does as well. So what is the rest API? Well, I like to, sorry, just for a moment. Is there any chance we can put it into presentation mode because there is some animation on the slides? I'll leave that with you guys if that's possible. Great, thank you. So I often think about an API similar to a power socket in a wall. So whilst it has lots of potential and offers us power, it really doesn't become useful until we actually plug something into that power socket. So this slide isn't going to make any sense to you at all because this is animated as we gently move from one section to the other. Let me try and recreate it for you. So you might have to close your eyes and imagine this as I walk you through it. So I've recently just got back from Guatemala. My wife is Guatemalan, so we're going there to visit family. And it got me thinking about APIs and connecting systems in this way. So behind the WordPress logo is me and over there is my father-in-law. Now, my father-in-law speaks a smattering of English. A few words that he remembers from his primary school days. My Spanish is criminally bad. So it's really difficult for us to communicate, but he's got things that I'm really interested in. So I'm really interested in Latin culture in the music and the food and the sort of parties, the fiestas. And equally, he's interested in English culture. So he thinks he doesn't understand why we all drink warm beer in England, for example. He's interested in fish and chips, and he genuinely thinks that we're all pirates in England. And so my poor wife, who's in the middle here, has to bounce between my father-in-law and me trying to translate, as I'm speaking English or terrible, terrible Spanish, and my father-in-law is speaking Spanish, so she's translating back to English. So this is a bit like an API, but we can do a bit better than this. So imagine that I and my father-in-law decide to learn a shared language. So let's say that that's Pigeon Esperanto. So we decide to learn this shared language. Well, now my wife can put her feet up. She doesn't need to translate anymore because we can communicate via this shared language. Now, this slide would be animating as we're talking. So what we would see is a transition to WordPress. This might be a COBOL install. And, of course, it's unlikely. And, of course, our Pigeon Esperanto would be JSON and wouldn't be Pigeon Esperanto. And we're not going to be talking about pirates and piñatas. We're going to be talking about user objects and legacy data tables and so on. So when to use the REST API. And I'd like to give you a couple of a few architectural examples, so ways that we've utilized the REST API to help us create an elaborate architectural solutions where WordPress is already part of that solution. And then we'll talk and look at some specific use cases where we've used the REST API. So WordPress is part of the solution. This, and again, I'll talk you through this. This is a startup company. This is a sports startup company. And this company is interested in promoting information around sports that aren't necessarily in the public eyes. So the football and rugby and cricket and so on, the most popular sports. But there's a huge long tail of other sports that there's a lot of interest in. And so this company wants to promote those sports. So they're really interested in using that classic and the traditional WordPress. The content team will be creating content within the WordPress space. They'll then be enriching that within WordPress. So adding their taxonomies and images and so on. And then pushing that out into the front end of the website. However, this presents us with a few issues because one of the things they also want to do is to ingest news feeds. So that news feed might be the press wires or might be from other sources. But these are articles that they want to pull down into the system. They want to select the articles that they want to publish on the site. They want to enrich them but also add a sort of summary and contextualize those articles. Now, this presents us with a challenge because we have some performance issues around this. Now, this, our WordPress layer, our business layer, is running a subscription. It's running a sort of user management on all sorts of other heavy lifting within this website. So to then start ingesting this feed as well, we're going to start putting pressure on that core system. So we're likely to hit some performance issues creating pulling this into WordPress. Equally, we're going to hit some scalability issues. So as new sports are brought online, we're going to start exponentially growing this system and this architecture isn't going to support that growth. And then the third thing that would be a real concern is that if you're taking this news feed and pulling it directly into WordPress, you're very vulnerable to any changes that are happening in this source. So anything that's happening in the news feed, you're not protecting your system from those changes. So what we'll be implementing, so the architecture that we'll be using is creating a content API. So this API will be a sort of node server that will be ingesting those news stories, so pulling those in from the press wise or from whatever the source is. WordPress will then be pulling in from that content API. So we're protecting ourselves here with an abstraction layer. We can make those changes from the source. We can make those changes in the content API. We don't need to change anything in our WordPress layer. And then we can push those articles. So once the content team have enriched them as they need to, we can then push them to a published section of the content API. And the value of doing this is it then frees us up to change our front-end technology. So we might use React or View and so on. But we can also push to other services. That would be a newsletter service or a dedicated app and so on. So let's take another look at a slightly different example. So this is WordPress as an API delivery system. So this is a simpler architecture where WordPress could do the heavy lifting here because we're not doing any sort of user management or e-commerce and so on. This is for a startup company wanting to show details about swimming pools all over the world so that you might be in Belgrade and you're looking for a swimming pool close to this venue that's open after 7 o'clock. So as you put those details in, the system would return you relevant details. However, there was no website at the front of this project. There was no website to query. It was a publicly queryable API. So you might be pulling this down from another site, from a widget or some other sort of service, and you'd be pulling that relevant information in. So we were able to rely on WordPress to do this heavy lifting, but we did consider some performance issues and those issues were around data retrieval. So when we were doing these unique searches where you're combining a number of parameters before then returning the results, we were finding quite a slow performance issue. So we used the API. We integrated with a service called Elasticsearch, a sort of flat distributed storage system which then returns almost lightning fast results. So we were then able to complement the WordPress architecture and start moving our data storage and improving the data storage. So in this example, although we're using WordPress as the graphical interface, so the way that the content team are uploading their content is via WordPress, we've actually decoupled the front end. It's a headless CMS. And we've also changed the storage systems or using an alternative storage system. So let's have a look at integrating with existing systems. Now, this is a project by HumanMade. This is a Fairfax project. Now, Fairfax are a large Australian publishing company and they have an existing content API with over a million articles within that content API and also an existing media API. And I think that has well over a million multimedia entries which then connects to a cloud service. That's a cloud network that's storing those images. Now, what Fairfax were interested in was utilising the publishing flow, so the workflow of WordPress. They were interested in their journalists and for their editors to be able to utilise WordPress as their interface but then wanted to utilise their existing architecture and to integrate with their existing architecture, so the content API and the media API. So that's exactly what they did. They utilised the content API, allowed journalists to create stories in the normal way or pull them down from this dedicated content API. The editors, once they were flagged for review, the editors could then pull them down, enrich them with images and the taxonomies and so on that were required and then they would push them to this published section of the content API. And then a react front-end, so the front-end would be pulling in this data from the rest API and also pulling in images from the media library. And so what we see in these three examples is that each time the client has requested WordPress as to core graphical interface that they want their content teams to work in. The architecture that sits around WordPress, be it the storage or the front-end, changes for each project to adapt the requirements of the client. But that core experience for the content teams are consistent and is within WordPress. So let's have a look at some examples of working with WordPress. So I like to think of working with the API as being as easy as pie and by that I mean presenting, integrating and experimenting. So let's have a look at the first example of presenting. So this is a plugin that I've been working on for a while. This is a plugin called Site in Numbers. And what this does is presents to a site owner, indeed their users, all sorts of information, data and revealing statistics about their site. So it might be telling them the total word count of the entire site, giving you a breakdown of where that content is, giving you an insight into the publishing times, the publishing days, your most popular and successful content and so on and so forth. So trying to give a sort of big data visualisation and an opportunity to understand your site in more depth. So the way that this is structured is we have an administrative interface, a graphical interface where the site owner can drop and drag these different sections that they want to show onto the front page. We then have our business layer. So this is our API, rest API construction sort of layer where we're creating a large JSON object and that JSON object contains all our statistics and all our data and all our raw data. And then that's pulled into the front end. So pulled into our JavaScript layer which then constructs that data into the sort of visually rich charts and so on that we're presenting to the end user. So let's have a look at another example. This is a project called IM Team GB. This is a project that Pragmatic worked on with ITV and the National Lottery and the British Olympic Association. And so this was introducing Britain's biggest sports days. There were many thousands of events happening simultaneously around the UK and among many of the challenges that they presented us with was enabling a user to put in a search so you could search wherever you were in the UK and we would then return you relevant events within distance from your front door. So the way that we did this was that we and again I'll talk you through this, you're missing the animation unfortunately. So we used WordPress as our core to do the sort of the core of the site. We had our JavaScript layer. So as you input your city, let's say, well it has to be in the UK, let's say Liverpool, as you inputted your city we would fire a request out to Google Maps API. We'd make sure that where you were searching for was in the UK. We'd then get your longitude and latitude coordinates, fire that back via the rest API into the back of the system and what we'd done in the back in the UK into sections. So as we had many thousands of events to make it a manageable load we took and chunked the country into a number of sections and then pushed that data and pulled that data back into the JavaScript layer and then presented it to the end user and this would happen in a matter of milliseconds as a user experience. So using the rest API to integrate with systems. What you're seeing here is Sage.com, the Sage.com home site. Now this is a home page, so this is a site core site, so runin.net. However, almost everything you're seeing on the screen is coming from WordPress. It's coming from a WordPress site. So within Sage there's a number of systems, an ecosystem that has a number of different content management systems and different solutions of which WordPress is one that runs the Sage advice service. So we created an endpoint for any of the ecosystem, anywhere within the Sage ecosystem to pull and request relevant contextualized data and sort of results and posts. So as you can see here we had an endpoint where and this turned out to be quite important for the system that it was an opt-in solution. So you could add as few of these parameters as you wanted so you might just define a category and so we would return you relevant results to that category but you could add a multitude of different parameters and so you'd be turning up the relevancy of the results that return to you. So sat behind this endpoint was what we were calling a relevancy engine where we would take all those parameters to take all your search parameters and then start scoring, so essentially creating a league table of relevancy and then returning those results. So what this enabled us to do was to create this a number of connection points so these are touch points between the different systems. So a site core site on the left here and the WordPress site on the right site core might be showing content that's actually generated by the WordPress site and vice versa. So what we're creating are these numerous touch points across these two different systems and it leads to a seamless user experience where the user has no idea that there's actually two different systems built in completely different solutions and different languages because it's an entirely seamless experience for them as they're moving from one system into the other and indeed there's portions of each site which are being delivered by the other system. So let's have a look at experimenting. Now unfortunately you're not going to see this. It's animated but I shall again briefly talk you through this. So this is an ionic app and this app is run by WordPress. So behind this app where we can do full crud rights we can create and edit and so on a WordPress site is running that information. So you will have seen if this was running that there's an article that's around Charles Darwin and so we add the name Charles to that article and then what you'll see is that that then persists into the WordPress install so we're making a change within an app on your smartphone and that change is persisting within WordPress and that really takes us back to that point we were looking at very early in the talk when we were talking about that free flow of information where data can move freely into WordPress and move freely out of WordPress and that's exactly what's happening here is that we're really removing the reliance of our data on WordPress and it's becoming platform agnostic as we can be changing it editing it and moving it within the ecosystem of our whole service. So this is an example of something slightly different. We challenged ourselves to start thinking about WordPress in a different way and thinking about ways that we could experiment with WordPress in ways that maybe we hadn't before and so we decided to set the challenge of creating WordPress as a game engine and what could we do could we create a game using WordPress so the game or the type of game that we settled on was a football management simulation and so we created these tournaments like the World Cup you might have teams and so the team object is linked to a league so tournament objects and in turn they might be linked to a country object and you have players and so on and so forth so it's a really interesting exercise to think about this interconnectivity this lattice of objects and data and how they interconnect but we used the REST API to solve the problem of time within the game so it's an interesting challenge to try and think about creating a time machine and how time would persist in this virtual world and so we created an endpoint where we would fire this time machine which we called Herbert and we would fire this API request our time machine would then move on and we could fire events in the game so that might be a World Cup fixture or injury to your best player or whatever it might be so this is and I'm sure interfaith now this is something that I've been thinking about for a while that as we've modularized our built files so we think of our sort of SAS partials and our javascript files as we break them into modular chunks so I think that content has the opportunity to do the same modularization to our content so I often think of posts and pages within WordPress as being like that black box so that's sort of self-contained black box that we were talking about before as WordPress was before the rest API well so posts and pages are at the moment they're really a sort of binary you're either displaying the content or you're not but Gutenberg gives us the opportunity to change that so Gutenberg splits our content into discrete blocks and one of the really positive consequences of that is that we can then access those discrete blocks and start displaying them and manipulating them in different ways and so one of the things that we've been experimenting with is something called content so much as you think at the post level you add post tags well we would add content tags so contents to individual blocks and so what we'd be able to do is then create these dynamic pages which are generated from those content tags and pull out hyper relevant blocks that you've searched for and then pull those blocks out and display them there's some really exciting things we can do around AI and using certainly what Google call intent which is the dialogue flow service where we can utilise that intent and really start making this a dynamic service but that would be the next iteration on this so let's have a brief look at performance so whilst using the rest API there's a couple of things that we've found that has been really useful with regards to performance so the first is and I don't think this is going to work because this isn't animated so again I'll talk you through this the first is when you're creating large JSON objects so the example that we looked at before was a site in numbers where we're creating a very large JSON object so all those statistics if you remember you can pull into the JavaScript layer well that's a heavy payload and so we were finding some big performance hits so we've got about four and a half seconds that could get up to five six seconds at a time so we started looking at transients and transients is a way of storing and caching that data so transients are a way of caching data within the database temporary data and so by implementing that and we can see it here transients we could slash that down to about a tenth of what it was previously at about 0.40 0.5 seconds so however I mean using transients comes with a number of caveats you need to be very careful so we have we need to be aware of the sort of expiry dates of transients we need to be aware of our bloating of our database we also in fact if you have a very popular site or you have a lot of users on your site you need to be aware that if the the transient doesn't exist then the user generates that new transient but if another user comes along at the same time and requests that transient then they too will be generating that transient and so what we create is these racing conditions where we have a huge number of people generating the transient and causing our system and a huge problem so there's an async transients which is a 10-up plug-in which sort of addresses some of those issues there was another saving a nice performance saving that we made so this is the plug-in that we created at Pragmatic a very simple plug-in it's a must use plug-in where the boot sequence of WordPress we go through a very standard flow as WordPress loads and for an API call and indeed for any call we continue with that standard boot sequence however we created this little plug-in where we intercepted an API call so we recognized that this was an API request and then when the boot sequence got to the the plug-in folder we diverge so not download these unnecessary resources we diverge and go straight to the construction plug-in for that for that endpoint and so that resulted again a huge saving about two-thirds shaved of our performance by just intercepting those API calls and then diverging and taking them elsewhere combining those two services those two approaches to performance pay huge dividends when working with the REST API so here are some resources some information some dev resources around the REST API I'll leave these up on the screen for a second and then equally here oh and what I will mention just briefly is the accelerator plug-in that I was just talking about is on GitHub so you're more than welcome to go and have a look at that and here are some wider resources around the API including some white paper and the Slack channel and so on so what does Tobro bring for WordPress and for the REST API well for me I don't think it's important if we move away from the REST technology and we move into an alternative technology for me we've created the beginning of something so we've created this opportunity where we can start looking at sort of integrating with other services integrating with other software that simply wasn't possible before we can start collaborating with other agencies and other teams that we weren't able to whilst we were that black box and that monolithic application and I think this is me and my Guatemalan father-in-law and I think it's really important not to forget that in fact this is us sharing a moment and this is made possible by Google Translate and by technology and I think it's really important to remember the huge human impact that the work that we do can make to people's lives thank you thank you Sean for saving the moment by improvising maybe another applause because you did really well so you know we're running late a little bit but we have time for maybe one or two questions long questions with short answers or short questions with a short answer so who wants to have a go we have Micron as in a venue does one here in the middle hello thanks for the great talk you mentioned using work process kind of a headless CMS and integrating it that way with other services so in that scenario how do you handle for example post previews how do you handle post previews previewing content from admin excellent it's a really good question so unfortunatly had we had the animated slides we would have briefly got into this so where we were talking about Fairfax which is that Australian publishing company where they had that pre-existing content API when the editorial team pulled down the contents pulled that content back into WordPress they enriched it within WordPress they would then push it to a preview section content API now that section was only accessible on the front end with a query bar that would then enable you to sort of unlock that preview and so you'd be able to view it in your React front end or your standard front end in the standard way and then flag it for publication and that would then trigger it into the publish section of the content API and the front end would then pull out so it's a really good question because it is something you need to consider it's not out of the box when you start creating this architecture so you do need to if it's part of the publishing flow that's required you do need to create this dedicated section of the content API for that and for the previews okay one more quick one on the side can we have a microphone there that's an WPRS API expert so forgive me if this question is perhaps a bit done do you have an experience with loading entire pages through WPRS API is it something that REST API allows if it does allow how does it handle page builders because page builders are something in a WP ecosystem that I simply can't fit with WPRS and other changes okay thank you was it page builders did you ask page builders like WPRS Korean okay so it's an interesting question I mean in answer to the first section of your question we wouldn't use the REST API to pull down the whole page so it's really best to start thinking about your pages as components and so component elements that might make up the page now those components might have their own REST API calls or they might be triggered within your JavaScript layer to decide which of those components need to be pulled in you may indeed use a GraphQL service which is where components can actually dictate which small section of the data they want to pull down so that's really addressing the issue we're just talking about where we're talking about that sort of component modernised approach as the page builders would that be something to discuss at the hallway track no I'm going to have a go I'm not a fan I'm going to put that out there now I mean when you see the output I'm not going to mention any names when you see the output of some page builders that they take over the content area they just fill it with spaghetti code of short codes and all sorts of other gumpf that then as developers we have to unpick and try and turn that back into something that the system can use however, with that said I entirely appreciate that for clients it's a really valuable tool and sometimes that's actually a deciding factor for them using WordPress adopting WordPress Gutenberg, God bless Gutenberg I think is going to help us and is going to improve that so we can say goodbye to some of these page builders but in answer to your question it's really tricky if that data is embedded in the content area we're pulling in that in via the REST API we're going to have to have some sort of regular expression hell to try and strip out all of that additional data or we're just going to have to sort of rethink our architecture and I'd suggest that the latter would be the better solution so they're not really compatible as they stand at the moment Great question I can imagine there are other questions but we have no time left so will you be at the conference today and tomorrow and will you be available for questions? Absolutely People can just walk up to you and say hi I want to know something about the REST API James Bond, Harry Potter, anything All of the above, of course they can Can they contact you online if they have any questions There are some contact details in the corner there Thank you so much and another applause for Sean Blakely Thank you