Server architecture

Although Tasker is a simple app, we've built it to mirror a typical enterprise setup, as shown in the following diagram:

The mobile device (say, the user's phone) is considered the presentation tier of the app; this is where the data is displayed to the user and where they can manipulate it. Although this book is a PhoneGap book, we actually won't deal with this tier until Chapter 5, Communicating between Mobile and the Middle Tier, and later, since we need to establish the foundation of the app first.

The mobile device doesn't have to live on the enterprise's network. Depending on the sensitivity of the data, the mobile device might be expected to connect to the enterprise's network using a Virtual Private Network (VPN). This essentially means that the device exists within the enterprise's network. Since this adds an extra burden on the user (they need to connect to the VPN prior to using the app), this isn't always desirable. For this reason, we've built our app under the assumption that our app won't require a VPN.

Note

There's no real difference in how we code our app whether or not we connect to the backend using a VPN. It largely boils down to how much we trust the intervening networks with the data we are handling, and the trade-off for the end user when managing the VPN connection. The code, however, operates in the same way.

The dotted lines in the preceding diagram represent the dividing line between the Internet and the user's network and the enterprise's internal network. All communication comes into the web server, which represents the web service API for our app. The web server receives requests from the presentation layer and then passes them on to the database server, which represents the backend or data tier of the app. In our case, the data tier also contains a good deal of the logic tier (where calculations are made and data is manipulated).

Since Tasker's logic lives in the database, the actual architecture looks more like the following diagram:

Regardless of the architecture, it is important to note that the database server has no direct exposure to the outside world. At the minimum, the database server will be placed behind the enterprise's firewall. It's also not uncommon for many firewalls to be used in order to create various zones of ever-increasing security.

Even though the database server's exposure to the outside world is minimized, one must always take care to sanitize any incoming data in case a malicious user attempts to send data that will adversely affect the system. For example, SQL injection attacks are often used to inject malicious code into the database in an attempt to extract and/or destroy data.

Access to the database server must be carefully managed and protected. Should an attacker gain unauthorized access to the server, the data should be considered to be compromised—even if that data is encrypted (it just might take a while to decrypt).

Tip

Encryption is important; however, this doesn't guarantee that an attacker won't eventually gain access to the encrypted data. This is why you should never store any data that isn't necessary and also why it is important to follow security best practices. For example, don't store passwords in a form that can be decrypted; use salted hashes instead, and use a strong hashing algorithm (like PBKDF2). Better yet, delegate authentication to a server specifically designed for secure authentication. For example, when dealing with credit card information, avoid storing credit card numbers at any cost. Instead, delegate this responsibility to third-party providers. Your enterprise surely doesn't want to incur the cost and loss of trust, should that kind of information be leaked.

In this chapter, we're dealing with the database server. As we've mentioned, we've elected to build the business logic in the database server as well—though other enterprise apps might need to have the business logic in a separate instance. Both options are valid, and there are benefits and detriments to both methods.

For the database server itself, I've chosen Oracle 11gR2 XE on a CentOS 6.5 64-bit Linux server. The database software is a no-cost version of Oracle's Standard and Enterprise database servers that provides a simple install on many popular operating systems (Windows and Linux). The free version can store up to 11 GB of data, uses only one CPU core, and can only address 1 GB of RAM. XE doesn't support some of the same enterprise-level features that the Standard and Enterprise editions do, but for simple apps, the XE version offers an excellent trade-off between the power of an Oracle database and the cost. If you'd like to learn more about Oracle Database Express, visit http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html. In fact, it isn't uncommon that XE is run in tandem with its enterprise cousins in the organization, simply due to cost and easy setup. If an app isn't storing extremely sensitive data and doesn't need a great deal of enterprise features, then an XE instance can be more cost-effective than purchasing a costlier license.

Of course, there's no reason why another database server wouldn't work. MySQL, MariaDB, PostgreSQL, SQL Server, and so on, would all have been more than sufficient for our needs, and they are sufficient for many enterprise-level apps as well. It's wise to compare the feature sets of the database servers and the needs of your app, and select the database server that will best meet the needs of the enterprise and the app.

Finally, it's critical to understand that we can't cover how to set up a database for an enterprise-level app (especially with regard to high availability, disaster recovery, table-level encryption, and so on) mainly because these are database administrator and network security concerns, and require a good deal of understanding to correctly implement. Alternatively, if you want a secure backend in the cloud that takes care of a good portion of the security side for you, you might want to consider a Backend-as-a-Service (BaaS) such as Parse; however, this will depend on your enterprise's willingness to have data stored in the cloud.

Tip

Don't assume that you need a typical SQL-based database! There are lots of other options available for data persistence, including the popular NoSQL trend. For example, a document store would likely be more appropriate for a document management app. To learn more about NoSQL, see http://en.wikipedia.org/wiki/NoSQL.

One of the benefits of using Oracle is that it has a very expressive procedural language called PL/SQL, which makes it possible to build the app's business logic within the database. This has a benefit in that the code is available to any client connecting to the database, which is useful for reporting solutions, automated processes, and so on.

On the other hand, having the business logic in the database has a corresponding downside. The code is not necessarily portable to other platforms, and PL/SQL doesn't have the same large community that other languages have (such as Java, C, or even Objective C).

Oracle isn't the only database environment to support a procedural language, either. A SQL Server has its own flavor (Transact-SQL), as does PostgreSQL (PL/pgSQL). Even though these attempt to solve similar problems, it is not typically possible to move the code back and forth without large changes to the code—this is something you definitely must consider; is your enterprise willing to be tied to a single database server vendor or does your enterprise need to be extremely flexible with regard to database server vendors?

You'll need to weigh the advantages and disadvantages to host the business logic on the database server or on a separate instance based upon the kind of app you are building.

Tip

Don't want to install database server software on your own machine? Consider using a virtual machine. It will be slower than a dedicated hardware; however, it means that you don't have to risk your primary computer's configuration by installing large complicated software on your primary operating system. Alternatively, consider spinning up virtual servers on other hardware or in the cloud (be careful with security concerns if using the latter).