I’ve been spending a fair amount of time lately thinking about whether WordPress is a viable platform for building modern web applications. Browse the Web and you’ll find a ton of people saying that WordPress can be used for a lot more than simply blogging. But what exactly does that mean? When is WordPress simply inappropriate and where does it shine? And, if you are going to use WordPress, can you use modern design patterns for web application development?
What I’ve discovered is that you can in fact build some very nice, flexible & scalable web applications built on WordPress using modern design principles, that afford you some very nice unique advantages. In this series of tutorials I’m going to step you through the details of building sites using this methodology.
In part 2 of this series, we will build a REST interface to our server, using WordPress.
In part 3 of this series, we will be leveraging that REST interface to build an data-driven app embedded in a WordPress page.
What’s Driving This?
Here’s the scenario I’m thinking about – you’re trying to build a rich interactive website. Your marketing department wants to be able to incorporate blogs, dynamic feeds, etc. and most importantly, they want to be able to create and modify their own content on the site. They don’t want to have to bother engineering every time they want a page tweaked. Sounds exactly like what WordPress was built for.
But, you also have functionality on the site that is going to require some good programming experience. You want to make heavier use of background data retrieval via AJAX instead of reloading the whole page on every click. You have some complexity around business logic to be developed on the server (e.g. messaging, mail notifications, different behaviors based on user’s roles & capabilities). There is enough complexity in the UI that interacts with that server logic that you’re starting to think that perhaps you need two applications – the marketing site and the application itself. Maybe users should first come to the marketing site, but then they would log into the embedded application, which does all the heavy lifting.
Unfortunately, there are several issues with this line of thinking. Some are easily dealt with, and some are more troublesome. Here a couple just for starters:
Authentication & Authorization
Are you going to have two completely separate authentication (are you a valid user?) and authorization scenarios (is the user allowed to do the operation they are requesting)? One for the marketing site (WordPress users), and one for the embedded application?
One of the main selling points for me with WordPress is the fact that there are so many good plugins out there. You don’t have to reinvent the wheel. It would be great if the embedded application could make use of WordPress’ core functionality and plugins to manage things like user profiles, passwords, user validation (new users receive an email with a confirmation link), roles, capabilities, etc. It’s all there, so why not use it? If your application developers go off and use their favorite MVC framework (e.g. Django, RoR, Spring, Grails, etc.), they’re going to miss out on all of that code reuse. And, unless you customize the application to use WordPress’ database tables to manage users, you’re going to have two separate user databases to maintain.
Separation of Concerns
There’s nothing that bothers me more in large application development than unwanted dependencies. They always, always end up biting you in the end. So, you chose that piece of technology that looks all nice and shiny and promises to solve all of your problems. Who cares that the only people that really understand that proprietary piece of technology are based in Nowherzistan. They said they’ll be there to support us if we need! I really prefer going open source wherever possible to mitigate that risk.
Or better yet, you’ve decided after 6 months of development that the WordPress theme you’re working with just isn’t working. You need to switch to a more responsive theme. Oh, but you’ve built all kinds of custom logic into your WordPress child theme that has dependences on the parent theme. It should only take a few weeks to extract that logic and put it into your new theme, but it actually turns into a lot more time because, let’s face it, things always do.
Or how about that nice interactive shopping cart you’ve built into one of the pages? The marketing department wants to test moving that code to another page. It should be simple, but most likely now you need to find the template you modified, pull out just the shopping cart code and move it to another template. That is error prone, and involves both engineering and marketing. That just shouldn’t be necessary. If that code were a simple component that could be dropped into any arbitrary page that would work much nicer for all parties involved.
Bottom line, as much as possible, when I’m architecting a system, I want everyone working on the project to be able to do what they’re good at (content creation, web design, server development, component development, database architecture, etc.), and minimize their dependencies on everyone else. That way, everyone can run at top speed, unencumbered by unnecessary inter-dependencies or distractions.
For instance, in the 2-headed hydra architecture mentioned above (WordPress marketing site with embedded pick-your-favorit-MVC-framework-based web application), how do you ensure that there is consistency of themes across the two? You need to make sure that everyone’s using the same CSS files for instance, but if one is based on a WordPress theme and the other is based on a different architecture, you’re going to have to do some housekeeping to ensure the two play well together.
What I Really Want to Build
This is what I would really like out of my site architecture, and this is what I’m going to explain how to build.
- Marketing site built with all the glorious functionality and code reuse of WordPress
- Embedded application leveraging all WordPress functionality wherever it wants
- Ability for site designers/developers to drop application components wherever they want and to theme as necessary
- Ability to easily change to new theme at any point
- Rich, interactive user interfaces that don’t have to reload the entire page every time there is some new piece of data to display
- Good MVC structure to my UI code
- REST interface to my server to provide clean separation of concerns and to allow me to easily provide different programmatic interfaces to my server. Think how much easier it is to build a mobile application or even command line interface to your application if the server already has a REST interface. Oh, and you’ve decided to completely replace your backend for some unbeknownst reason? Just maintain the REST interface and everything will continue to run just fine.
- MVC on the server. The only tweak here is that more often than not, I want the view of MVC here to be a JSON view of my data which is presented through the REST interface.
The key components to building this site include:
I don’t need to go into the details of building the basic marketing site on WordPress since that is covered in great details on the WordPress site and thousands of other blog posts.
Building the embedded app is going to first require some data to work with that is retrieved from a server, and thus a REST interface to that data. Part 2 of this series steps you through using the wp-mvc plugin to build a REST interface. Part 3 of this series builds the front end, a data-driven app embedded into a WordPress page that leverages the REST interface we built in part 2.
Part 3 will step you through the building WordPress pages that leverage the REST interface to building data-driven dynamic WordPress pages.