With a private alpha release due out soon, we’re gearing up to help developers take full advantage of the 3.0 platform. Our goal is to make it as easy as possible to build really advanced plugins, widgets, gateways, and modules. To facilitate that we’ve written some detailed interfaces and libraries, as well as put together a pretty in-depth developer manual. And while the v3 source is almost entirely open, I figured what the heck, how about some source code documentation? So I created Doctorate.

Doctorate is a simple plugin for minPHP that documents source code using Reflection. Being able to read the source documentation without actually having to open the source code is a huge advantage. But because the Blesta API is just a simple access wrapper for the Models it’s a huge time saver for us. It would take months to document every API request (there are hundreds and hundreds), but Doctorate does it automatically.

Here is a sneak peak of the source code documentation from Doctorate…

Here is a sneak peak at the developer manual…

So when can you expect to get your hands on the developer manual and source documentation? If you’ve made it onto our developer list you can take advantage of these resources as soon as alpha is released. When 3.0 goes into beta we’ll make the documentation public.

As lead developer, my primary focus has been on designing an efficient system. Since our primary data store (where we make the most reads/writes) is the database, naturally this is where the smallest change can have the biggest impact. I’ve already discussed a number of changes we’ve made to the database system including switching to InnoDB and the use of PDO. The last is the use of unbuffered queries.

Buffered Queries

Buffered queries fetch (e.g. buffer) all records into memory from the database server and automatically close the cursor, allowing other queries to be executed. You might take this for granted. For example, you may have something like:

<?php
// What looks like 'nested' queries...
$statment = mysql_query($sql);
while ($data = mysql_fetch_assoc($statment)) {
    $statment2 = mysql_query($sql2);
    while ($data2 = mysql_fetch_assoc($statment2)) {
        ...
    }
}

This might be all fine and dandy, but assume that the first query finds 1,000,000 rows. If each row contained just 1 KB of data, that’s 976 MB of memory consumed! Keep in mind that the memory is consumed at mysql_query(), so it doesn’t matter how many rows you actually fetch (using mysql_fetch_*). Moreover, the memory isn’t freed until the program terminates or you explicitly invoke mysql_free_result().

Unbuffered Queries

Unbuffered queries, on the other hand, are not buffered into memory. Each row remains on the database server until fetched. This can drastically reduce memory consumption on the web server.

The only downside is that you can’t create what look like “nested” queries (as in my example above). But that really isn’t a downside at all, because it forces you to look at better methods for fetching or querying data. Like limiting your result set and fetching all results.

The Record component in Blesta, in conjunction with PDO, make unbuffered query support almost seamless. You really only need to be concerned about closing the cursorif you’re explicitly working with PDOStatement objects.

<?php
// Manually work with the statement...
$users = array();
$user_stmt = $this->Record->select()->from("users")->getStatement();
foreach ($user_stmt as $user) {
    $users[] = $user;
}
$user_stmt->closeCursor();
 
// Or just let the Record component to handle it all...
$users = $this->Record->select()->from("users")->fetchAll();

While the benefit of unbuffered queries may not be entirely evident on small data sets, there’s no doubting it improves efficiency. And that’s what creating an enterprise-level application is all about.

A lot of effort has gone into designing and interfacing with the database in version 3, so I thought I’d share a little insight into some of the improvements we’ve made over version 2.

We’ve beefed up the database by making use of transactions, which allow us to add, edit, or remove items from the database with the ability to undo those changes should something go wrong. Because of this we’ve made the switch from a MyISAM storage engine to InnoDB (the default for MySQL as of version 5.5), making Blesta ACID-ic.

Another major improvement is the use of UTF8 collation, which will now allow users to more easily search the database in their native tongue as well as input and output data without conversion. This is a huge improvement for developers, and we are all about developers with version 3.

Speaking of developers, another great improvement is the introduction of the Record component. The record component is a database access object that creates queries using a series of method calls. Never again will you have to worry about which comes first, GROUP BY or ORDER BY.

In addition, the Record component uses the PDO library, making queries safe and secure. But that’s not the only benefit of PDO. Can we say “multi-database support”, as in MSSQL, PostgreSQL, and others? Well, no, not at the moment, but that’s definitely a possibility.

From the Developer Documentation:

In this developer commentary, I give a behind the scenes look at the API in version 3.

What we’ve done is create a controller to make available all of the various models in a RESTful manner, using the four primary HTTP verbs (GET, POST, PUT, DELETE). All this controller needs to do is handle parameter passing and output formatting, which we’ve done here in just 342 lines. Available output formats are JSON, XML, and PHP serialization, but more may be added in the future.

The API supports an unlimited number of users, so you can delegate users for specific tasks. In addition, the API may be extended by plugins. The format for those requests is /api/pluginName.modelName/method.format.

Currently the API supports HTTP Basic authentication, but we’re looking to add Digest authentication in the future as well. In addition, we’ve added command line interface (CLI) support which is bound to make API development easier for you programmers out there.

Click the icon in the bottom right of the video player to go full screen.

There are two prevailing factors that determine how well a software product can adapt, improve, and be extended without imploding in on itself. They are:

1. Coupling, and
2. Cohesion

Coupling represents how dependent a given module is on other modules within the system (I use the term “module” in this article in an abstract sense to describe an object or set of objects that are designed to accomplish some task). A loosely coupled module doesn’t rely or expose much of its inner workings to other modules. Conversely, a tightly coupled module relies heavily on other modules and may expose portions of its inner workings so that other modules may interact with it.

Version 3 of Blesta is built on top of an MVC (Model-View-Controller) framework, which, as the name suggests, separates control into three distinct areas. Building off of an MVC framework (in our case, minPHP) gives us the discipline needed to maintain a loosely coupled system. But it’s not without its challenges. For example, as I’ve mentioned in a previous article explaining data validation, error handling can be handled in a number of ways, but the best way is this through message passing. This allows the errors of a model to be accessed and interpreted without the controller having any direct knowledge of the model or how it works, and vice versa, thus maintaining a loosely coupled relationship.

Cohesion relates to how well the various functional elements of a module are related. High cohesion requires that the module be, in a sense, single-minded. In other words, a class may have high cohesion if all of its methods are closely related. Low cohesion means that a module attempts to accomplish too many tasks, or relates to multiple distinct sets of data.

When designing a modular system, we strive for high cohesion because it improves readability and comprehension of a particular module. If a module attempts too much it becomes bloated, disorganized, and difficult to maintain.

This works hand in hand with coupling. As each module becomes more refined it generally becomes more independent, or loosely coupled. A perfect example of this is the payment gateway system in version 3, which consists of four merchant gateway interfaces (Credit Card, ACH, off-site Credit Card, and off-site ACH). Each interface is designed to accomplish a distinct set of actions (high cohesion), and each payment gateway is thereby only associated with the rest of the system through the implemented interfaces (low coupling). This allows us to create a wide variety of payment gateways that can process credit cards only, or ACH payments only, or any other combination of interfaces without requiring any changes to any other parts of the system.