This chapter contains code samples. However, you don’t need to remember them, as they simply serve the purpose of helping you understand the context of what’s explained better. Just expose yourself to their meaning and let go of trying to map it to a real implementation.

In the upcoming chapters, the code will be real code samples, which can be found, sorted by branches, at https://github.com/PacktPublishing/Building-Production-Grade-Web-Applications-with-Supabase.

Now for the preamble. In this chapter, we’ll dive into why Supabase is the ideal stack for building exceptional applications and explore its internal architecture.

Don’t be intimidated by the length of this chapter—Supabase works seamlessly without you needing to remember all the details of this chapter. Approach this chapter like you would a novel: as something to read, enjoy, and have aha-moments with, rather than something that you...

Talking about an awesome product is one thing. Understanding its history of success is equally important, as this paves the way for the future that you will invest your time and effort into. Also, that same history is part of the reason why it resonates with the principles of many developers, as well as why it isn’t just yet another Software as a Service (SaaS) with a short life span but one of the most promising tools that the web has seen in recent years.

In 2019, Paul Copplestone, the CEO of Supabase, worked on a Realtime extension for Postgres. This was part of a migration, in his former company, to move away from Google’s Firebase to Postgres. As this gained popularity, he asked his friend Ant Wilson if he’d be open to building an open-source company with the Postgres database at its core.

Ant agreed, and they came up with the name Supabase, choosing this due to the planned “super database”...

Postgres is, and always has been, one of the go-to databases. It has proven to be a reliable and fast partner for projects of any size. Hence, it’s no surprise that Supabase is not only using one but in fact is a Postgres database with a specific setup and specific extensions, enhanced with additional services.

Everything related to Supabase (excluding files) is stored within that exact Postgres database. That’s why we will now jump into a mix of theoretical and practical thoughts about what differentiates Supabase, at its core, from just being a regular database.

One very interesting fact is that the database within Supabase can be controlled by you and is extensible. Often, when you work with any kind of platform that provides you with a database, your access will be limited in regard to safeguarding you from making fatal changes. Supabase, however, gives you full access to its underlying Postgres database...

At the heart of the Supabase stack, you’ll find Supabase Studio, an intuitive dashboard designed to streamline the management of your Supabase instance. However, it’s not a necessity—if you’re a command line person and love to hack SQL commands and HTTP requests much more than using a convenient dashboard, you’d be free to ignore the dashboard. Hence, of all the Supabase services, Studio is the only one you could completely delete without negative impacts on your Supabase infrastructure as it isn’t required by the other services.

Studio excels at simplifying complex tasks, from creating and managing table data to handling users and credentials, and even executing raw SQL commands for those who prefer that level of control. In Figure 1.5, you can catch a glimpse of the Studio start page for one of my projects, showcasing a quick statistical overview of its usage:

...

