Choosing a technology stack for a digital product in 2024

The technology stack for launching a new product in a company is usually selected based on what the team has worked with before and how much developments it already has.

However, if you are free from the need to use any legacy (recruiting a new team or looking for current technologies to learn), then this article will help you choose what to use to launch a product or service.

My name is Evgeniy Korneev and I will try to give a comprehensive assessment in terms of technology maturity, popularity, availability of specialists and vacancies, as well as for what purposes it is better to use a specific stack.

Backend as a basis

Node.js backends (Express, Koa, Nest, etc.)

Let's start with the hottest technologies of the moment. The number of projects running on Node.js is now growing very actively. This was facilitated both by the growth of the ecosystem and the attractiveness of using a single language on the client and server. Previously, Node.js in large projects was used only for individual services – backends for chats, notifications, receiving quick-readable data. However, thanks to the development of tools and the JavaScript / TypeScript community, it has become quite convenient to use Node.js as the main technology for large web projects.

MongoDB has become the most popular database paired with JS frameworks. The fact is that Node.js processes requests in a single thread. Accordingly, it is vital for the application to think as little as possible and receive data as quickly as possible so as not to block requests from other users. The ability to store unnormalized JSON data and quickly read it fits perfectly with this requirement. However, at some point, the so-called MERN stacks (Mongo-Express-React-Node) became so popular that they were used in places where they were clearly not needed, which is why companies could face growing pains.

Nowadays, vacancies with the Node.js + PostgreSQL stack are increasingly appearing. The fact is that until recently, libraries for working with SQL databases in the JS ecosystem were not very mature compared to other languages ​​and stacks. But now several promising ORM libraries have appeared: Prisma, Sequelize and others. And this is quite important for the development of the JS stack as a tool for not only cheap, but also fast development. PostgreSQL is a favorite database of developers for a reason – it is a universal Production-Deady solution that covers performance and data consistency requirements.

In our MyGig.ru Node.js is the core stack for the entire platform. For me, as a person who has been writing applications in Ruby on Rails and Python + Django for many years, some of the problems solved by developers seem too low-level – quite often abstractions and tools are invented where in more mature frameworks people use ready-made solutions. This is why I think Node.js stacks are more suitable for single-tasking microservices than for large applications with complex business logic.

I admit that the popularity of Node.js stacks has led to rapid development of tools and methodologies. So, for large applications you can already use Nest.js, which offers a clear structure, philosophy and architectural patterns that take into account the features of the technology. All this saves developers from having to reinvent the wheel and makes it easier to introduce new frames.

If we talk directly about programming languages, the emergence of TypeScript contributed to the growth in popularity of the entire stack, but I do not consider the need to use it a dogma. JavaScript is developing quite well on its own, and not in all products and teams the lack of strong typing will negatively affect development.

Python + Django/Flask/FastAPI

This stack experienced a rebirth with the popularization of professions in the field of Data Science. The presence of many popular libraries for working with data and machine learning (Pandas, Numpy, Keras and TensorFlow) has caused a desire to reduce the number of technologies used in projects. However, popularity Python initially based on the fact that it is a fairly easy language to learn, so it is used not only in Data Science and web development – for example, it is increasingly chosen as the first programming language in schools and universities.

Let's look at the most popular Python frameworks.

1. Django. This is a whole combine that includes out of the box almost everything that might be needed for a modern web backend: from authorization and authentication to ORM and an automatically generated CMS. Combined with the lack of need to write abstractions, this allows small teams to launch projects in the shortest possible time. I can only characterize my experience with taking projects from scratch to large production using Django as positive. However, there are also some growing pains: Django is focused on developing monoliths, which gives a quick start and is great for small and medium-sized projects. For large systems, over time, Django may seem like a burden (but the project still has to grow to that size).

2. Flask. A simple framework that is perfect for small microservices. For example, it is often used to create APIs for querying ML models.

3. FastAPI. A fairly young framework for API development, which quickly gained popularity in the Python community due to the fact that it implements many modern solutions both in terms of web technologies (GraphQL, WebSocket) and in terms of taking advantage of the latest versions of Python ( asynchronous code, typing). An excellent choice for both microservices and larger API-first projects.

Considering that Python itself is actively used for working with data, there are a huge number of libraries for working with various databases. Choose the one that best suits your tasks – you are likely to find both a low-level driver and a convenient ORM.

If we talk about the shortcomings, then most often you can hear about the specifics of the Python interpreter, in particular GIL (Global Interpreter Lock), which does not allow efficient implementation of multithreading in some tasks (which, however, is partly solvable).

Python supports the asynchronous approach, but is not as efficient in this as Node.js. But the presence of such a feature cannot be considered a minus, because without changing the language you can optimize your I/O-intensive tasks.

