Serverless Microservices for WordPress
Microservices: Imagine that your application (for example, your WordPress site) is broken into smaller services (i.e. microservice). Each service handles one part of your application’s operation. One service might only handle the authentication of users. Another service might handle the comment system. Yet another service might handle the routing of web pages. All of these microservices operate together through APIs (application programming interfaces) to form a cohesive product. In a nutshell, this is the idea of microservices.
This post is not recommending that you abandon WordPress and adopt a microservice architecture for your web application. A complete microservice application comes with many unique issues and is typically only used by large, monolithic applications. In this post, we will explore incorporating a single microservice into WordPress.
A Case for Microservices
WordPress can be used to handle a variety of different and varied tasks for a web application. For routine tasks like forms, SEO, and analytics, there are many top-notch solutions available out of the box. Often, more complex or unique problems can be solved with a bit of custom code within the WordPress ecosystem. Sometimes, however, there is a reason to offload a task to another environment. Perhaps there’s an existing service that handles your data with the perfect output structure. Maybe you need to manipulate an image in a very particular manner. Or, you might even need to process data using machine learning. This could be difficult to do within WordPress’ ecosystem, or even just to tackle within the constraints of time and budget.
Five Reasons to Use a Microservice
1. Your team is more productive in solving this problem outside of the WordPress ecosystem
Perhaps your team is full of experts in Python or C++ and you need to solve a problem on your WordPress site, but want to work in an ecosystem that they are more comfortable in to solve a complex business problem. Since you will be more productive using a different toolset, building a microservice might be right for you.
2. Software exists to solve this problem using another set of tooling
At Pixel Jar, we have created microservices for WordPress sites using Node servers deployed using Now by Zeit. We chose to develop a service this way for a few reasons. The first reason is that there were already Node.js packages that handled what we needed to do. The majority of the code was already written for us. All we had to do was implement it with a few lines of code and a simple web server.
3. You want this software to run separately from your public-facing website
For our Node.js microservice at Pixel Jar, we had software that needed to run when a certain form on our site was submitted. We did not want the potential to have a few concurrent form submissions slow down other parts of the site. The load was on another server, and not the public side of the website.
4. You want to leverage existing software platforms to solve your problem
Another use case for a microservice would be to utilize an array of software from a single provider. Amazon Web Services, Google Cloud Platform, and Microsoft Azure all offer a wide variety of tooling to solve a ton of problems. They include tooling for things such as Machine Learning, SMS messaging, image manipulation, and much more. Plus, all of these platforms offer something called “serverless”, meaning that you can hook up many of these services together without having to run and manage your own virtual server.
5. You want to maintain this code separately
You may have a separate team working on code for a particular problem in your business, or you might even be an outside firm in charge of developing a tool. In some cases, maintaining code as a microservice can be immensely beneficial to all parties involved.
A Brief Overview of the Implementation
Once you have decided that building a microservice is right for you and your specific problem, you build it. How you do that is up to you. You might build something in a programming language that nobody has heard of, or using a service like Now from Zeit or Amazon Web Services’ Lambda.
After you have built your microservice, you will need a way of passing data to your microservice and receiving data back. To pass data to your microservice, you will want to use WordPress’ HTTP API, detailed here in the plugin developer handbook. The function wp_remote_post is handy to use for sending data to your microservice.
For receiving data in WordPress, the REST API is a great tool to use. WordPress.org has a handbook that details working with the REST API. If you aren’t working with a component that is native to WordPress, like posts, comments, or settings, you might consider the chapter in the handbook on creating a custom endpoint.
Of course, you will want to authenticate your application to WordPress to really unlock the power of the REST API. There is a great plugin that allows your microservice to authenticate using an application password and not a user password.
Microservices can be a handy tool to keep in your back pocket for the right time. We can easily handle most problems within the WordPress ecosystem, but more complex problems sometimes require more clever solutions. If you have a particularly complex site build we’d love to discuss your architecture.
