Technology stacks like LAMP, MEAN, and MERN have been a boon to developer productivity. With just four components you have everything you need to develop web applications quickly and easily. And while these stacks do provide a robust framework out of the box, they are not without complexity, and aren’t always designed to scale. As a result, organizations often find themselves transitioning away from their V1 application built in a four part stack to a simpler configuration. Reducing complexity is a great way to improve stability, which, in turn, is a great way to reduce costs.
Here at HarperDB, we refer to this process of simplification as Collapsing The Stack. Fewer moving parts means less can go wrong, after all. In this article, we’ll outline challenges with the four-part stack and propose some alternatives that can save money, reduce complexity, and help solve some of the issues of performance at scale.
A Primer on Four-Part Stacks
Below are some popular four-part stacks and their (4) components:
MERN
- MongoDB
- Express
- React
- NodeJS
MEAN
- MongoDB
- Express
- Angular
- NodeJS
LAMP (edited, because it’s been a while, and Javier Lopez is right in the comments)
- Linux
- Apache
- MySQL
- PHP
With each of these stacks, you have a database (Mongo or MySQL), a client-side framework (Angular or React), a server-side framework (Express or Laravel), and a core language runtime (NodeJS or PHP). With these four parts, you can rapidly generate the UIs, APIs, and persistence layers of your application.
But Wait, There’s More To Consider! Like, A LOT!
As I mentioned in the introduction, these are easy solutions to understand, and easy to deploy. But there are some drawbacks that one should consider when planning for the future.
Performant applications, in the simplest terms, have to do two things: respond quickly enough to keep users happy, and be able to handle all the users they just made so happy. Four-part stacks involve two links that can hinder your application’s ability to meet these two objectives: the API call to your database, and a database that can only support a limited number of users with the provisioned resources.
Performant APIs, Happy Users
First, let’s take a look at the API call to your database, and see how we can simplify that process and make it more performant.
In the old days, we used things like stored procedures and user-defined functions to put business logic into the database server. This was considered by most people (other than DBAs) to be a Very Bad Idea, indeed. The way we accomplished it at HarperDB was to integrate the API server into the database itself, a feature we call Custom Functions. By using server-side JavaScript and core methods that eliminate the second hop from the API to the database, you reduce latency and make users happier, without relying on a standalone server-side framework like Express or Laravel. Basically, we integrated a pre-configured Fastify server into HarperDB and let you define your routes and handlers- no more dependencies, configuration, or command line configuration. Plus, happy users experiencing lower latency is always a win.
Keeping Users Happy At Scale
Next, let’s look at supporting all your happy users. Scale is a challenge for applications in a lot of ways, but the biggest hurdle is the cost of all that success. Distributing load is a challenging prospect, but lots of tooling has arisen to solve it like AWS lambdas and other “serverless functions”. But when it comes to traditional four-part stacks, you now have a lot of moving parts to duplicate in order to handle additional users. That doesn’t seem like much fun, and it’s not.
The main obstacle is the fact that distributing data is WAY harder than distributing applications. And unless you plan for it upfront, you’re most likely going to find that you’re sending all your users to a cluster of databases for which you keep having to increase resources, a concept we call vertical scaling. Vertical scaling follows an exponential cost curve- a fancy way of saying that 2GB of RAM costs more than twice what 1GB of RAM costs… not much more, but once you start to need multiple VCPUs, multiple cores, and 128GB of RAM to support your happy users, your CFO is going to be… less happy. I think we can all agree that unhappy CFOs are no fun at parties, or anywhere else.
Truly distributed applications scale horizontally. That is to say, if one application node costs $10, and supports 1,000 happy users, then you just keep adding nodes for every 1,000 users you need to keep happy. The challenge of the four part stack is that none of the usual databases are designed to scale like that. We built HarperDB to solve exactly that problem. Happy users don’t stay happy for very long if you make them wait, and it stinks when that problem only reveals itself once you’re actually starting to see lots of users.
The HAN Stack: As Happy As A Wookie At Home For Christmas
Application development isn’t JUST about keeping users happy. It’s also about keeping developers, DevOps, and CFOs happy. And staying performant as you grow without having to swap out your database or API framework is one of the easiest design decisions you can make now to stay successful down the road.
To that end, we call our efforts to make this whole process less stressful the HAN Stack.
You may have already guessed that the HAN stack stands for HarperDB, Angular, and Node.js. Angular is an obvious choice for building enterprise-based applications because of its extensive built-in functionalities and community support. Node.js is an incredibly versatile and user-friendly JavaScript runtime. And HarperDB consolidates the API and database, while being orders of magnitude more performant.
With applications and data deployed as one, you can focus more on your application logic and less on your architecture. We’re still big fans of old-school HarperDB stacks like the HERN stack. But with the introduction of Custom Functions, you no longer need to be weighed down by a four-part stack as you grow.
How is This Possible?
With Custom Functions, you can now define your own API endpoints within HarperDB. Your custom endpoints will interact directly with core operations, such as “insert”, “search_by_hash”, “update”, and more. This eliminates the second connection from your API to the database in favor of a direct connection to the data layer, which usually reduces round-trip API latency by around 50%. Imagine how many happy users you’ll have! Plus, you can host your compiled Angular UI as a static resource right inside Custom Functions, so you can actually build your entire application in one place. It’s an indisputable win-win.
With more traditional last-generation tech stacks, you would need to deploy and host your backend API code on additional servers, then have them call out to the database layer for database needs. As Jake Cohen, Director of IT & Operations at HarperDB, mentioned in his article, “HarperDB is collapsing the stack onto a single server, which eliminates virtually all network latency. This frees up headroom for achieving higher throughput from a single server. Capitalizing on HarperDB’s already powerful horizontal scalability, this means you can now distribute both your APIs and your database to the edge.”
Simple World, Simple Life
There are many benefits to a simplified tech stack, both for the developer and the organization as a whole. A stack like the HAN stack makes developers’ lives easier, creating the opportunity to utilize modern technologies while reducing the number of programming languages or frameworks that they have to work with. This also enhances collaboration, allowing more developers from diverse backgrounds to work together on the same project.
For the organization, the shorter the stack, the easier it is to adapt to crisis and evolve when needed. Most modern infrastructures are moving towards a “collapse the stack” model, and this allows the organization to be agile while reducing costs and latency at the same time. The leaner your mission-critical stack, the lower your risk exposure. With the right technologies in place, you'll benefit from both a cost and functionality perspective. Simplicity is key, and that’s why HarperDB’s tagline has been “Simplicity without Sacrifice” from the beginning.
Top comments (8)
Wait LAMP is for Laravel, Angular, MySQL, PHP? that is totally wrong.
LAMP stands for Linux, Apache, MySQL, PHP that means LAMP, so technically that is MySQL + PHP, since Linux is the OS and Apache is only the server.
Same opinion here. LAMP stacks typically consist of the Linux operating system, the Apache HTTP Server, the MySQL relational database management system, and the PHP programming language.
That looks like a "modern monolith" to me 😁 Maybe showcase with a NH (Next/Harper) stack would be nice!
Your definition of LAMP is a bit different en.wikipedia.org/wiki/LAMP_(softwa...
Looks like you’ve chosen Angular just to have a vowel in the middle 😄 just kidding, but as a matter of fact, I guess nothing stops one from using Vue for instance. Or does it?
why not JAMSTACK
Checkout T3 stack