June 5, 2019
If nothing makes a better morning than a coffee, then a technology stack jump-starts the future of a Web application. And just like with coffee, well-selected grains of a tech stack can either breathe life into a Web application or sour its development and later maintenance.
When determining the tech stack, a number of criteria have to be taken into account—each component within, and all of them combined, directly translates into the quality, performance, and usability of a Web app.
The choice of the technology stack also depends on the type of business: startups usually have limited budgets but heavily depend on the initial success of a Web app so they need reliable and battle-tested tech stacks. Large companies seeking to build robust and highly available Web applications need to invest in technologies that are powerful enough to efficiently handle big traffic.
As you can see, there’s lots to consider when choosing a technology stack for Web application development, so before explaining how to go about it, we first have to talk a bit about what’s what in the world of Web app development.
Buckle up, then, and let’s go for a ride.
The answer might seem obvious, but it’s important to understand some of the technicalities involved in the making of an app before moving on with our exploration.
A Web app is installed on a server and accessed over the Internet via a Web browser on a user’s device. To access the app, the user doesn’t have to download it to the device.
Each app’s infrastructure should include:
The function of a database is to search, filter, present, and sort the information in a Web application based on user requests sent via a Web browser. To further support user queries, a database can perform various calculations. Databases are the backbone of many online services, e.g., e-commerce websites or discussion boards.
Databases are divided into:
Caching system reduces server lag and relieves the database of heavy loads during peaks in traffic by serving previously used and accessed data. Without the caching system, Web apps are often sluggish and offer poor site performance.
A Web server receives, processes, and delivers user (i.e. a Web browser) requests in the form of an HTML message.
Most used Web servers:
Structurally, a Web application is made of the frontend and backend components. Let’s decompose them.
The frontend, aka the client-side, encompasses everything a user can see. The frontend makes the interaction with a Web application possible through the tangible presentation layer.
The HTML and CSS part of the frontend can be built with frameworks, which contain standardized code packages that speed up development and add functional components.
Popular frameworks for HTML and CSS are Bootstrap, Foundation, Stylus (for Node.js applications—more on that later), Semantic UI, and UI Kit.
The use of JS frameworks greatly speeds up the development process, while lightweight frameworks, such as Vue, are highly flexible and retain their high performance no matter the backend.
The backend, AKA the server-side, governs the logic behind how a website works. Essentially, the backend is responsible for the communication between the client-side, the server-side, and all the components within the backend.
The backend usually comprises server-side software and background processes. Yet, depending on the complexity and specificity of a Web application, the setup might be different—we’ll talk more about this in the next section.
Server-side software determines how the server, application, database, and other components in a Web application architecture communicate and work with each other.
A Web app code can be written raw or with the use of a backend framework, which streamlines the development process. Each programming language has a number of frameworks based on it. The most popular are:
|Ruby||Ruby on Rails||Hanami||Padrino|
Very often business logic created under the hood is heavy and needs a lot of time to process things. An application may slow down and, even worse–may be blocked, because current resources are actually reserved for some operation. When the user is ready for that kind of disadvantages, for example when some big file needs to be uploaded–okay, it’s not that bad. But what happens when somebody wants to send 1000 emails from the interface and it’s just a click of a button, but processing on the server takes minutes? This is exactly the perfect use case for background processes. It’s a very common practice that a part of the time consuming logic is moved to external workers, which will improve user experience and the application’s performance.
Combined, all of the components above are called a technology stack.
Now that we have the basic stuff out of the way, let’s dive a little bit deeper into our Web app decomposition.
The basic type of a Web application will have a single database and a single server on the backend and, of course, the presentation layer: the frontend.
This basic Web application setup, however, is usually used only in small and simple projects, preferably even only test projects.
Having a Web app running only on one Web server and with one database is a considerable risk for business owners. With one server, when it goes down, the Web app becomes unavailable. Therefore, this structure is not recommended as a core setup for a company Web application.
Developing solutions with a single point of failure might be the cause of many future headaches, which, as I'll promptly explain, can be easily avoided.
With two servers operational, there’s no single point of failure in case one of them crashes—the Web application will remain operational, with all requests redirected to a working Web server.
However, there’s still the single database to consider—if that database malfunctions, so will the Web application, regardless of two servers.
Thus, in this setup, the database should be installed on a separate machine rather than on one of the two servers. This allows for effortless horizontal scalability in the future, should the traffic increase. Also, with the database running on a separate machine, you’re increasing the safety of your data, adding another level of security for a possible attacker to go through before compromising your Web application.
With two separate Web servers, there’s also the performance aspect to consider—a two-fold increase in available resources.
This is pretty much a fail-proof architecture: ideal for large enterprises and companies where core business operations rely on the seamless availability of a Web application.
The database in this setup can be duplicated and installed on two separate machines or distributed across those two, or more machines. With the former structure, when one database crashes, the other takes over, maintaining availability and ensuring no information is lost. The latter structure is somewhat risky, for when one database machine with a portion of data fails, the information becomes unavailable to the users.
Equipped with load balancers, the Web servers will allocate workload and maintain high performance regardless of the traffic.
With a general understanding of what constitutes a Web application and what is the responsibility of each component in the tech stack, let’s slice up the meat of the matter.
Considering how many components are involved in the development of a Web application, one of the biggest determinators as to the tech stack necessary to build it is the size and complexity of the project.
Having a clear picture of what you want to develop will help you decide on the tech stack that brings the most benefits to the table.
In most cases, these are landing pages, with some interactivity, or basic online stores (with a small number of offered courses, services, etc.).
While they can be built using one of the widely available (and free) CMS platforms (such as WordPress) you can use a tech stack that combines the frontend and backend for a better performance, usability, safety and a more unique touch.
Choosing custom development over off-the-shelf CMS platforms means that any possible attack vectors for hackers or bugs, that might result in poor performance or usability, will be kept to a minimum, because the code is in the hands of professional devs. Security, user experience, and performance are the elements that can’t be ignored regardless of the size of the business. Quite on the contrary: the better the first impression of a product in its nascent stages, the higher the chances of its profitable future.
Web apps with many more features, such as full-fledged e-commerce stores or enterprise-grade applications.
Also, the architecture of a medium Web application will be more complex, since they have to handle large traffic efficiently while being highly available.
With built-in analytics, many custom features, and numerous third-party integrations.
These are international marketplaces, HR software, social networks, just to name a few. A technology stack for such complex Web applications is usually a high-calorie combo of different development technologies, programming languages, and custom solutions.
Technology stacks behind large apps have to be speedy, scalable, available, and maintainable. To meet these requirements, each component of the stack has to be carefully picked by the software development team.
If a Web application is going to do lots of real-time data processing, the bulk of operational responsibility will fall on the backend. Needless to say, the server-side has to be optimized to meet the demand.
Examples of Web apps with heavy data processing:
When determining the technology stack, and especially the backend language, the rule of thumb is that the more advanced and sophisticated the programming language, the higher the cost of the development.
Some software development companies employ business analysts, whose job is to help with project estimation and who try to find the best solutions within your budget. In order to develop an application suitable for your needs and the market, they may offer discovery workshops. These focus not only on the scope of the app, but also on the development process, user needs and design. So, after a couple of days, you receive a quite detailed estimation.
If you’re pressed for time, you might want to choose technology stacks that greatly facilitate code reuse and speed up the development process. Modern stacks not only use the same programming language across the whole ecosystem of a Web application but also have components that can be reused between the backend and frontend, with only slight modifications injected.
Ruby on Rails is also lauded as one of the fastest programming frameworks, allowing developers to build startup apps and MVPs with lightning speed.
Integrations and out-of-the-box solutions affect TTM, too. With technology stacks where many functionalities are readily available and integrations with third-party service providers and solutions are hassle-free, TTM drops considerably.
While complete security and invulnerability from hacker attacks are impossible these days, there are technologies and programming languages that are safer than others. If your Web application relies heavily on customer data, be sure to thoroughly analyze the security means implemented in the technology stack you’re considering.
Sophisticated authorization and authentication methods are of utmost importance. Also, the very fabric of the code has to leave no stray points of entry for attackers.
When developers are following security guidelines and best practices during development, the vulnerabilities and possible attack vectors hiding within the code can be kept to a minimum.
Scalability of a technology stack is crucial for businesses intending to grow in the future and meet the increased demand for their undisrupted availability.
That said, when picking a technology stack, check its horizontal and vertical scalability options.
Horizontal scalability is about the possibility to add next servers to the current one.
Vertical scalability is about adding more resources (CPU/RAM/DISK) to the current setup of a web server.
When deciding on a technology stack, be sure to implement solutions that are open source. They’re free of charge and are available for use with limitless modifications, as per project requirements. Picking open-source technologies ensures lower initial development costs as well as later maintenance fees.
According to Hackerrank, untested or broken code is the biggest bug in production. To save time otherwise needed for bug fixes, it’s important to include technologies where conducting testing is easy. Test automation framework Selenium, or apps such as Katalon or Cypress.io, are essential for a speedy delivery of quality Web apps, with the number of bugs kept to a minimum.
It’s also worth considering technologies propagating test-driven development (TDD). TDD technologies are especially useful when you have a Web app prototype with the correct structure of components and interactions defined clearly. Before writing the production code, TDD lets devs write tests that ensure errorless data flows in the app to be.
When dealing with obscure technologies, it may sometimes be tricky for a developer to find a solution to a problem. Trying to figure out how to make something work or identify a piece of code that is throwing errors can both delay the deployment date or the introduction of post-deployment modifications.
Look for technologies with good documentation and considerable developer community. The two combined ensure the likelihood of finding the necessary solution quickly. A vibrant community of developers and contributors might also be able to work out how to overcome an issue if the documentation lacks the solution.
Following technology trends is important, in order to know if there are any revolutionary changes in Web app development. Yet, they should never shape the tech stack for a Web application.
New and exciting technologies might be tempting, but before deciding on implementing them, cross-check their functionality and performance with the needs of your application. Why invest money in solutions that excite but don’t necessarily add value to your business? Make a thorough research first, and decide wisely on a tech stack that will match your business needs.
In the next section, we’ll show you a collection of popular tech stacks behind Web apps of known international brands, but treat them only as an insight rather than a direction your project should follow. It’s good to know what successful companies in your industry have running behind the scenes, but only if the setup matches your business context.
Do your research to know what’s what when asking questions relevant to your technology stack. Nevertheless, always consult with an experienced developer on what to choose to fit the needs and specificity of your company.
Below you’ll find the tech stacks behind internationally recognized Web apps that Stackshare was able to investigate into. We’re showing you only the major components. To grasp the complexity of the whole architecture of each stack, visit its respective link.Groupon—a worldwide e-commerce marketplace. Full stack here.
As I’ve already pointed out, a technology stack is only one part of a Web application. The other part is a team of experienced Web developers who will know how to squeeze out the best of each component within the tech stack and use the combination of those components to build a highly performant and available Web app with impeccable UX and usability that complements the setup. Even with a great toolset, inexperienced developers won’t utilize the full potential hidden within each tool. However, in the hands of skilled devs with a flair for building inspiring Web apps, a tested and proven technology stack is key to the successful development of Web applications.
Work with a team you can trust
Working with us guarantees shared knowledge of 90+ experts and starting your software development in weeks—not months. That means doing more business and less low-level work on your side.