Serving the Internet of Things (IoT) with Drupal - DrupalCon Barcelona 2015
1 like661 views
The document discusses how Drupal can serve the Internet of Things (IoT) by acting as a content and service platform, enabling devices like fridges and smartwatches to connect and interact with web services. It highlights Drupal's capabilities, including content management, user access control, and API creation for integration with various IoT devices. Additionally, it covers strategies for building external APIs to enhance performance and manage services effectively in an IoT context.
Serving the Internet of Things (IoT) with Drupal - DrupalCon Barcelona 2015
- 1. Serving the Internet of Things (IoT) with Drupal Kalle Varisvirta Technology Director Exove
- 2. In this session What’s Internet of Things? (briefly) What does my fridge need Drupal for? How is it actually done? Content as a service
- 4. Internet of Things Internet of things usually refers just to all things gaining internet access, from smartwatches to toasters In this presentation, the definition of the Internet of Things is based on everyday things gaining internet connections home automation, energy equipment, wearables etc.
- 9. What does my fridge need Drupal for?
- 10. What does Drupal offer? Drupal offers a platform for content Drupal offers a platform for easily controllable data structures and data in it Drupal offers fine-grained user access control Drupal offers an online store Drupal offers user-generated content and the storage for it
- 11. Drupal as a back-end Until Drupal 8, all Drupals returned HTML when getting GET or POST requests Drupal 8 changes this in the core, but earlier Drupals could be made to do the same When removing the front-end from Drupal, it becomes a content and service platform that can do more than just web pages
- 12. Drupal as a back-end Decoupling the HTML layer from the content was originally aimed for flexibility for the front-end, essentially headless Drupal It also makes Drupal fully capable of connecting to any display system, whether HTML-based or native
- 13. Examples
- 14. Example: A health monitoring service All textual content across devices, with language versions, can be easily stored to Drupal Changes to content as well as news and notifications can be delivered straight to people’s wrists from
- 15. Example: Self-service gym A mobile site, where people could extend their membership Drupal can bill monthly, or support pay-per-use Smart lock would open door for to a certain Drupal user role
- 16. Example: Online store for connected fridges An app in a connected fridge A back-end as a Drupal online store for groceries Connected to a card payment system, ERP for product and balances and logistics for orders
- 17. Real world? We’ve done mutiple implementations with different IoT devices Most of them use Drupal for some resources
- 18. How is it actually done?
- 19. Serving machines Easiest approach is to create a REST API Drupal 7 has modules for serving (or helping to serve) all data out via a REST API Services, RestWS, RESTful and JS module or Endpoint for those looking for something more exotic Drupal 8 ships with a REST module in core
- 20. Serving machines Any service directed to behead a Drupal might not be suitable as is for serving any machine out there For example Drupal 8’s REST API is very Drupal-specific out-of-the-box You should separate your Drupal’s internal data structure from the data you’re serving out Not to make a point by separation, but to allow versioning and smooth control of the API evolution
- 21. Serving machines A proper REST API needs to follow the rules (stateless, cacheable, layered, uniform) It also needs to be well-documented for integrations Security, both by access and transit, need to be considered Also, take into account possibly needed changes by versioning your REST feed
- 22. Serving machines An Open API with proper documentation is a good way to open up your resources for all the networked things out there, but it’s not at all always enough Many times you’ll have to integrate to a machine - even if you might feel the architecture would be better served if done the other way
- 23. Connecting to machines Integrating to machines is different than integrating to other services running on servers in server halls It’s combining appalling reliability with poor to useless network performance And you’ll be connecting to 1 or 10 000 units
- 24. Connecting to machines For connecting to machines, you’ll always have implement a proper connection architecture Simplest architectures would use queuing to prevent failed connections from losing data More elegant approach would be some kind of messaging system, observer or publish/subscribe design patterns
- 26. Let’s take a plunge with Drupal architectures
- 27. There was a time when just a Drupal website was enough. There are still times like that.
- 28. But then we needed a couple of integrations.
- 29. And then a mobile app, which we would serve with ready- made HTML or a JSON view.
- 30. But then we wanted a Javascript front-end and opted to go with a headless Drupal.
- 31. And suddenly, we could just open our REST interface to the world and let everything on the internet integrate.
- 32. And if Drupal couldn’t perform to take care of all the traffic, we’d move it as the enterprise content management storage and delivery system.
- 34. Building an external API Sometimes the only solution is to not use Drupal for the API, but serve the content to a separate system building the API I’ve talked about this in my “Accelerating headless Drupal with Node.JS” presentation
- 35. Building an external API In this approach you’ll index all your content outside Drupal every time it’s edited To a MongoDB, SOLR, Elasticsearch, Redis or whatever serves your purpose Writes pass through to Drupal or are queued in the external API layer and then executed to Drupal External API layer is built performance-oriented, with e.g. Node.JS or Go
- 36. Building an external API Serving just content might not be enough, you might also need to front some Drupal services, like authentication or authorization All services that can be, should be cached on the external API layer
- 37. Building an external API Enables you to have full control over the API Enables you to aggregate and mix data from multiple sources, like adding pricing information to Drupal’s products from ERP - this is one of the principes of REST And you’ll get blazing performance, if you do it right
- 39. Taking Drupal to enterprise When trying to get Drupal to that “enterprise background system” -level, you’ll might find resistance Enterprise architects would like to keep to world Microsoft-only or traditional enterprise software-only and let Drupal stay outside, handling only the sites
- 40. Recap
- 41. Internet of things Is a buzzword and means a lot of things, but usually just devices not originally designed to be connected, but that are getting connected these days Can use Drupal for content or for a variety of services, like authentication and authorization
- 42. How to do it? Creating a REST API is the most straightforward of solutions Drupal 7 has a couple of really good REST API modules, but Drupal 8 has REST in core API should be versioned or backwards compatible Sometimes a REST API isn’t enough, but you need to adapt to the client’s (bad) way of connecting
- 43. And then…? Move your API outside of Drupal for performance, better control or aggregation of services Index Drupal’s content outside to MongoDB and front the services with a Node.JS layer
- 44. Thank you!