Creative Coding

Using WordPress for Web Application Development: Rethinking Architecture


In this series, we're in the process of talking about how we can build web applications using WordPress. And though this isn't a technical series in which we'll be looking at code, we are covering topics such as frameworks, foundations, design patterns, architectures, and so on.

If you've not read the first post in the series, I recommend it; however, for the purposes of this post, we can summarize the previous post as follows:

In short, software can be built on frameworks, software can extend foundations.

Simply put, we differentiated between frameworks and foundations - two terms that are often used interchangeably in software despite the fact that they are not the same thing. WordPress is a foundation because it's an application unto itself. It's not a framework.

To that end, when it comes to building web applications on WordPress, we need to rethink architecture or re-consider our conceptual models for how applications are built.

The Structure of a Web Application

At the high-lest level possible, web applications are normally structured with the following three components:

  1. The Database Layer
  2. The Application Layer
  3. The Presentation Layer

Generally speaking, the Presentation Layer is what the user sees and what the user interacts with. It includes all of the styles, client-side code, and markup necessary to put something in front of the user.

When the user clicks on something, or the page renders information retrieved from the database, it's interacting with the Application Layer.

The Application Layer is responsible for coordinating information from the browser and/or from the user's action to the database. Sometimes, this consists of writing information to the database - such as information from a form field - to reading information from the database, like retrieving a user's account information.

Much like the Presentation Layer consists of different components - such as styles, JavaScript, markup, and so on - the Application Layer can consist of a variety of different components such as systems that are necessary for reading and writing data to the database, sanitizing information, validating information, and enforcing certain rules that are unique to the problem at hand.

Finally, the Database Layer is where the data is stored. That may consist of the file system, it may consist of a MySQL database, or it may consist of a third-party solution such as a datastore that's "in the cloud" such as Amazon S3 or something like that.

It's All Abstract

The main point to take away from this is that in software, we're always dealing with some level of abstraction. For example, we talk about the data store or the database layer, but we're not really being specific. Same goes with the Application Layer and the Presentation Layer.

  • Are we talking about a relational database with multiple tables, or are we talking about cloud storage?
  • What kind of data access layer are we going to hook up to the application layer to talk to the database?
  • What frameworks and languages are we using on the front-end? Vanilla JavaScript, jQuery, Knockout.js? What about CSS preprocessors - LESS or Sass?

Obviously, we aren't looking to provide answers to these questions right now, but the point is that all web applications consist of similar components, but the details of each component vary from project to project.

The Components of WordPress

As a web application itself, WordPress is a perfect example of how various technologies come together to form a web application:

  1. The Database Layer is a MySQL database.
  2. The Application Layer - which some would consider WordPress itself - is written in PHP and handles a lot of the core operations for reading and writing to the data store all the while providing APIs for developers to take further advantage of it.
  3. The Presentation Layer uses basic CSS (at least for now), HTML (with some themes now using HTML5), jQuery, and with parts of the dashboard using Backbone.js.

So that's the WordPress architecture, but what about the projects that we want to build on top of the application? How do they follow the same architecture?

Well, remember that WordPress is a foundation - not a framework - so we're subjected to WordPress' architecture by default. This does not mean that we can't bring in our own libraries, in some cases, but it does influence the way in which our applications and projects are built.

We'll talk more about the libraries, extensibility and more in a bit, but first, it's important to note that in a day-and-age where MVC (and MVVM and other variants of the Model, View, Whatever) paradigm are all the rage, WordPress does not follow that convention.

There are arguments for and against why that may be a good thing or a bad thing, but that's not the purpose of this post. Instead, it's simply worth noting that WordPress uses an event-driven pattern, rather than the model-view-control panel.

And to that end, it's worth understanding how the event-driven model works so that you have a clear understanding of how WordPress hooks work, and how you can shift you're thinking from MVC or whatever other paradigm you're used to using, to how WordPress manages its information.

What Does It Mean to Be Event-Driven?

Before we take a look at an example of an event-driven application, let's revisit what it means to follow the MVC paradigm.

  • First, the view serves as the presentation. The user sees information and interacts with the user interface.
  • Next, the controllers coordinate information to and from the model and the view. They respond to user actions, and retrieve information from the model to pipe into the view.
  • After that, the model represents the data in the database. This can be done any number of ways, but one of the most popular ways is to map the data in the database into an object-relational model so that the data is represented in the format of objects.