The maturity of tools for web development, the popularity of Python in AI and Data Science, the ease of learning and the availability of specialists – all this makes Python stacks an excellent choice for starting a project of any scale.

Ruby on Rails

I love Ruby with all my heart and have spent most of my career as a developer in it. In the 2010s, Rails was a very popular choice due to the speed of development and its philosophy, which produced many quality developers. We are talking about the Convention over Configuration approach, which reduces the number of technological decisions made by the developer, allowing him to concentrate more on the business problem rather than on its implementation. This, in turn, has become the main theme for critics of Rails: the feeling that everything works by some kind of magic invisible to the eye reduces the possibility of control and complicates debugging.

Ruby on Rails has had a huge impact on all web development. Many approaches were copied (and are still being copied) to other technological bases. The popularity of tests in web development, the use of MVC-like patterns, metaprogramming, ActiveRecord ORM and many other things that make development easier in many popular web frameworks have been developed thanks to Rails and its effectiveness as a tool.

Despite all my love for Ruby, it should be noted that the popularity of asynchronous approaches and microservice architectures has pushed this stack into the background, which has made it more difficult to find specialists. That is why the last time I led the development of a product from scratch, I chose the Python stack – at that time it was so easy to recruit a team.

ASP.NET Core and Java Spring Boot

I will unite the kings of the large enterprise into one section. Traditionally, it was believed that the .NET and Java stacks develop more conservatively, so by choosing the same solutions in JS and Python you can be on the cutting edge of modern development trends.

However, this conservatism and the patronage of large corporations (Microsoft and VMWare) make these technologies an excellent choice where the reliability and performance of the product is more important than the speed of development and innovation: in corporate systems, banking fintech, etc.

And ASP.NET and Spring Boot has a huge ecosystem that allows you to flexibly choose an architecture and at the same time use ready-made developments, but the learning curve for both technologies is much steeper than for the more popular JS and Python.

Go and Rust

For the most part, both languages ​​are used for the same purposes – creating high-performance microservices with high requirements for computational speed and competitiveness. Go is a little simpler, Rust is a little more complex, but more flexible. Go has a much broader ecosystem for web development now, but Rust is also gaining popularity in this regard.

You should use Go or Rust as the main technology at the start of a project only if the performance of your solution is one of the unique selling points of the product (or if your goal is to study the ecosystem of these technologies and you do pet project). The lack of user-friendly and mature tools can significantly reduce the speed of bringing a product to market.

However, the phrase “rewrite in Go” is heard very often in development teams as projects grow: thanks to a neat microservice approach, fast compiling code is the ultimate tool for high productivity. This is especially necessary where a lot of calculations or high competition are required: generating/reading large amounts of data, working with data streams, subsystems loaded with requests.

As your product's audience and complexity grow, it's likely you'll start adding Go or Rust developers to your team, because these compiled languages ​​are often great additions to stacks with more mature web ecosystems.

Elixir + Phoenix: a little exotic

You may have heard about this functional language that runs on top of Erlang's BEAM virtual machine. In fact, Elixir is my latest love. Designed to easily build fault-tolerant backends running millions of concurrent requests, it delivers Go-like performance and Ruby-like development fun.

You may have heard about this functional language that runs on top of Erlang's BEAM virtual machine. In fact, Elixir is my latest love. Designed to easily build fault-tolerant backends running millions of concurrent requests, it delivers Go-like performance and Ruby-like development fun.

Pure functions, elegant designs, data immutability, pattern matching – all this allows you to take a different look at development in general, so I advise every developer to dig into Elixir at least a little. It is not very suitable as a first programming language, but it can be a good start for experienced developers.

Thanks to attracting a large number of fans of Ruby and Rails, Elixir now has a fairly extensive ecosystem of libraries – and this is not counting all the advantages of Erlang OTP available out of the box: supervisors, web server, tools for managing threads and state, telemetry, built-in key-value storage and even a transactional database. All this allows you to remove a lot of components from your stack.

Phoenix, in turn, is the most popular web framework for Elixir, which has absorbed many of the successful practices of large frameworks and transferred all this to the functional paradigm. All modern approaches can be easily implemented here: GraphQL in real time, CQRS, Event Sourcing, frontend without JavaScript via websockets, distributed microservices – all this fits almost perfectly into this stack.

Discord, WhatsApp, Slack, Bleacher Report, Pinterest are just a few of the companies that have publicly talked about how switching to Elixir has significantly reduced costs and allowed them to offer unique features to their customers.

For most startups, the main argument against will be the small number of developers on the market and their relative high cost, but if you are creating solutions for a large number of users interacting with your application in real time, and at the same time want to quickly bring it to market, pay attention to Elixir. This is a good point for job seekers: it seems that the demand for good Elixir developers exceeds the supply at the moment.

