Machines that do a great job running databases are often much different from those running presentation software. To further complicate matters, the differences depend on the type and structure of database you are using. More RAM always helps, but it’s essential when indexes are involved. Big tables need much more RAM than a large number of little ones. If you plan to do many JOINS, you might be better off bucking the all-in-one trend and going with a separate database server.
When you put the database and the rest of the software together under one hood, that one machine is forced to be a jack-of-all-trades. It may be able to communicate with itself quickly, but it can’t be tuned to efficiently perform each of your code’s various tasks.
Using a big CMS hammer on a tiny nail
One of today’s trends is to strip down the work of a central hub and split it up to run as lightweight microservices. Instead of building one portal to all your data, you build dozens or perhaps hundreds of separate web services dedicated to answering specific queries and collecting specific data. Doing so allows you to create, debug, and deploy each service independently -- great for making iterative changes without having to upgrade a monolithic code base.
But using a big, fat content management system like WordPress or Drupal to do the same thing is another way to serve up JSON or XML data with a bit of reconfiguration. This may seem like a terrible idea at first glance, as the extra complexity of the CMS can only slow down the stack. But a CMS approach can also speed development and improve debugging. All of the data formatting and “content management” can serve the internal staff who are managing the system. Even if no users touch the fancy layers, it can still be a big help for the internal audience.
The extra overhead may be a pain, but it’s relatively easy to solve by adding more computing power to the back end.
Integrating display with data
One of the cardinal rules of modern design is to split your project into at least three parts: data storage, decision making, and presentation. Such separations make it simpler to redesign any one part independently of the other two.
There are downsides, though, because separating the display from the data means that the application is constantly reprocessing the data to fit the current template for the display. Much of this is repeated if the template remains the same.
Lately, architects have been reworking data formats to make it easier for display code to process. The move to JSON data structures and JSON NoSQL databases is largely driven by the desire to deliver data in a format that is simpler for the browser to process. It’s not exactly mixing data with display code, but it’s moving them closer together.
Sign up for CIO Asia eNewsletters.