The whole MVC model looks like this:


Now, event-driven applications can have some of the same components - that is, they can have views and models or views and data objects - but they don't necessarily have a controller that's coordinating information from the front end to the back end.

Instead, event-driven programming works off of the premise that "something as happened." Hence the name for actions in the WordPress lingo (of course, we also have filters, but I'll cover those momentarily).

WordPress provides hooks which are literally points in execution in which we can introduce our own functionality such that WordPress recognizes that "when this event happens, I need to fire these functions" where these functions are defined as whatever we've provided.

The truth is, filters work the same way, but their purpose is different. In short, filters are actions that are meant for manipulating data (such as appending, prepending, removing, or updating the content) in some way before returning back to the application's execution.

So what does this look like?


Nothing terribly complicated, right?

So What's Our New Architecture?

The point of this article is primarily getting us to think in terms of event-driven programming and how to coordinate our efforts of building web applications specifically on WordPress.

That is to say that it's important for us to think in terms of events or the fact that "something has happened" so that we know when to appropriately insert our own actions. We'll talk about this a little bit more in detail in the next article, but the main point that I want you guys to take away from this particular article is that just because something isn't MVC (or whatever the next popular paradigm is) doesn't mean that it's not well-suited for application development.

Each pattern and architecture provides us with advantages and disadvantages all of which can contribute to the success of building a web application.

Up Next...

Next up in the series, we'll take a more detailed look at how hooks play a vital role in building web applications on WordPress, and then we'll start looking at some of the facilities that WordPress offers out-of-the-box that make it such a solid option for certain types (read: not all types) of web applications.

Related Posts
  • Code
    Creative Coding
    Using WordPress for Web Application Development: A ReviewApplication foundation 400
    Over the past few months, we've been taking a look at all of the features and aspects that make WordPress a potential foundation for application development. In fact, we've spent roughly 15 articles talking about all that WordPress offers. And though we'll be reviewing each of the points in this email, perhaps the biggest thing to take away that building web applications using WordPress is different than using many of the popular frameworks that are currently available namely because WordPress isn't a framework.Read More…
  • Code
    Creative Coding
    Using WordPress for Web Application Development: Custom Database QueriesApplication foundation 400
    Throughout this series, we've been looking at the various facilities that make it possible to treat WordPress as a foundation for web application development. Thus far, we've covered a lot of ground: We've talked about how WordPress is more of a foundation rather than a framework. We've discussed the nature of the the Event-Driven Design Pattern. There's been a discussion of Email, User Management, Saving Data, Retrieving Data ...and more. In the most recent articles, we've been talking a look at how to handle queries against the WordPress database through the use of WP_Query and WP_User_Query.Read More…
  • Code
    Creative Coding
    Using WordPress for Web Application Development: Features: SessionsApplication foundation 400
    In this series, we're taking a look at how it's possible to build web applications using WordPress. Thus far, we've talked about how WordPress is a foundation (rather than a framework), its architecture, how we need to conceptually think of it when approaching it especially coming from other languages, and then we began talking about the components that make up a basic web application.Read More…
  • Code
    Creative Coding
    Using WordPress For Web Application Development: Features: User ManagementApplication foundation 400
    Throughout this series, we've been taking a look at how WordPress can serve as a foundation for web application development. The thing is, up to this point, we haven't really taken a look at the features of WordPress that really contribute to building web applications. Instead, we've spent time looking at how WordPress serves as a foundation rather than a framework, and we've looked at how WordPress is organized in comparison to many of the modern frameworks that are available.Read More…
  • Code
    Creative Coding
    Using WordPress for Web Application Development: The Conceptual ModelApplication foundation 400
    With people beginning to realize WordPress' potential as an application foundation rather than just a content management system or a blogging platform, this series is focusing on just how WordPress can be used for such projects.Read More…
  • Code
    Creative Coding
    Using WordPress for Web Application Development: An IntroductionApplication foundation 400
    Now more than ever, developers and designers are beginning to see the potential for using WordPress as a way to build web applications. By that, I mean that the community is beginning to see that WordPress can be used for more than blogging and more than just content management: Instead, it can be used to power database-backed applications that run within the context of the web browser.Read More…