Supabase Auth, formerly known as GoTrue, is an auth API server written in Go. It’s what I refer to as the authentication service. It was originally created by Netlify. However, Supabase forked it and now builds upon it (https://github.com/supabase/auth).

In the next chapter, you’ll be setting up your first Supabase JavaScript client, which has a lot of convenient methods for the features of your Supabase instance. When you call the convenient supabaseClient.signUp(..) method, it requests the Auth server at its /auth/signup endpoint. Even though you can (and should) always use convenient functions such as signUp(..), it is interesting to know that everything in Supabase is based on REST APIs and hence you are not dependent on any specific framework.

Auth itself does not care about permissions, it cares only about authentication, such as sign-ups, login, recovery, profile changes, and so on. The job of giving...

The driver of any web application is selecting, updating, and inserting data from or into the Database. With Supabase, these actions are internal requests to the PostgREST service, which is reachable at the /rest/ endpoint. That service is the PostgREST project, which essentially makes any Postgres database accessible via the REST API (https://postgrest.org/en/stable/).

However, how does it work? Relational databases consist of tables, just like an Excel spreadsheet. In one Excel file, there can be multiple tabs, each containing a table of columns and rows. Hence, the Excel file itself is like a container for different tables.

In relational databases, this container is called a schema. By default, any table within a Postgres database is created in the default schema, which is named public. A simple visualization of a TodoItem table with an Upload table resembling a Todo database is given in Figure 1.6:

Nearly any sophisticated application will come to a point where it makes sense to deliver live updates to a user without delay, whether it be gaming, a collaborative whiteboard, or simply new comments in your favorite social platform such as Signal. The Supabase Realtime Server solves exactly that.

It is an ultra-fast, open-source WebSocket communication implementation connecting to Postgres databases, written in Elixir Lang (https://elixir-lang.org/) by the CEO of Supabase, Paul Copplestone. It’s worth mentioning that nowadays, it’s driven by community contributors. It can be used for arbitrary real-time communication purposes and is able to handle millions of connections (https://supabase.com/docs/guides/realtime/architecture).

Even more interesting is the fact that it listens for changes within the database, so you can actually push live changes happening in the database to the user without any noticeable delay...

Supabase Storage is the service that allows you to store and manage files while respecting authentication. However, the service in itself isn’t actually storing the files, it’s only managing them.

As we learned, the PostgREST service isn’t a database but only connects to it and provides an API on top of it to access the data from the Postgres database. The Storage service in the Supabase stack provides an API to manage the files which can be in arbitrary places or other servers. Let’s get a deeper understanding of it.

A very common way of storing files is the Simple Storage Service (S3). S3 is an Amazon-specific development that allows for failsafe, distributed, replicated object storage—in simple terms, it’s a well-architected database for files.

Although Supabase uses Amazon’s S3, nowadays, when talking about S3, one doesn’t necessarily mean Amazon S3. There are alternative...

The Image Proxy service is a standalone, but complementary, service to the Storage service. It is used internally by the aforementioned storage service to pre-render images; for example, if you only need a thumbnail of a saved image and not the full resolution, you can use the Image Proxy service.

In the following figure, you’ll see a flow diagram illustrating what happens when you request a resized image from Supabase:

Figure 1.7: The service flow when requesting a resized image

In the figure, you requested a file called cat.jpg, which we assume is high-resolution, and you want it to be downscaled to a size of 120 pixels. In that case, the Storage service will download the file from the S3 and pass it on to the ImageProxy service, which returns it to the Storage service after the transformation. The Storage service will then pass the result on to the one who requested it.

With the...

Edge Functions are small and lightweight pieces of code logic that are separate from your application code. Their name comes from the fact that they best perform on the edge (https://deno.com/blog/the-future-of-web-is-on-the-edge). Edge is a rather new term and refers to a paradigm of delivering a fast result by being as close to the executor as possible. That usually means that the piece of code that is supposed to execute is distributed to different server locations in the world. Depending on where it’s called from, the closest server takes the task.

Supabase’s Edge Functions service allows you to add custom edge functions that you can then execute whenever you need them. However, that leaves us with a question: when do you use them, and if they are that fast, why isn’t everything on the edge?

Edge functions can be considered to be background workers. They need to be small and have a limited processing...

When you use the dashboard to create a new table or add some more columns to a table, you would think that this is done via PostgREST, right? Well, PostgREST is built for data management, not database management.

Instead, database management is the task of the pg-meta service. It is a REST API that allows all kinds of manipulations on the database that is used by the other Supabase services. For example, when you create a new table with Studio, it talks to the pg-meta service by making a POST Request to /pg-meta/tables. It is secured and only accessible for the internal services or admins (e.g., when you log in to Studio, you are an admin).

However, why is pg-meta needed when all the services in the Supabase stack could also access the database directly? The following are some key reasons:

• It abstracts away any underlying changes. In theory, you could even completely replace the database with a different database...

The Supabase services are Docker containers, and those containers live in their own Docker network.So, whenever I say “Supabase service,” I’m referring to a Docker container. The fact that all Supabase services live within the same Docker network means that if one service, such as Storage, has a server running with an API for managing files in its container at localhost:3000, all the other services can access the API of that service with serviceName:3000 (so storage:3000). That also means that all the services can talk to each other via their REST APIs.

Usually, in production environments (such as supabase.com itself), none of the services are directly accessible to the outside, so from the outside, I cannot just use an API at storage:3000. Only containers that explicitly expose themselves to the public will be accessible to the outside, but none of the services in Supabase are—and this is best practice...

In this book, you will build a production-ready, AI-enhanced multi-tenant ticket system with Next.js and Supabase, which you can take, deploy, extend, sell, or do whatever you like with.

To illustrate how Supabase integrates into a real-world application, it was obvious that this book would have to build a real-world application. Hence, I had to choose a framework (Next.js) to build an application together with you rather than just pinpointing to Supabase features. This means that, in the beginning, it may feel a little bit like a Next.js tutorial, but rest assured that this feeling changes over the course of this book. Even if you use another set of technology, you should feel well-guided.

Note

The system that we will build will be functional, contain best practices, and be secure for production usage.

However, what do I mean by a ticket system? We’re not talking about event tickets or bus tickets here; instead...

Wow, what a deep dive into the Supabase ecosystem! We peeled back the layers and got our hands dirty with the inner workings of this powerful platform. From the clever RLS in the database to the seamless chat between services via REST APIs, we saw how Supabase isn’t just smoke and mirrors—it’s smart engineering at its finest.

We uncovered how Supabase blends traditional permission checks with fancy FGA, making data management a breeze for developers. Let’s not forget the star of the show: those REST APIs that tie everything together, including the Supabase client that we’ll be using. We learned about those in this chapter as well.

However, we’re not just here to admire the architecture. All this knowledge is building toward something tangible: our multi-tenant ticket system. We’ve set the stage, and now it’s time to put the theory into practice.

As we move on to the next chapter, get ready to roll up your sleeves...