I know this is the least appealing title for a blog post that we’ve published in quite some time. However, it’s such an important topic and we’ve received many inquiries into the subject recently. As such, I think its time we discuss what’s happening in terms of web application development and software architecture so as to remove any confusion when we refer to the different methods of development in subsequent posts.
Web developers: I’m warning you in advance that this is a top-level review for marketers, end-users, and executives. We can debate terminology used or any other number of potential flavors of the options I’m presenting, but that would be outside the scope of this post. With that said, let’s start with a brief overview of the subject at hand.
A Summary
To begin, let’s define the two most popular approaches to developing web applications. One is the older, tried-and-true method of integrated web application development. By using the term “integrated”, I’m referring mostly to web frameworks such as popular LAMP stacks: CodeIgniter, Laravel, Symfony, in addition to other frameworks such as Rails, ASP.net, or similar. You may also hear these approaches defined by the term "monolithic". I understand that definition, though, it seems to be a bit too harsh a descriptor for a method we have used for many years, and the majority of web applications are still built on! Integrated systems were mainly developed via frameworks, such as those above, which aimed to make common programming tasks simple and easily repeatable.
On the other end of the spectrum is the newer philosophy of web development: the utilization of an API-Driven model. In this scenario, developers build applications that access data via a pipeline or an API (application programming interface) which in turn communicates with a backend database, as opposed to having the application make a direct connection to the database itself. The reasons for this? Well, we’ll dig into that in a bit.
To visualize this, I created this quick model which shows us how the integrated approach utilizes a series of tools that are, well, integrated, whereas the API-driven approach utilizes a variety of “nodes” connected to an API for data access.
This model articulates the differences between the two approaches in a fairly simplistic way: One architecture is more tightly connected, with different areas of the framework sharing a codebase. The other utilizes a more scalable approach, where “nodes” are independent codebases all sharing a common data access point. Let’s review each in detail.
The Old Way: Frameworks & Tight Integration
If you look back to the history of web development and specifically web applications, you can see that most applications were (and are) built out of “scripting” languages. As opposed to compiled programs (think of installable software on your computer), scripting languages compile and execute code each time that the script is initiated. This means that most web development applications are rendering pages on the fly, as opposed to from compiled code. While this is not a hard and fast rule, it is simply the more common approach. Scripting languages made it easy to iterate changes to your codebase, which in turn makes deployment easier – you simply push new scripts to the server and the next time a request is made, the new code is already handling the task.
The earliest examples of these scripts were those old-fashioned CGI scripts, typically written in Perl. You’d have a series of scripts in a “CGI-BIN” folder on your web server, and as warranted they would be called with inputs that produced outputs. This model was limited, however, and the creation of complex applications wasn’t so easy. Because of this, over time more focus was placed into languages such as PHP, ASP, and others. What these languages did was offer quick and reliable scripting that could be scaled to large applications. As the languages grew, more community-based frameworks evolved to make their usage even easier, such as Laravel or Symfony with PHP, which serve as coding frameworks aimed at enabling developers to quickly roll out new applications by providing a codebase that already handles the most typical scenarios.
How does all this tie together to the point of this article? Simply put, most web applications were built utilizing this methodology of having scripting languages or frameworks connecting to data sources for the manipulation and presentation of data. The problem is that as web applications scaled, issues existed in that they were built on top of one codebase and not in a more “modular” way. Take the most popular CMS platform today: WordPress. WordPress is built upon a single PHP-driven codebase. The application shares a common foundation between the content management tools and the front-end experience. For database access, the software directly connects to MySQL for gathering and manipulating data for presentation. This model puts all of the logic under one hood, which can prove challenging for future scaling. If you upgrade the core or even separate components, you will have a high likelihood that you will run into dependency issues – where another part of the software breaks. Think of it as a cobweb of interdependencies wherein the whole can’t function properly without all of the parts playing nicely with each other. As you can imagine, this isn’t a portrait of stability.
The New: API-Driven Connectivity
Given the issues with the above-integrated approach, developers sought ways to better separate components. This coincided with the advent of the mobile application revolution. Now, developers had more venues to develop applications for, yet each needed to share the same data. Furthermore, the idea of sharing data with outside developers to extend functionality and grow platforms started to gain steam. Enter the “API Generation”, or the era we are in now, where both open and closed APIs are powering most applications.
The theory behind API-driven development is that all of the data applications require is made available via an API, or a pipeline between data sources and applications. This shared data source enables developers to “decouple” their applications from data sources, thus giving more freedom and flexibility when it comes to choosing front-end implementation tactics or tools. An API can now power a web application, a series of mobile apps, OTT devices, smart TV’s, Watches, Alexa…. You name it.
With API’s becoming more flexible and easier to roll out, the development community started building more and more frameworks for front-end usage of these data pipelines. Libraries such as Angular, React, Vue.js, and Ember became popular as they allowed developers to build complex applications utilizing front-end technologies including Javascript. This brings about a series of advantages. First, it ensures the front-end is decoupled from the data source and backend management tools. Secondly, Javascript libraries put more of the front-end payload on the client, meaning that server scaling is less of an issue and performance can be improved, provided the client is capable of handling the task. And finally, these libraries allowed for a more cohesive experience for end users as web applications became more fluid in terms of user interfaces and experience. Overall, the new architecture is a win for developers and a win for end users. And, despite not seeing it that way due to higher price points for development, decoupling of components is a major win for management as well in that they are not only getting a more redundant solution but one in which individual components can be swapped or amended in the future without affecting other components.
Comparing the Architecture Methods
Choosing what works for you depends on a variety of elements. In an attempt to help you interpret your best architecture method, I put together a list of factors you should contemplate for each approach.
Integrated works best if:
- You plan on only architecting a solution for a single channel of distribution: the web. If you are building a web app that will never have a mobile application attached, then the integrated approach is a safe bet. Just note: this doesn’t mean you can’t have mobile web capabilities – it just is limiting you to the web and not application-based experiences.
- You do not plan on scaling to extreme levels. Integrated apps get gnarly when scaling. It isn’t impossible – in fact, we’ve been doing it for years. However, the new methodology makes scaling much easier, so if you plan on serving millions of requests per day or week you should probably consider the API-driven approach.
- You have no need to give outside access to data. If you have no business connections or outside partners who need data feeds, then the integrated approach may make sense for you.
- You need quick prototyping. If you have a short timeframe and need to show the success of an application fast, then this is a good way to build out a solution. However, be aware that in the future you may need to redevelop to scale or grow.
- You are budget sensitive. Integrated solutions require a smaller team and less moving parts, therefore are faster to develop and require smaller budgets.
- You don’t want to maintain the individual pieces. Remember, an API is a piece of software you will have to build and maintain – and so is each node that utilizes it.
On the flip side, consider API-Driven architecture if:
- You want to build out an application that will live for many years. Remember, individual “nodes” are always changeable, so you should rest assured that this approach will enable the overall architecture to live for quite some time.
- You plan to have alternative distribution channels. The biggest example I see is mobile applications – if you plan to have a mobile app in the future, you will need an API. In this case, it makes the most sense to start with this architecture from day one.
- You want to work with multiple frameworks to build out your different channels. API-Driven projects have a variety of tools required to make it work. Funny enough, your API may be built on top of an integrated platform such as a PHP framework! If you plan on building web applications utilizing Vue.js for example, mobile apps using native coding techniques and a customer portal utilizing Angular, (though, not sure why you’d want to use two different frameworks in that sense) you could.
- You want to make your data available to third-party applications. If you have partners or a business case to make your data accessible, you’ll need an API.
- On another note, a major benefit could be unloading tasks such as content management to companies that provide content as a service, such as Contentstack or other headless CMS providers.
Some Words of Caution
While the API-Driven philosophy is now not exactly new anymore, it is now becoming more and more relevant when discussing options for building web applications. One area of concern, however, is the noise the industry is putting out there in relation to less-than-proven frameworks. I’m always a fan of being conservative in terms of choosing frameworks on which to base your applications. Always do your homework so that you avoid getting locked into frameworks for core components that may not be in the picture for the long haul – trendy technologies are not always the best bet for a long-term application’s foundation. I like a mixture of conservative framework choices, such as Laravel or Lumen for API development, and then picking front-end libraries that are also proven over time. Vue.JS, in particular, is an appealing framework: lightweight, easy to work with and the future seems bright for the platform.
Keep in mind also, that the front-end frameworks are iterating themselves quickly. While frameworks that are integrated such as Laravel include front-end components to handle user experience, they are slower to evolve as those components are basically just utilizing HTML, CSS, and JS for display. However, platforms such as Vue.js, Angular and React are evolving as a software package on a regular basis which means investing heavily in them could result in higher maintenance costs as you upgrade them.
Finally, you need to put proper thought into the architecture and planning of each individual piece. As mentioned above, an API will need to be built on a framework such as Laravel to work. At some point, the API has to be coded utilizing a framework that allows for connection to a database or data source directly. This new methodology is actually a bit more of a development footprint in that you’ll be maintaining an API and the individual nodes through which users utilize your application.
Wrapping Up
There are still many legitimate approaches to software development, and each of the two approaches outlined in this post are defendable pathways to completing a web application project. The key to making a good decision is twofold: first, plan for your future considerations to the best of your ability. The idea of multi-channel distribution and scaling is a major factor in deciding what works for you. Secondly, regardless of the methodology chosen, work with a willing partner who can help you determine which approach is the most logical given your requirements. Making the wrong decision on something so integral to your digital operations is not something that you want to deal with, whether it be during development, after deployment or years down the line.
