 So, my name is Kalle Varis-Virta, I'm the technology director at EXO. I'm gonna talk about serving the internet of things with Drupal. I'm gonna, in this session, I'm gonna go through briefly on what's the internet of things in this aspect of this session, because it's a buzzword and everybody has their own idea of it. I'm also gonna try and open up horizons on what we can actually do with Drupal and how far the limitations actually are on what you can do with Drupal. The session won't be technical, but I'm gonna let you feast your eyes on some architectural drawings on the session. But, so, let's go to business. What's the internet of things? So, it's a buzzword with a lot of meanings. Everybody has their own idea of what it means. I've heard definitions ranging from, you know, anything other than computers to specific physical things, physical things doing something physical in the physical world. To get things aligned, I'm gonna define for this session it. I'm not saying that this is the only true meaning of it. I'm just saying that I'm gonna use this as the definition in this session. So, usually we refer to all things gaining internet access from smartwatches to toasters. I have never heard of a toaster that actually has an internet access, but there might be one. Probably really useful. In this presentation, the definition is gonna be everyday things connecting to the internet. Things that didn't previously connect, but these days do. So, things like home automation, energy equipment, wearables, but also consumer electronics that are increasingly gaining internet connections. Let's take a look at a couple of examples to give you an idea of what I'm talking about here. You all know Nest. Nest is a home thermostat, a really famous one, controls your home and learns how you live. So, it adjusts it just right. There's a plethora of integrations available for it. So, it can control a lot of other things as well. Or a sensor for your waste container. It's gonna call the people to empty it when it's full. That's pretty straightforward, simple. There's a web service where you can check your expected fill updates for your waste containers and stuff. That's the internet of things. That's not a toaster, it's a fridge. I find this really awesome, by the way. I still don't find any purpose for it, but awesome. It's a Samsung fridge that has an internet connection. It has some kind of proprietary software that you can do apps and stuff like Samsung Smart TVs. It also got hacked a couple of weeks ago because they don't check the SSL certificates authenticity, which is kind of bad. But yeah, here's another one. That's a rifle that you can aim with a computer or an iPad. It also got hacked, which sounds a bit scary. I mean, genuinely scary. You can re-aim it via the hack, which sounds even scarier. But yeah, it's mind-blowing, I hope not literally. So let's go to the business. Why, what does my fridge need Drupal for? Let's go to what Drupal offers. I'll try to tell it from the perspective of a fridge. Drupal offers a platform for content. Say your fridge wants to list you product information from a grocery store that delivers. That would be kind of convenient, I guess. Let your fridge show you what's available from your local grocery store. It offers you a platform for easily controllable data structures and data in it. That would be like maybe recipes that the fridge could maybe offer based on what's in your fridge right now. The Samsung fridge, by the way, doesn't know what's in your fridge as far as I know. I hope it doesn't, but it just shows you other stuff, I guess. Drupal offers fine-grained user control and access control so you can control the access to a shop for grocery items. It offers a platform for online stores, commerce, and then it offers user generated content and stuff like that so you can even have your grocery store shop on your fridge show user reviews so that you can select the best yogurt by your peers. So what you need is a Drupal that works as a backend. Until Drupal 8, all Drupals were really kind of web content management systems so they were returning HTML when you requested something with HTTP like Ketora Post. Drupal 8 changes this, although earlier Drupals can be made to do the same, basically at least seven, but Drupal 8 is the first that's not directly aimed at coupling HTML with your data that's stored inside it. So if you remove your front end from your Drupal, it becomes a content and a service platform and it's pretty powerful in that. It can do a lot more than just web pages. De-coupling the HTML layer that we call Headless Drupal, that's something that was aimed for the flexibility of the front end so we wanted to build like really app-like front ends or have full control of your front end or develop it faster or I don't know, all these things. And it's still used for that, obviously. We're currently building one site that has a Headless Drupal and it has like a Node.js layer and React and Isomorphic rendering and all the hype words in the same project. But it also makes Drupal fully capable of connecting to any system that can read its data. So, when Driz said that like full de-coupling works in only very narrow cases, this would be those cases. But let's look at some examples. These are just to give you an idea of why and what you might consider to use Drupal for in a system where there's different connected devices and these are imaginary examples. I'm not saying we wouldn't be building something like this but I can't also say that we would be building. Anyway, the real world is not as clean as these examples. Let's put it that way. Here's an example, health monitoring service. So, you have your smart tracking device on your wrist then you store that data somehow outside. There's a web application where you can check your activity and stuff and then there might be a health app in your phone that also delivers that information. You can store all the textual content into Drupal but what Drupal offers for this kind of service would be data storage services, generating reports for the data, user profiles, social connections between your friends so you can share data between your friends as well, automatic emails, reminders, push notifications. Just think about the options that you can get pretty much done free from Drupal for this. You can't ignore that. Let's take another example. This would be a self-service gym, so there's a mobile site, there's a smart lock in the door of the gym so you can get in via the mobile site so that either you have a passcode for the lock or it's actually connected to the site so you can go and click it open. There are locks like that on the market, plenty of them, different locks that you can use. You can use an app for opening doors and if you lose your phone, then your sheet hard of luck but that happens also if you lose your keys. In this situation, Drupal would offer a shop with connections to payment gateways, different roles for different users, say if you get a gym membership that you can only use during workdays, during the daytime of workdays. Reminder emails, statistics, workout reminders for users again, there's a lot of possibilities here and this is what we briefly touched here as an example for the beloved fridge, an app in a connected fridge that can let you order groceries while staying on the door but it's actually the Samsung fridge, you can open the door and it's still, the app is right there so you can see to the fridge and still click away, that's how it works. The freezer is I guess behind the app thing that you need to refill separately, I don't know. But this is again, a full blown online store and there's no reason really if you would have an app on a fridge that allows you to buy groceries why wouldn't you have the same shop also as a web service online and then you could also serve the people who have their iPad connected just attached to their fridge door, I've seen those. But in the real world, as I said, it's not that clean and simple to explain but the things we've done with different IoT implementations, we've done smart TVs for instance, an API feeding Drupal information with like Drupal content out to smart TVs. Also that needed some special arrangements for the smart TVs so usually we'll get to that later but usually the things aren't that straightforward as you would think, again, that's the real world here. We've done medical wrist alarm devices. Again, that those things don't speak rest. We'll get to that later as well. And then we've done handheld golf gaming devices which had part of the stuff was working to Drupal so. And we're currently building another Drupal enabled feed that also is directed at feeding machines. We don't know what machines yet but I hope we'll get to that part later. So how do we do this? I can let you in in a bit of a secret. It's not that hard really. You just have to have the courage to do it with Drupal. You feel like Drupal is for the web, it's not for the web, it can do a lot of other things as well, you just need to have the balls to sell it for this purpose. But yeah, serial machines, easiest approach, a REST API. This is hugely popular these days, talking about REST APIs and stuff, but that's what it is. Drupal 7 has modules for serving data out with REST like services, WES, RESTful, JS module endpoint. If you want something more exotic, they also partially bootstrap Drupal so you can get performance gains with them. Drupal 8 ships with a REST module in core. If you want to find a good comparison or well, yeah, a good comparison of REST modules, there was a session by Konstantin Komelin and Kate Marsalkina in Drupal camp politics a couple of weeks ago so you can find it online. You can check that out. Any service, what does that sentence even mean? Let's go to the next line. For example, Drupal 8, well yeah, so Drupal 8 REST APIs are really Drupal specific. If you look at the output coming from a Drupal 8 REST API, it has a lot of things that's, if you're not a Drupal developer, you'd be like, you know, really pondering on what is this all about? What kind of feels, there's a lot of feels that have something to do with Drupal and not that much with the actual data. So, G's even mentioned that in the G's note today, he said that there's either too much stuff or too little stuff or you need to do multiple calls to get the information. So you should separate your Drupal's internal data structures from the actual API you're serving out so that your API is good. And also that's, you know, kind of what it's all about. So the API should just be for the API and not for any of the systems. And I'm not saying that you should separate them for security purposes because that's just stupid. I hate when someone tells me that, well you can see the internal data structure from there. Yeah, you can see the internal data structure. That's security due to obscurity and that's nonsense. Doesn't really secure anything from anyone. Okay, so a proper REST API follows the REST API rules. They're stateless, cacheable, layered, uniform. It also need to be well documented. If you're serving out stuff from an API, it's paramount, I'd say, to have a good up-to-date documentation. You can use a web page. You can use some services online for it, like APRE, Swagger. You can use Markdown to do your documentation, convert it to everything. It needs to be secure. So you can do, if you have a real triple API that offers access to, let's say, internal systems behind it, you can do very dangerous things with it. So you need to take on, consider that really thoroughly. And then you should take into account that when you have an API, you should always have either versioning or it should be backwards compatible. I can tell you from experience that I always prefer versioning, even though it's a hassle, because backwards compatibility just has you carrying out that legacy stuff for ages and years. But I understand people who have to do that as well. It's okay. An open API with a proper documentation is a good way to open up your resources for all the network things out there, but that's not nearly enough usually. Many times, there's something totally different you'll have to integrate too. So there's no device that can, you can just tell the developer that, well, I have a REST API, just read my API and get the content from there. No, actually, there's something really odd happening in the other end and you'll have to do the architecture all the way around. In my experience, the difference between different clients comes from the computing power available or the kind of maturity of the computing platform. If it's like a handheld device built by a customer themselves and they write some really low level stuff on this, they might be really reluctant to follow like the good principles of REST API. They just offer you some binary proprietary format that you'd have to read and maybe decipher and decipher again. If you have like a smart TV on the other end, that's a programming platform that can do a lot of things. So there's like system level services for accessing REST APIs, shouldn't be a problem. If you have a really small RIST watch size thing, but not an Apple watch, I'm saying like a really more like a stupid watch, then it becomes that you'll be in a mess of deciphering and deciphering binary things back and forth. And if you're connecting the other way around, so you'll have to connect to all the services, all the systems around there, it's like push information from Drupal to the other way. It's totally different than connecting to servers running in server halls because it's a polling performance available on the other end, like almost useless network reliability. And you might be connecting to a lot of them, but it's like out with your perfect API blueprints and then you just go and do a really, well, specific implementation of a format connecting there. But whenever you're connecting to machines, there's an architect that you need to consider performance, persistence and security. The connection architecture is important. You have to at least have some kind of queuing process to prevent the connections losing data because the connections are unreliable always. More elegant approach would be to use some kind of a queuing message queue system that might work a bit better. You can still integrate Drupal into them. It's not a problem. If the other end can use something like that and then the messaging system takes care of your messages going through. I personally use a considerable time of architecture design. Every time we have a situation where there's questions about performance, reliability, that kind of stuff. And then you just have to adjust it along the way a lot of times and you have to make compromises and stuff. Okay, let's talk a bit about content as a service because that's what we're doing here. We're serving content, but we do it as a service. So we're just serving content, not HTML pages. Take a short plunge with Drupal architectures. It's an evolution of sorts, but it's not something that you would always end up at the bottom of it. But there was a time when just the Drupal website was enough. There are still many times like that, but then you needed a couple of integrations. You just put varnish upfront and it's your really typical Drupal implementation integrate to some standard CRM and a non-standard ERP in my experience. And then there's a mobile app which you need to serve either HTML or a JSON view or something from Drupal. You can always have a rest API at this phase as well. But when you do a rest API, you might go all the way headless. And if you're going headless anyway, you can serve other things as well. Don't limit yourself. So this is where we are at in a good situation where we have systems that can read a proper good well-documented API and there's no problems serving all your Drupal content out there. And if Drupal can't perform, then there's the option of moving it behind as part of the enterprise system level, background services, and then use something else to aggregate the API. That's something I'm gonna talk about briefly here. So sometimes you have the need to build an external API. You can't use Drupal for it because there's like too much stuff that you'd have to build on Drupal or there's too specific proprietary connection architecture that you have to follow that might need, for instance, callbacks or event-based handling of stuff going through in and out. I've had this talk about accelerating headless Drupal with Node.js and in this talk, I did mention this or explain this a bit further how you build an external API. So building an external API in this approach, you index all your content outside of Drupal. Every time it's edited to a MongoDB or Solar Elastic Search Redis. To index your stuff to MongoDB, there's a module for it. We did one module for, I would be using it for multiple production environments now called MongoDB indexer. It's just storing all your content outside of Drupal or you can configure what content it stores outside of Drupal. In this case, the writes coming back, they pass to the platform to Drupal or even directly to Drupal or then you can queue them in the external API system and then execute them one by one in Drupal so that the Drupal won't be dead under the weight of the traffic. The writes might become problematic because you have to write a lot of extra code for handling the writes into Drupal. If there's a lot of writes, then you'd have to think of an architecture that works better. But this is usually the case that you get like 10% of writes and 90% of feeding out data. You might have something stored already on the Node.js layer or the acceleration layer. External API layer is built performance oriented with like Node.js, but this is only for content. Although I was there, the whole talk is about content and delivering content, but sometimes you need some other services from Drupal because Drupal offers a lot of services outside of content as well. So on vacation, there's user roles, user groups, user friends, connections. All those services would be needed to be cached on the API layer and there's no module for that at least yet would be pondering on creating one for that as well. What you gain from an external API on in front of Drupal is you have the full control of the API so then you can use a version and use your, you can aggregate the different sources from ERPs. This is a real world case. We have like six different background systems that we aggregate information to an acceleration layer serving our data. And you'll get placing performance if you do it right. Here's proof. This is an actual screenshot from a performance tool online. So that's a service serving our Drupal data. About 13,000 requests per second and it can do different kind of filtering and stuff. There's a Node.js and a MongoDB backend behind that. By the way, at this rate of three requests you'll also become an expert on optimizing Linux TCP connections because they tend to become problematic at this rate. But then that's what you have to do. When you're talking about systems like Internet of Things, serving them with a special API, you're gonna be deep in big companies or at least companies with a lot of systems around. So I would think about it as a path to taking Drupal to enterprise. So when you try to get Drupal as a backend system in an enterprise to serve content around different platforms, different services, different machines, there's gonna be resistance from enterprise architects that have grown used to Microsoft only world. They would like you to use instead of a REST API, they would like you to use the Azure Service Bus or Beastalk or something like that. Or not definitely run a Linux server in their systems. But that's something that might happen there. All right, let's do quick recap presentation. If you fell asleep, just keep your eyes open for the next three slides. I promise you'd be on top of things again. So Internet of Things is a boss word, means a lot of things, but usually just devices not originally directed at connecting, but are getting connected these days for added value, can use Drupal for content or variety of services like application authorization. And as I said, it's all about your courage to just do it. And how do you do it? The REST API is the most straightforward of ways. And Drupal 7 has a bunch of good REST API modules, but Drupal 8 has REST in core. As you all should know by now, we just need to get it out. But yeah, APIs should be either versioned or backwards compatible. And sometimes REST API just isn't enough because your Internet of Things device specifically requires some really odd connection method and then you'll have to be coding and hacking away to some nights. And then when you have your stuff delivered from Drupal, you can move your API outside of Drupal for performance. Better control for aggregation of services. And you can just index it outside to a MongoDB and serve it out with Node.js. That's the thing. Thank you. So if you have any questions, please walk to the mic because it's apparently at least very important to record everything here. There's like big notes around. Questions? Go ahead. Either walk to the mic or I have to repeat your question. I had a question about architecture. You said you should use at least some simple sort of queuing mechanism. Do you use like enterprise service bus systems in your setups? I try to avoid stuff like that. I consider like the Microsoft technologies I mentioned like Azure service bus, one of those systems that does, but they do that what they claim. They're just hugely expensive and kind of, I think, hard to get connected to your systems. But yeah, use enterprise service buses would be one option for that. But I'm talking about maybe a bit more simplified queuing. I've seen, well, there's a story about doing an electronic lunch voucher thing that sent, that happened five years ago or something. It sent you an SMS for your lunch voucher so you could buy lunch. But it did subject your balance every time, but it only tried once to send the SMS. And that's the problem with queuing. It just lost the information that it was trying to send you an SMS. And the SMS sending system was really unreliable at that point. So I'm just expecting someone to try until it works. Some kind of a queue. It doesn't need to be enterprise queuing system. Yeah, but like what about open source Java? I can't remember the name, but it really works perfect for the situation that you just described. Yeah, I would totally prefer open source Java service buses, yeah, instead of the hardcore proprietary stuff. I haven't used, I guess we've once used some kind of an Apache project that was a service bus. But pretty rarely, yeah, anyone else. All right, thank you.