Outside of brackets: Serverless

Speaking about current backend development, one cannot fail to mention the growing popularity of the serverless approach. Its main advantage is savings on infrastructure, because you pay the cloud provider only for function calls and their operating time, which allows the company to spend as much money as the actual computing power was used (rather than renting instances on an ongoing basis).

In serveless, you can implement a REST API or GraphQL, create event-triggered microservices, background workers, etc. The range of applications is quite wide, as is the choice of supported programming languages: most cloud providers allow you to write serverless functions in Node.js, Python, Go and Java.

Many companies in a variety of industries talk about how they are reducing costs and making it easier to scale with serverless solutions. In my experience, serverless functions work well as the main backend for simple applications, such as various chatbots, as well as microservices or background workers in more complex projects.

Client part: web frontend and mobile applications

There is also something to think about on the client side. If we talk about web clients, then one of the simplest options is the JAMStack approach (JS + API + Markup). It involves the preliminary generation of static html pages based on data obtained from the API and html templates. This makes such sites super-fast, because no calculations are required on the server at the time of the request – simply returning a ready-made HTML page. However, this is more suitable for corporate websites, landing pages and simple e-commerce projects.

With the development of JS frameworks, the SPA (Single Page Application) approach has become very popular, but its thoughtless use leads to large code bloat (and sometimes to the leveling of advantages). But SPAs are still good for applications that require greater interactivity during a long user session: complex forms, editable tables, complex personal accounts.

Nowadays, a hybrid SSR + SPA approach is often encountered, when initially the page for the browser is rendered on the server, and the reactive part occurs on the client. This allows the end user to quickly get the image without losing the responsiveness of the application. There is also a belief that search engines will love your site more in this case.

If we talk about specific frameworks, then there is a clear leader in React (as well as Next.js as an SSR implementation and Gatsby for JAMStack) and a couple of constantly catching up ones: Vue.js and Angular. If you need a mature, proven stack, I will choose React simply based on the huge number of developers in the market and the rich selection of ready-made solutions in the ecosystem.

Among the interesting new technologies, I would like to mention Svelte and its SSR framework SvelteKit. It is quickly gaining popularity due to its ease of use with no compromises in terms of speed and size of the final JS build. If you want to be on the cutting edge, I would recommend looking in his direction: judging by the reviews of all my friends frontendersDevelopers really like Svelte a lot, which is a good sign of a long-lived framework.

I'll tell you about the exotic approach that I use in my personal pet projects. We're talking about frontend without JS: Blazor from ASP.NET, Phoenix Live View on Elixir and Hotwire from Ruby on Rails. All three solutions propose to abandon the bold separate application for the frontend, and instead use Server Side Rendering with the implementation of reactivity through the backend using websockets. Each of them does it differently, but overall it's an interesting concept for solo developers and small teams: no JS developers and unnecessary components in the stack and pipelines are needed. The main disadvantage is that this approach does not scale well to other types of clients (for example, mobile applications).

Speaking of mobile applications. For most modern products, having a web version is not enough. Let us highlight modern approaches for mobile applications.

1. Using PWA (Progressive Web App). Essentially, this is reusing the web version as a mobile application. Modern PWAs can support offline functionality and minimal mobile platform features such as support for push notifications. This is the most cost-effective way to release an app to stores, but also the most limited in terms of functionality and performance.

2. Writing native applications in Swift and Kotlin. The most expensive option, if only because you need to have two teams on staff that make the same product for different platforms. However, this is the best approach in terms of freedom to implement any functionality on the devices themselves if you need to work with the camera, geolocation, On-device ML and other functions that are provided by the operating system SDK.

3. Cross-platform frameworks. Here the choice is between React.Native and Flutter. The former is attractive because it can be used by your front-end developers, while the latter is attractive because it is more flexible and performant. In my opinion, this approach is the optimal solution for most products.

4. No-code. Another simple and cheap option for simple applications. Most no-code solutions for creating mobile applications have Rest or GraphQL connectors, so they may be suitable for MVP and prototyping.

Results

Typically, such articles end with phrases like “choose what suits you.” And this, of course, is correct, but I still always want to listen to the author’s subjective opinion. So now I will express my opinion.

If we look at the developer market and the development of ecosystems right now, then for most new products I would choose a combination of Python (Django/FastAPI) for backends, React with Next.js for the web frontend and Flutter for mobile.

And then act on the requirements. If the application involves active real-time interaction with the user, we change Python to Node.js, Java or even Elixir. We need heavy computing and high performance – look at Go/Rust or ASP.NET. Need to make it cheaper? Choose PWA or React.Native to save money on your mobile team. And if we need to increase the speed of bringing a product to market, then we pay attention to Django or Rails.