At WordCamp Miami, which I attended recently, one of the most popular topics of discussion was leveraging WordPress to power mobile applications. At this point, I think everyone is an agreement that you can, in fact, use WordPress to power both web and mobile applications. Now it’s time to answer the questions “Should I use it?” and, if so, “how do I do it?”
These questions don’t have one simple answer. In fact, they are highly contingent on the project, budget, requirements, and competencies of those involved.
Like every other type of project, how well you plan it is going to be one of the biggest determinants for whether or not your project will be successful. In this article, I will address the different questions that you need to answer during your planning; and then, in future articles, I’ll delve a bit deeper into them.
It’s important to note that these are only my opinions. Each project is different, and so you will have to answer these questions for yourself on a per-project basis.
Do You Know Why You’re Using WordPress To Build Your App?
Building web applications is very different than building WordPress sites, themes, or plugins, and, how you use it, may invalidate some of the reasons for choosing WordPress. As a result, you need to think through which reasons still apply and decide if it still makes sense to use WordPress at all.
Here are some of the big reasons to choose WordPress to build an app—which, for the most part, apply to any type of project:
- Awesome and highly extensible content management and editing
- A solid and secure relational database that is easy to query
- A totally customizable REST API
- A strong commitment to backwards-compatibility
- PHP—a mature, solid, and rapidly improving language
- A powerful and extendable URL mapping system—for example, WP Rewrites
- Your overall familiarity using and working with WordPress
These are all good reasons to use WordPress; however it’s important to consider that it is not the only solution out there. Keep those in mind, listen to the WordPress-haters, as their alternatives might be good options, but keep in mind that you know WordPress, and you’re good at it. That alone may be the reason you’re using it.
Before you start asking any other questions, you first need to understand why you are asking them—because you decided to use WordPress and that has it’s pros and cons.
Will You Use the WordPress Backend for Administration?
One of the great things about using WordPress to build a web app is that, while you are building it, (and even before you have a working front-end interface), you still have a completely functional backend. While you are developing and testing, you can use the WordPress backend, as well as WP-CLI and the REST API, to fudge the data.
Once the app works, an important question to ask is if you need front-end administrative interfaces, or if your privileged users will still use the WordPress backend to do things like create content and moderate users and content.
This also extends to managing WordPress and plugin updates. Will you use WordPress’s plugin and theme admin or will you use Composer or Git to keep these dependencies up to date?
Personally I don’t see a need to create too many redundant admin features. In fact, I love having wp-admin available to me, as it allows me to avoid accounting for every possibility in the first version of my app. If something needs to be fudged, an admin can do it.
As far as managing dependencies, if you’ve followed my articles here and elsewhere, I think Composer is the way to go. It makes it easy to keep dependencies in sync between production and development environments.
Will Your End-Users Use the WordPress Backend?
Not all apps require user interaction and front-end data input; however many of them do. For this types of application, you probably have to create a front-end interface for the interactions. Knowing what interactions and what types of data should be input is incredibly important.
In the next section, I will discuss whether you should decouple your front end from WordPress or not. When thinking that through, don’t forget to consider how users will submit any data you need from them. If you are not decoupling your front end, using a form-builder plugin for building the interactive UI is a huge timesaver.
Being able to use Caldera Forms to create a large part of my UI has saved me a ton of time getting to MVP because I inherit its layout tools, validation, sanitization, and entry tracking. For every form builder plugin that you do choose, make sure you can easily move the form configuration between environments, which generally means opting not to store the form configuration in the database. Also, think through what happens if or when you decouple the front end of your app from WordPress, as most of these plugins are not designed to work in this scenario.
Will You Decouple Your Front end(s)?
One of the reasons I listed above for using WordPress is the URL mapping. By that I mean using WordPress to create a response from any URL passed to it, and, based on that URL, do a query or return an error page.
The URL mapping in WordPress powers its templating system—a system which is powerful, but might not be the best for a mobile app. It also involves a lot of unnecessary overhead processing that’s strongly coupled to the traditional way WordPress runs queries—a function that may be redundant to the API requests that your app is making.
These are all reasons for decoupling your front end from WordPress; but the main reason that I like doing so is because it makes it easier to have multiple front ends built out for different platforms—web, desktop, iOS, Android, Windows Mobile, etc.
I wrote a three-part series that showed a proof of concept for a Node.js and a WordPress REST API powered single page web app that used a totally separate front end from WordPress. There are many other examples out there, such as K. Adam White’s ExpressPress. Roy Sivan’s Angular theme and plugin are great examples of the opposite approach—building a REST API-based app inside of WordPress.
Both approaches have advantages and disadvantages. I’m very excited by using separate front ends, but it does create a challenge, as WordPress is my core competency. Until I master a front-end framework, or partner with someone who has, I’m going to keep coming back to what I know—WordPress’s templating and routing system.
Will You Use An MVC Framework For Your Front End?
A lot of people assume that to make an app you have to implement the model view controller (MVC) pattern. While that’s not true, MVC frameworks are very helpful in creating a maintainable and scalable app. Carl Alexander makes an excellent argument on why MVC is a bad fit for how we traditionally use WordPress.
That doesn’t mean you can’t use an MVC framework. All you really need is a RESTful API, like WordPress’s, and a framework in a language that we know. Since we are WordPress developers—i.e. PHP and JavaScript developers—when we talk about MVC frameworks, we are probably talking about a JavaScript MVC framework.
There are lots of popular JavaScript MVC Frameworks including Angular, React, and Backbone. If you’re already familiar with one of them, then the choice of which one is pretty obvious. If you’re not, which one you should learn is a huge topic that I will cover in a future article.
The really important question to ask yourself—if you (or your team) don’t know any of these frameworks, is if you really should use one. It’s not required, and while they are awesome, magical things, learning one converts you from an expert to a novice. I should know, I’ve been hacking my way through the basics of some of them recently.
New World, New Questions
WordPress has added custom post types, improved the back-end interface, and added a RESTful API; and, in doing so has matured into a great application framework. That’s awesome for us WordPress devs as it sets us up to do work that is more complex, fun, and profitable.
That said, it changes a lot of things. Knowing what has changed, what hasn’t, and which questions that we need to answer before starting a project is important. In the rest of this series, I will dive into these questions, including both technical, philosophical and business questions. It’s a fun and exciting new set of challenges that I look forward to exploring.
10 Comments