So, you’re working for a tech company that is developing a new promising project. You’ve just clarified the business requirements and now the crucial moment is fast approaching: the choice of technology stack your awesome team will use. A project’s internal stakeholder groups (owners, managers, developers) usually have different ideas about the importance of choosing the right stack. A perfect solution should satisfy as many needs as possible within a group, but the only way to find such a solution is always full of unknowns and surprises.
Firstly, you want to zero in on the target. Remember, you don’t have a time machine to go back and change everything if your solution becomes unmanageable after a half year of development. Making strong arguments allows you to influence changes, but a lingering change is a waste of your clients time and money as well as your team.
Your team should be content. After all, a happy team is a productive team. Another interesting point to consider is that some developers can enjoy rewriting their project from scratch. If the situation is that you’re dealing with a legacy project, sudden global architectural changes can be a signal of a poorly performed initial analysis phase.
This article from the custom software development series is intended to be used as a collection of guidelines that every web developer or architect should be aware of. Its content is related exclusively to the high-level architecture of websites. At this point we’re not going to talk about the consequences of using microservices or which database vendor to choose.
Back in the 2000s, many websites on the market were being created using the very limited set of technologies. The world was simply not as advanced as it is now.
In the 2010s, the situation changed dramatically when technologies became ready to bring the best user experience to the browser. Along with the rapid increase in the number of software engineers around the world, it caused exponential growth in the number of frameworks, architectures and standards. As a consequence, it’s not easy to find out which thing is really worth adopting and learning due to the phenomenon of “hyping” and marketing wars, but what is especially clearly visible in the front-end world.
Some seasoned developers have a strong unwillingness to adapt for a quickly changing environment continuing to use tools they mastered years ago. For some engineering domains it’s fine, but web development has a special place among them. Modern websites must meet a criteria of requirements to be successful. This includes, time to market, attractive interface, search engine optimization, accessibility, scalability and a lot of other features. The sad news is that there isn’t a single tool to handle it all. If it existed, it could be overkill for many projects. The good news is that competition born by the diversity of tools makes some of them stand out.
The law of the instrument states: “if all you have is a hammer, everything looks like a nail”. Many IT companies or individuals have chosen this strategy. They found a way to use framework “X” to create a landing page, a real-time dashboard or send a squirrel to the Moon. Sometimes it works, but most often brings problems when a product is scaled up.
In actuality, while the list of proposed solutions to different problems is almost infinite, some versions of modern apps have a lot in common. In the next sections we’re going to categorize and divide websites into several groups to find the most suitable solutions for them.
There isn't a strict definition that dictates how we categorize web projects into specific groups. However, the lines between them often become blurred. This is largely due to the fact that any website can include an arbitrary set of features. Our division will be based on the ease of applying certain technologies to a specific group so please pay attention.
Let it be a website in which content changes rarely and is managed by the site owner and the customers who can only view it. The core values such as quality content and incredible visual experiences allow you or your business to promote itself.
Examples of such websites include:
In most cases, static websites don’t require a backing CMS. A markup and content can be stored in the same place and served by a CDN provider. You’ll need the help of a web designer and a front-end developer to build it from scratch.
However, you should strongly consider using a page builder if your website doesn’t have something very special. By special we mean having complex animations, page transitions and built-in interactivity. Visit Awwwards if you want to see beautiful examples of sites with the unique designs. If visual exceling among competitors is not the primary goal of your business, page builders like Google Sites, Carrd or more advanced tools like Wix, WebFlow might be a great choice as well.
Don’t just listen to people who may say that you don’t need building tools to create a static website. Modern websites should have decent browser support and be developed as quickly as possible with the minimum number of kilobytes in output. Tools such as HTML template engines, CSS preprocessors, JS bundlers can help you with that. Luckily, extra effort isn’t needed to configure all these tools living in the era of static site generators — programs that take templates and a markup as an input, and produce static pages in output. To better understand what we’re talking about, check out the list of the most popular generators. For typical websites, the choice often depends on a developer's preferences. For example, Gatsby is a perfect choice for those that are familiar with React. Hugo is known as one of the fastest tools that is able to generate a page in less than 1ms. Jekyll can even generate a site from a plain text.
Hosting a static website is usually simple. You need to upload static assets to a hosting provider either manually or using the continuous integration pipeline (many providers have an integration with GitHub and similar version control repository hosting services). The hosting strategies are divided into two groups, described below.
Services like AWS Amplify, Google Firebase, Azure Static Web Apps are parts of cloud giants and they provide the possibility of building deep integrations with the rest of their services. For example, using Amplify (which is actually a combination of S3 and CloudFront under the hood), AWS Cognito can further be included to add an authentication on the website. Despite being extremely configurable, sometimes they might be overkill in relation to the tools that are allocated to the second group.
The second group is about complete automatization. Tools like Netlify and Vercel allow you to develop, preview and publish content without a single line of configuration. They are probably built on top of big cloud providers, but hide all the complexity from the developer. As a result, you have a perfectly optimized development and deployment process. Nothing is ideal, first of all, you’re limited with the capabilities of a platform, so you should plan beforehand if a solution such as this suits you. Second, the monthly subscription fees for using these tools can be costly at scale.
In contrast to custom sites, page builders often handle hosting by themselves. All you have to do is press the “Publish” button and your website will be immediately available for all users from around the globe.
Let it be a website that has some kind of CMS under the hood, where the content changes are immediately available for your customers. Another distinguishing primary feature is a user identity. Most dynamic websites allow their customers to perform actions on their behalf, for example “leave a comment”, “buy a product”, “post an article”. Examples of such websites may include:
Just like static websites, each type of dynamic website can be built using various methods. Let’s focus on the most popular types: blogs and ecommerce websites.
Blogs are probably the most frequent websites on the internet. That’s why there are countless platforms that make it super easy to manage content and display it to your customers in the most performant way. Tools like Wordpress, Squarespace, Wix have a long history and almost every web developer has heard about them or used one of them at least once in his life. In the past few years, people have started calling them "Traditional CMS’s" because there’s an alternative way to create dynamic websites called “Headless CMS’s”.
A headless CMS is a service that allows your business to manage the content in the similar way traditional CMS, but instead of rendering it into HTML and exposing it to your customers, it provides an API which can be consumed by your custom front-end applications. You can think of traditional CMS as a monolithic application where customization is limited by the platform's capabilities. A headless CMS gives you a REST or GraphQl API, so you can build multiple applications that use the same data (web, mobile app) using the framework of your choice. Check out the list of the most popular headless CMS. An interesting point is that even WordPress can be used as a headless CMS because it has a public REST API.
Remember, most platforms can be either open source or proprietary. By using an open source platform you may have to manage the infrastructure yourself keeping security and scalability in mind. Using a proprietary solution is usually much easier and includes a variety of subscription plans to suit different sized businesses.
The last option is to create a CMS from scratch. It gives your business a complete customization of the back end, but in most cases it’s unnecessary work that may be rejected in favor of either traditional or headless CMS.
It’s important to understand the process of building a front-end application while using a headless CMS. It’s crucial for SEO that your site’s markup should be either static or generated on the server side at runtime. To achieve this, you have two options.
The first one is a server side rendering (SSR). This implies the usage of a web server and a template engine. For example, Next.js (React) and Nuxt.js (Vue) are the most popular choices that support SSR because they allow you to write front-end code using modern stack familiar to many developers. You can further deploy your Next.js application to Vercel or any cloud service (e.g. AWS) that has a Node.js runtime as a monolithic server or as a set of cloud functions, each responsible for rendering a single page.
The second one is static site generation (SSG). You may ask: “how is it possible to build a dynamic website using a static site generator?” It's a very interesting and non-intuitive approach, the core idea of which is that every time the content of a website changes, the static assets should rebuild. It might seem odd and inefficient, but this approach is gaining popularity every day. For example, Smashing Magazine migrated from WordPress to Jamstack (this term is described in the next section). They use Preact, Hugo and Netlify CMS and serve all their pages via CDN. The proper SSG configuration includes integration of a CMS system with your Git repository to manage content and a CI service that triggers a build every time the content changes. Luckily, many headless CMS systems handle it for you while tools like Gatsby Cloud perform selective builds, so the fresh version of your site will be available in seconds after the content has changed. There's a nice book called Modern Web Development on the Jamstack that describes details of SSG without reference to a specific tool.
And now, a few words about Jamstack
It can be thought as an opposite of using a LAMP stack with all its infrastructure management burden, or WordPress in which the front end, back office and database is a one huge monolith. Using Jamstack you’re able to satisfy all the needs of your development team, owners and customers.
The number of e-commerce websites has grown disproportionately quickly. For example, Shopify handles over 1,000,000 businesses with more than 500,000 active stores. Considering external statistics, the overall number of e-commerce websites can be about 10,000,000. It simply wouldn’t be possible to create all of them by writing the back-end and front-end parts from scratch.
Many popular platforms consist of multiple subsystems: a store website itself, a back office (a CMS usually combined with an administrative panel) a POS application, sales channels and injectable widgets to extend existing websites with the e-commerce capabilities. Today, there are many ways to create a successful e-commerce store.
The first option is to use a dedicated platform that automates the creation of both a website and its backing office. Among the most popular: WooCommerce, Magento, BigCommerce, Shopify, PrestaShop, OpenCart. There’s no wrong choice as hundreds of thousands of merchants have built successful businesses using all of these platforms. You may want to choose a proprietary platform like Shopify if you don’t want to bother with infrastructure, deployments, security and other aspects that they handle for you. In contrast, an open-source platform like WooCommerce is your choice if you want more customization and control over infrastructure. Remember that almost all e-commerce platforms have an idea of a “plugin store”, so you can always extend the capabilities of your store by installing a third-party plugin or creating your own. We recommend searching for a comparison table of e-commerce platforms if you’re confused by the choice.
In the previous “Blog” section above we described the definition of a Headless CMS. The same applies for the e-commerce domain. Many platforms combine both traditional and headless methods of store management. Using REST API or GraphQl allows you to create a multichannel store, meaning you can manage products in a single place but sell them everywhere: on your primary website, on a site of your business partner, in mobile apps, games, social networks. So, if you know that your business eventually expands, consider using a platform that combines traditional and headless approaches preventing yourself from further migration between platforms.
The second option is building a custom e-commerce website. It’s an option for the businesses who reached the highest point offered by a platform, touched their limits and want to scale their product even more. While this may be the only possible solution for a very small percentage of stores, it is completely unsuitable for most: it won’t be easy to develop a full-featured e-commerce store from scratch, so consider using tools created by hundreds of professionals especially for you.
As a bonus, in specific cases where you don’t need a full-featured e-commerce platform, but rather want to just sell something on your existing website, consider an integration with a dedicated third-party service like Snipcart. It allows you to bring the shopping experience to any website (static, dynamic, single-page) with a few lines of code. It’s like a headless platform, but easier to use and more developer friendly because the API calls the store and nice-looking widgets are already implemented for you.
We’re not going to dive deeply into these types of websites. The recommendations proposed above can be applied for them as well. You should either use a dedicated platform if it satisfies your current and future needs, or develop a part or a whole solution by yourself. Just remember that these sites, like every public site used by a big number of users, should be static or server-rendered, have decent performance, and have a UX that is familiar to your customers.
Finally, the section we've been waiting for. It is interesting because the kinds of web applications are only limited by the human imagination. Among them:
The distinguishing features of this type of websites are:
Once you’re sure that the website you are about to build falls under the web applications category, it's time to choose a suitable programming language, frameworks, and infrastructure. Let’s go through this step-by-step assuming that the product we’d like to build is a single-page application (means it uses only client-side rendering) that communicates with the external APIs developed by you or other companies.
We’re not going to discuss the pros and cons of every possible back-end language. Choose whatever your team is experienced with. You can create awesome software using PHP, Java, Node.js, Python, Go and many other languages. All of them are perfectly suited for web development. The general recommendation can be the same as for the front end: try not to experiment with unsuitable technologies. You likely don’t need a server in C++ or Rust to build a microservice that reads data from a database and puts it to the user.
There are only three front-end frameworks that we recommend to use for commercial purposes. React, Vue and Angular, that have held leadership positions for many years and aren’t going to give way to other frameworks (sorry, Svelte). Pick one of them depending on your team experience because they are equally capable and powerful enough to create an app of any complexity.
Remember that Vue and especially React are not full-featured frameworks, as compared to Angular. This means that your team needs to agree on the application architecture and install every necessary companion library before development can start. On the other hand, Angular is strongly opinionated about how exactly the code should be structured and how the modules within the system interact.
Depending on the programming language of your choice, pick a framework with a worthy history and a large community. The bigger community is, the more answers for common questions you may be able to find. For example, Laravel, Spring, Nest and Django are the most famous representatives of their languages.
This section can be expanded into its own blog post because of the diversity of possible solutions. Depending on the application domain, size and complexity of an app, the infrastructure setting may vary from self-hosted back end on Netlify Functions to PaaS like Heroku or the advanced cloud solution on AWS.
If your company is experienced working with a specific big cloud provider, then you may possibly want to reuse it for most projects. For example, with AWS you can build infrastructure of any complexity. Initially, it may take time, but at scale working in a similar environment will bring you results in the form of quicker setups of every new project.
With regard to the front end, setting up a nimble CI/CD pipeline with preview deployments, incremental builds, distributing assets over CDN with multiple levels of cache and other advanced features is difficult to achieve with raw AWS or similar services. It would be wise to use dedicated tools like Netlify and Gatsby Cloud to empower your front-end capabilities, in order to make its development convenient and its performance output workable. Here, the only drawback is the price of such tools which is usually higher than using a cloud provider.
Many typical websites and web apps have common parts. Authentication, search, payments, forms, analytics, databases. Sometimes, it may be wiser to not spend development time on implementing this functionality from scratch, but rather use third-party services. Examples of such services include Algolia for search, Snipcart for a shopping cart, Auth0 for authentication and user management.
In fact, the choice is not obvious. Flipping through Twitter discussions and listening to experienced architects, it turns out that using third-party services or implementing custom solutions depends on many factors and not every team wants to invest their time to integrate these services to their apps:
However, it’s hard not to notice that more and more popular websites are migrating to Jamstack using external third-party services in order to bring a smoother experience to their customers. One day it will eventually become the standard for creating software.
Building web applications is not rocket science, but in a fast changing world it requires an in-depth understanding of what is required by the market and what is trending to reach success among countless competitors.
We covered a lot of typical use cases and their optimal solutions in 2020. The world is confidently moving to decoupled architectures where the front end is aware only of the public API of services it uses, and the services themselves are either powered by third parties or created by your own team using the most suitable technologies.
Axon’ software developers have years of experience by working with almost every application type mentioned in the article with a special focus on complex solutions such as SaaS platforms and B2B apps.
We will help you to choose the right technical stack of your future software solution. Every project that is created by us undergoes a technical evaluation where all of our experts compare requirements, time and budget to choose the perfect stack to suit all of your business needs.
In the next blog post we are going to tell you about one of our latest case study - impressive web application for the renewables and environment company. Stay tuned!