The differences between monolithic and decoupled no-code tools

In the world of no-code development, we have witnessed a significant shift from monolithic to decoupled solutions. As businesses grow and adapt to the ever-changing digital landscape, the need for scalable, flexible, and efficient tools becomes increasingly important.

In this article, we'll discuss the differences between monolithic and decoupled no-code solutions, focusing on the frontend and backend decoupling, and explore the advantages and disadvantages of each approach.

1 - Monolithic tools

Monolithic no-code platforms, like Bubble or Betty Blocks, bundle all frontend and backend components (client-facing app, backend server and database) together in a single package. This all-in-one approach allows developers to build and learn quickly, as they only need to familiarize themselves with one tool. Additionally, there's no need to worry about connecting various components, as everything is integrated within the platform.

‍

‍

This is ideal to quickly snap together a minimum viable product, but lends to some limitations.

‍

It's hard to use existing backends or databases.

If you’re a company with some legacy data, you might probably have an existing backend stack or a database with thousands or millions of records. And sadly, with monolithic no-code tools, you’ll need to re-export this data back to their internal backend, rather than plugin yours with it (it's true that you plug your data with API connectors, but the experience won't be as smooth as the data won't be considered as first-party).

This might cause issues as migrating data isn’t cheap nor easy, and also time-intensive. Data could be corrupted or lost in the process, which is always bad news.

You could also duplicate the data in the new no-code tool, but having to maintain 2 databases and keep them in sync is a hard job to do too, and will double your infrastructure costs.

‍

Most monolithic tools are black boxes.

These no-code tools are all-in-one blackboxes making it easy for users new to no-code to build their first app. But, by abstracting (sometimes a bit too much) web standards, like SQL databases, REST API calls or HTML/CSS design, they make it hard to understand what’s actually happening under the hood.

This can be a strength if you’re starting afresh and don’t care about these, but for existing companies with technical teams, that can hinder their comprehension of the app when building, debugging, or integrating with their current tools.

‍

It’ll be hard to scale your app.

Indeed, let’s say your app is having lots of traction (well done for that by the way 👏), and millions of users are now connected to it monthly. That’s where things start to get tricky.

Users complain that your app is sluggish, taking time to load or display data to their screen. On top of it, your monthly costs are skyrocketing, meaning your business viability is at stake.

Two solutions are available to you:

• You rework your app to optimize it
• You upgrade to a bigger plan on your no-code tool to handle the charge

Both are doable, but will require either lots of time or money.

That’s the issue with monolithic no-code tools: it’s really hard to pinpoint the exact thing making your app slow, hence, making it hard to optimize and charging you more money than expected.

‍

All of these problems are why we switched to the Web 2.0 in the 2000’s. Websites were becoming more and more interactive (known as web applications), so costs and complexity skyrocketed.

To solve this, developers switched from building monolithic apps using frameworks like Rails or Django to a backend and frontend decoupling that we know today (made possible by the creation of JavaScript frameworks like Angular, React or Vue). This permitted to optimize either the backend or frontend code, meaning more granularity in how you optimize your app.

In the end, no-code tools are following the same trend by decoupling frontends and backends. Let’s see how they differ from monolithic tools.

‍

2 - Frontend tools

Frontend tools, like WeWeb, focus on the user interface and experience. These tools deal with elements visible to the end user, such as webpages, mobile apps, and other interactive components. Frontend processes take place on the user's device.

‍

‍

Let’s take a real-world example: Twitter.

When you open Twitter, what you see on the main page (your profile, the latest tweets, the typing input when you write a tweet, how they’re designed and rendered, etc) is done on the frontend, entirely in your web browser or mobile device.

Frontend tools like WeWeb enable you to focus on this part, with a few advantages vs monolithic tools:

• As specialized tools on the frontend, everything is made possible for you to have a clean user interface. Frontend no-code tools follow the latest CSS best practices and features (like flexboxes, breakpoints, grids, etc). Meaning experienced frontend developers or designers will feel at home.
• They create single page applications (SPA) that make complex user experiences possible. For example, instead of rendering a new page when a user clicks on a button, they will rerender the page in real-time in the user’s browser without having to actually refresh it. Which provides a better user experience as the app’s navigation is more fluid and natural.
• They enable you to have workflows that are executed in the context of the user’s browser, meaning: less load on your servers (so more scalability), instant feedback on the user’s screen, etc. For example: changing a submit button’s background color when a form becomes valid or filtering data instantly when the user is typing in a search bar.
• They connect to any backend, including custom-made and legacy ones, without having to actually export the data in a new tool. Meaning you can quickly snatch together a user interface on top of a legacy database (like MySQL) or on top of your backend API. They also play well with third-party APIs (like Stripe for payments, or Algolia for search), meaning you can plug best-in-class tools for each specific use-case your app has.
• These no-code tools also scale really well. Let’s take the example of our app with millions of users. By using a tool like WeWeb for its frontend, you can have some workflows in the frontend, hence, reducing the load on your servers. You can also serve this app to users all around the world in no time, as most frontend apps don’t need servers to load initially in the user’s browser, meaning you can host them on content-delivery network (CDNs), that have really fast loading times and cost almost nothing in comparison to real servers.

But, for complex frontend apps to work, you’ll need a backend server 99% of the time. Indeed, the data in a user’s browser won’t be saved for long, that’s why you need a backend with a database.

3 - Backend tools

Backend tools, like Xano and Supabase, handle server-side processes that are invisible to the user. These processes often involve time-consuming, background tasks, such as recurring jobs and data manipulation. Backend tools also manage sensitive data and privacy concerns.

‍

‍

Most backend tools are comprised of a server and a database:

• The server is in charge of serving data through an API in a standard format (like JSON or XML)
• The database is responsible for saving the app’s data for good and making it easy to query (like PostgreSQL, MySQL or MongoDB)

In the Twitter example, the backend might be responsible for authenticating the user, sending the user’s tweeter feed to its frontend, and saving the tweets he just wrote, like, retweeted for when the user later connects back to the web app.

The advantages of having a separate backend tool are numerous:

• Having the choice to increase either or both the server’s power or database size (when handling many requests versus lots of data), which improves the return on investment on your spending
• Handling recurring, background or time-intensive tasks while the frontend is free to do something else (no more stuck app issues for your users). For example: let’s say you are building a CRM app that sends hundreds of emails for your users. While these emails are sent by the backend, the user is still free to navigate and set up his campaigns in the frontend, without having to actually wait for the emails to be sent to continue.
• Serving only data which is related to the current user for maximum security (remember, everything that’s loaded in a user’s frontend is actually visible to the user, even if not displayed in the current page!)
• Having one single source of truth that will serve data to many frontends. For example, you could have only one backend sending data to a web app and a mobile app. Meaning data is shared between clients and always up-to-date, without having to maintain multiple databases.

If we look at our no-code app example again, with a frontend made in WeWeb, we could connect it to a backend made in Xano, which we’ll use to authenticate users and store their data.

Both tools would communicate through a REST API, using JSON data which is read and parsed automatically by both WeWeb and Xano.

When using WeWeb and Xano, you can even use WeWeb’s Xano data source and auth plugins to automatically retrieve and save your data into your Xano instance, without having to do the REST API requests yourself!

Backend tools are really powerful to have a best-in-class scalability. Often, by upgrading your backend server or database, you’ll “magically” solve your problems for every user of your app, be it on a web or mobile app, as both can (and should) use the same backend!

In the end, using a frontend and backend no-code tool in combination, like a WeWeb + Xano stack, is a strong choice to build an app that will scale with your needs, while keeping your costs optimized.

Even if beginning with a monolithic no-code tool seems easier, and is sometimes (but not always!) cheaper in the beginning, this will often prove the opposite as soon as your app gets more traffic, which we all hope 🙌