SaaS


## Why use Supabase with React Query?

[Supabase](https://supabase.com) offers a Javascript SDK for interacting with the Supabase services, such as its hosted Postgres database. As such, it doesn't seem like you would need to use a library like [React Query](https://react-query.tanstack.com/) to fetch data from the server. 

However, there are a few reasons why you might want to use React Query with Supabase:
1. Data re-fetching with React Query. By using React Query, you can easily refetch data after a mutation, or update the cache and add optimistic updates to your application.
2. Caching data. React Query can cache data in various ways, such as in-memory, local storage, or using HTTP caching. This can be useful if you want to reduce the number of requests to your database, and it's arguably necessary if you want to reduce your database costs and scale your application.

While there can be more valid reasons to use React Query with Supabase, these are the two main reasons why I use it, and why I think you should too. 

In this post, I want to show you how to use React Query with Supabase. I'll be using the [Remix](https://remix.run) framework, but the concepts should apply to any React application.

### Why is React Query ideal for Supabase?

Since the realtime database does not support the streaming of snapshots, React Query is my preferred way to fetch data from the database without having to write a lot of code to manage the client-side state. 

By re-fetching data after a mutation, you can easily keep your client-side state in sync with the database without having to merge the data yourself.

## How to use Supabase with React Query

### Installing the dependencies with NPM

First, we want to install the following dependencies in your project:

```bash
npm install @supabase/supabase-js @tanstack/react-query
```

### Creating a React Query client

In the root o your component tree, you want to create a React Query client. This is where you can configure the cache and other options. 

For simplicity, we will just create a default client but do check out the API to see what other options you can configure.

In Remix, we would wrap the root outlet with the `QueryClientProvider` component:

```tsx
const queryClient = new QueryClient();

<QueryClientProvider client={queryClient}>
  <Outlet />
</QueryClientProvider>
```

If you're using Next.js, the above will be placed either in your `_app.tsx` file or in your `pages/root.tsx` layout component.

### Creating a hook to create a Supabase client

Next, we want to create a hook to create a Supabase client. This is so that we can easily create a Supabase client in any component using the `useSupabase` hook.

First, we create a function to create a Supabase client:

```tsx
import { createBrowserClient } from '@supabase/auth-helpers-remix';
import invariant from 'tiny-invariant';
import type { Database } from './database.types';
import getEnv from './get-env';

export function getSupabaseBrowserClient() {
  // Get the environment variables
  const env = getEnv();

  invariant(env.SUPABASE_URL, `Supabase URL was not provided`);
  invariant(env.SUPABASE_ANON_KEY, `Supabase Anon key was not provided`);

  return createBrowserClient<Database>(
    env.SUPABASE_URL, 
    env.SUPABASE_ANON_KEY
  );
}
```

While your code will certainly be different, it's only important to notice that you need to pass the correct environment variables to the browser client.

Next, we can wrap the above in a `useMemo` hook to prevent the client from being recreated on every render:

```tsx filename=hooks/use-supabase.ts
import { useMemo } from 'react';
import { getSupabaseBrowserClient } from '~/core/supabase/browser-client';

function useSupabase() {
  return useMemo(getSupabaseBrowserClient, []);
}

export default useSupabase;
```

### Creating a hook to fetch data

Now that we have a Supabase client, we can create a hook to fetch data from the database. 

My favorite pattern for fetching data is to create a hook that returns a `useQuery` hook from `react-query`. Additionally, I like to pass the client as a parameter to a function that builds the query. This allows us to reuse the same query in both client and server code when creating different Supabase clients.

For example, we assume that we have a `organizations` table in our database, and we want to fetch an organization by its ID. 

We can create a hook like this:

```tsx filename=hooks/use-organization-query.ts
function useOrganizationQuery(organizationId: number) {
  const client = useSupabase();
  const key = ['organization', organizationId];

  return useQuery(key, async () => {
    return getOrganizationById(client, organizationId).then(
      (result) => result.data
    );
  });
}

export default useOrganizationQuery;
```

1. first, we imported the Supabase client using the `useSupabase` hook.
2. we then created a key for the query. This is used to identify the query in the cache and to refetch the query after a mutation.
3. we return the `useQuery` hook from `react-query`. This hook takes a key and a function that returns a promise with the data.

Instead, the function `getOrganizationById` is a function that builds the query. This function is used in both client and server code, and it looks like this:

```tsx filename=queries/get-organization-by-id.ts
export function getOrganizationById(
  client: Client, 
  organizationId: number
) {
  return client
    .from('organizations')
    .select(`
      id,
      name
    `)
    .eq('id', organizationId)
    .throwOnError()
    .single();
}
```

#### Fetching data in a component

Now that we have a hook to fetch data, we can use it in a component. In this example, we will fetch an organization by its ID:

```tsx filename=pages/organizations/[organizationId].tsx
function OrganizationPage({
  organizationId
}: {
  organizationId: number;
}) {
  const { 
    data: organization, 
    isLoading, 
    isError 
  } = useOrganizationQuery(organizationId);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (isError) {
    return <div>Error</div>;
  }

  return (
    <div>
      <h1>{organization.name}</h1>
    </div>
  );
}
```

The hook from `react-query` returns an object that we can use to determine the state of the query. In the example above we are checking if the query is loading or if there was an error.

### Creating a hook to mutate data

Now that we have a hook to fetch data, we can create a hook to mutate data. Mutating data typically happens upon a user action, such as submitting a form. 

The concept is similar to the above, but instead of using `useQuery` we will use `useMutation` from `react-query`.

For example, we assume that we have a `organizations` table in our database, and we want to update an organization by its ID.

We can create a hook like this:

```tsx filename=hooks/use-update-organization-mutation.ts
function useUpdateOrganizationMutation() {
  const client = useSupabase();

  return useMutation(
    async (organization: Organization) => {
      return updateOrganizationById(client, organization).then(
        (result) => result.data
      );
    }
  );
}
```

1. first, we imported the Supabase client using the `useSupabase` hook.
2. we return the `useMutation` hook from `react-query`. This hook takes a function that returns a promise with the data.

```tsx
export async function updateOrganization(
  client: Client,
  params: {
    id: number;
    data: Partial<Organization>;
  }
) {
  return client
    .from('organizations'')
    .update({
      name: params.data.name,
    })
    .match({ id: params.id })
    .throwOnError()
    .select<string, Organization>('*')
    .throwOnError()
    .single();
}
```

#### Mutating data in a component

Now that we have a hook to mutate data, we can use it in a component. In this example, we will update an organization by its ID:

```tsx filename=OrganizationForm.tsx
export function OrganizationForm({
  organizationId
}: {
  organizationId: number;
}) {
  const updateOrganizationMutation = useUpdateOrganizationMutation();

 const onsSubmit = (event: React.FormEvent<HTMLFormElement>) => {
    event.preventDefault();

    const formData = new FormData(event.currentTarget);
    const name = formData.get('name') as string;

    updateOrganizationMutation.mutate({
      id: organizationId,
      data: {
        name,
      },
    });
  };

  return <form onSubmit={onSubmit}></form>;
}
```

We have abstracted the form's UI, but the concept is the same. We call the `mutate` function from the hook to update the data.

If you want to turn the request into a promise, you can use the `mutateAsync` function:

```tsx
updateOrganizationMutation.mutate({
  id: organizationId,
  data: {
    name,
  },
});
```

This is incredibly useful if you want to do something after the mutation has completed or if you use a library that accepts a promise. In the case of Makerkit, we use `react-hot-toast` to show a toast during the mutation.

### Re-fetching data after a mutation

When we mutate data, we want to re-fetch the data to display the newly updated data within the UI. To coordinate data reefetching across queries, we can use the query client from `react-query` to reresh queries by referring to them using their IDs. 

Let's rewrite the `useUpdateOrganizationMutation` hook to re-fetch the query after the mutation has completed:

```tsx filename=hooks/use-update-organization-mutation.ts
function useUpdateOrganizationMutation() {
  const client = useSupabase();
  const queryClient = useQueryClient();

  return useMutation(
    async (organization: Organization) => {
      return updateOrganizationById(client, organization).then(
        (result) => result.data
      );
    }, {
      onSuccess: (data, variables) => {
        queryClient.refetchQueries(['organization', variables.id]);
      }
    }
  );
}
```

### Updating the cache after a mutation

When we mutate data, we want to update the cache to display the newly updated data within the UI. 

To coordinate data refetching across queries, we can use the query client from `react-query` to update the cache by referring to them using their IDs.

```tsx
const queryClient = useQueryClient()

const promise = updateOrganizationMutation.mutateAsync(organizationData, {
  onSuccess: () => {
    const newOrganizationData = {
      ...organization,
      ...organizationData,
    };

    setOrganization(newOrganizationData);

    const userId = session?.data?.id;
    const query = ['organizations', { userId }];

    queryClient.setQueryData<UserOrganizationData[]>(query, (data) => {
      if (data) {
        return data.map((item) => {
          if (organization.id === item.organization.id) {
            const mergedOrganization = {
              ...item.organization,
              ...newOrganizationData,
            };

            return { ...item, organization: mergedOrganization };
          }

          return item;
        });
      }
    });
  },
});
```

### Invalidating a query after a mutation

Similarly, we can invalidate a query after a mutation to force a re-fetch of the data. This is useful if we want to update the cache with the latest data.

```tsx
const queryClient = useQueryClient()

const promise = updateOrganizationMutation.mutateAsync(organizationData, {
  onSuccess: () => {
    queryClient.invalidateQueries(['organization', organization.id]);
  }
});
```

### Optimistic updates with React Query

It can be useful in terms of UX to update the UI before the mutation has completed. This is called an optimistic update.

React Query makes it a breeze to do this. We can use the `onMutate` function to update the cache before the mutation has completed. If the mutation fails, we can use the `onError` function to roll back the cache to its previous state.

```tsx
 const queryClient = useQueryClient()
 
 useMutation(updateOrganization, {
   onMutate: async organization => {
     // Cancel any outgoing refetches 
     await queryClient.cancelQueries('organizations');
 
     // Snapshot the previous value
     const snanpshot = queryClient.getQueryData('organizations');
 
     // Optimistically update to the new value
     queryClient.setQueryData('organizations', old => [...old, organization]);
 
     // Return a context object with the snapshotted value
     return { snanpshot };
   },
   onError: (err, newTodo, context) => {
     // If the mutation fails, use the context returned from onMutate to roll back
     queryClient.setQueryData('todos', context.snanpshot)
   },
   onSettled: () => {
     // Always refetch after error or success
     queryClient.invalidateQueries('organizations')
   },
 });
```

## Conclusion

In this article, we have learned how to use Supabase with React Query.

I hope the above has given you some ideas on how to use Supabase with React Query. If you have any questions, please feel free to reach out!

How to use Supabase with React Query


This post is a follow-up to our previous post on why you should use [Next.js for your SaaS](/blog/saas/why-you-should-use-nextjs-saas). 

Are you thinking of building your next SaaS project and not sure what to use? This blog post shares our thoughts on why you should consider using Remix, a full-stack framework for building websites currently being developed at Shopify.

## Remix is built by the creators of React Router and React Training

While not as popular as Next.js, Remix is a full-stack framework built by the creators of React Router, the most popular routing library for React. 

The wealth of experience and knowledge of the team behind Remix can be seen in the framework itself: it's a very well-thought-out framework that is easy to use and has a lot of potential.

## Remix is backed by Shopify

Remix has recently been bought by Shopify, which is a huge vote of confidence in the framework. Shopify is the most popular e-commerce platform in the world, and the team behind Remix will be able to leverage Shopify's resources to make Remix even better.

That also means that Remix will become the framework of choice for building custom e-commerce experiences on Shopify, which used to be referred to as "Hydrogen". The team decided to drop their original implementation based on React's Server Components and instead use Remix.

The backing from Shopify will help Remix gain more traction and popularity, which is certainly good for the framework and the community.

### Very simple to get started. It's a router with a few extra features

Remix is definitely a *different* framework, but it's also very simple at the same time. 

The Remix creators say that by learning Remix, you will learn web development and that it's true: Remix adheres to Web Standards and is built on top of the web platform, leaving behind the "express" way like many other frameworks.

Remix can be thought of as a Router with SSR. The API surface is very small and easy to learn, and the documentation is fairly well-written, which should make it easy for you to get started.

### Easy to sell your projects

Given its popularity, selling a SaaS built with Remix and React can be
easier than selling a project made with a more obscure (or less in-demand)
technology.

Being backed by Shopify also means that Remix will be a safe bet for many developers, which will make it easier to sell your projects. With its popularity set to rise, selling a project built with Remix will get simpler and simpler.

## Remix offers all the tools to build a modern SaaS

Remix offers all the tools you need to build a modern SaaS. 

Let's take a look at some of the features that make Remix a great choice for building a SaaS.

### Access to a ton of open-source projects and libraries

Being built using React, you have an incredible number of libraries made by small and large companies at your disposal. 

Remix is no different than Next.js in this regard: you can use any React library you want, and Remix will work with it.

### Serverless and Edge computing

Unlike Next.js, Remix can be deployed to edge computing platforms such as Cloudflare Workers or Deno: which means, you can get incredible performance for your SaaS.

Not only is faster, but it's also cheaper to run your SaaS on edge computing platforms. 

While it's expected that Next.js will follow a similar path, Remix is there today. If you care about maximum performance and minimum cost, Remix is a great choice.

### Remix is very fast

Remix is incredibly performant: it's no wonder Shopify decided to make it the framework of choice for building custom e-commerce experiences on Shopify.

Performance is a key factor for eCommerce stores, so we can expect the Remix team to put a lot of effort into making Remix even faster.

## Conclusion: is Remix a safe bet for your SaaS?

Remix can still be considered the new kid on the block, but at Makerkit we use it with confidence and are happy to bet on it. It's undeniable that the acquisition by Shopify will help Remix gain stability, reduce the risk of the framework disappearing, and make it a safe choice for using it for building your SaaS.

[Makerkit](/) is a SaaS starter template built with Remix for Firebase and Supabase as backends. Our Remix SaaS boilerplate kits can
help you kickstart a SaaS in under 5 minutes and deploy it in a matter of hours.

If you want to build your SaaS with Remix, take a look at one of our kits!


Why you should use Remix for your SaaS


Firebase and Supabase are two of the most popular backend-as-a-service (BaaS) platforms. While at Makerkit we started by using Firebase for our original SaaS kit, we are now also working to support SaaS kits based on Supabase.

In this article, we will compare Firebase vs Supabase to help you decide which one is better for your next project, so you can choose the right kit for your needs.

---

Makerkit is a SaaS boilerplate to build a SaaS using Firebase or Supabase. It's a complete solution that includes a landing page, a dashboard, and a billing system. It's built with React, Next.js or Remix, Tailwind CSS, and TypeScript.

## What is Firebase?

Firebase is a BaaS platform that provides a set of tools and services to help you build and run your app. It is developed by Google and is one of the most popular BaaS platforms.

Firebase offers a wide range of services, including:
- Authentication
- Realtime Database / Firestore
- Storage
- Hosting
- Cloud Functions
- Cloud Messaging
- Performance Monitoring
- Remote Config
- Analytics

## What is Supabase?

Supabase is an open-source alternative to Firebase. It is a BaaS platform that provides a set of tools and services to help you build and run your app. It's backed by YC and Mozilla and is one of the fastest-growing BaaS platforms.

Supabase also offers a wide range of services, including:
- Authentication
- Realtime Database / Postgres
- Storage
- Functions

## Features

When it comes to features, it's clear that Firebase has the upper hand, as it offers more services than Supabase.

However, Supabase is catching up fast and is adding new features regularly. It's also worth noting that many Firebase services only work for mobile apps, such as Crashlytics, ML, Dynamic Links, and others.

If you're building a web app, **Firebase and Supabase will offer you a similar set of features**.

## Authentication

Firebase and Supabase both offer complete authentication services that offer a variety of authentication methods, including email/password, phone, magic link, Google, Facebook, Twitter, and GitHub.

Firebase also offers anonymous authentication, which is not available in Supabase. This can be useful if you want to allow users to use your app without signing up.

There isn't a large difference Firebase and Supabase when it comes to authentication. Both platforms offer an exceptional set of features and are easy to use.

## Database

Firebase offers two database options: Realtime Database and Firestore. Realtime Database is a NoSQL database that stores data in JSON format. Firestore is a document-based database that stores data in JSON format.

### Firestore DB
Firestore allows us to write and read data directly from the clients without having to write any server code by writing security rules.

### Supabase Postgres

Supabase offers a managed Postgres database.

Postgres is one of the most popular and battle-tested relational databases that stores data in tables.

Supabase also supports client-side reads and writes by allowing developers to protect their database using Postgres Row Level Security (RLS): these rules allow us to control who can read and write data using SQL.

## Firestore vs Postgres

Firestore and Postgres are two different types of databases. Firestore is a document-based database that stores data in JSON format. Postgres is a relational database that stores data in tables.

I would recommend using Firestore if you're not experienced with SQL and relational databases. Firestore is simpler to use, and most importantly easier to secure: Firestore security rules are arguably much simpler than Postgres RLS.

However, if you're experienced with SQL and relational databases, then Postgres is the better option. Postgres is a battle-tested database that is used by many large companies, allows us to write complex queries, can allow us to use full-text search, and is better when it comes to data integrity.

Simply speaking, Firestore is **better for beginners**, and Postgres is **better for experienced developers** who have already worked with Postgres and SQL.

This does not mean Firestore is not a good option for experienced developers: if your data structure is valid for NoSQL and you don't need to write complex queries, then Firestore is a great option.

### Realtime

Firebase and Supabase both offer realtime database services, but there are differences worth noting.

#### Firebase Firestore Realtime Database

Firebase's realtime queries allow us to listen to changes in the database and receive updates in real-time: the updates include the full snapshot of our query.

The ability to receive real-time snapshots of a query is incredibly useful since we don't need to write any client-side code to manage state and reconcile changes.

The UI will automatically reflect the changes in the database using the snapshot from the realtime query.

#### Supabase Postgres Realtime Database

Supabase's realtime works differently, and it's not as straightforward as Firebase's realtime queries.

It uses a pub/sub system that allows us to listen to changes in the database and receive updates in real-time. Updates do not return the current snapshot of the original query, but rather they indicate what changed in the database. This means that we need to write client-side code to manage the state and reconcile changes.

The UI will not automatically reflect the changes in the database, but we need to write code to update the UI.

When it comes to real-time changes, Firebase is the clear winner.

## Self Hosting

Many developers may want to self-host their app, be it for security reasons or scalability.

When it comes to self-hosting, the answer is simple: **Firebase does not allow us to self-host** our app, while **Supabase does**.

If self-hosting is important to you, then Supabase is the better option.

## Local Development

Firebase and Supabase both offer a local development environment that allows us to run our app locally. This is incredibly useful since we can test our app locally before deploying it to production.

Firebase offers a local emulator that allows us to run the Firebase services locally: it's a bit of a black box, and we cannot see what's happening under the hood. It works fairly well though, and it's feature-complete these days.

Supabase allows us to run a self-hosted instance locally using Docker. It still lacks some features but is getting better every day.

Both services offer a local development Admin UI.

## SDK

Firebase and Supabase both offer a complete set of SDKs. Generally speaking, they're both very valid options.

Firebase's SDK is more mature and has more features. It's split into multiple packages for each feature. This was necessary so that we could tree-shake the library and reduce the bundle size.

Supabase's SDK, instead, has a much smaller API surface, it's more lightweight and simpler to use.

### Isomorphic SDK

Firebase's SDK is split between Client SDK and Admin SDK. When we use the SDK in our API functions, or when server-side rendering, we cannot use the client SDK, but we're constrained to use the Admin SDK.

This has a lot of disadvantages, especially when it comes to server-side rendering (SSR): in fact, we are forced to write separate queries for the client and the server, and we cannot use the same query for both. This leads to more code and more complexity.

Instead, the Supabase client SDK is isomorphic, which means that we can use the same SDK both on the client and on the server. This allows us to write less code and have a simpler architecture.

### Edge Environments

Supabase has a clear advantage over the Firebase SDK: in fact, it can be used in edge environments, such as Cloudflare Workers and Deno. Instead, Firebase's SDK is only available for Node.js and the browser.

What does it mean? It means that by allowing us to use Supabase in edge environments, we can use Supabase to build serverless applications that run on the edge. This can unlock incredibly fast performance and reduce costs.

### SDK: which one is the winner?

While the Firebase SDK is more mature and has more features, the Supabase SDK is more lightweight and simpler to use. Additionally, it allows us to use the same SDK both on the client and on the server and in edge environments which is a huge advantage.

Personally speaking, I prefer the Supabase SDK.

## Conclusion

Firebase and Supabase are both great BaaS platforms. They both offer a complete set of features and are easy to use. Ultimately, since they offer a similar set of features, the choice between Firebase and Supabase will depend on your use case, your preferences, and your experience.

### When to use Firebase

Here are some examples of use cases where Firebase is a better option:

- If you're building a mobile app, Firebase offers more features than Supabase
- If you're a beginner and you're not familiar with SQL and relational databases, Firestore is a better option than Postgres
- If you prefer not to manage client-side state and rely on real-time features to automatically update the UI, Firebase is a better option than Supabase
- If you prefer to use a more hands-off service, Firebase is a better option than Supabase

### When to use Supabase

Here are some examples of use cases where Supabase is a better option:

- If you want to use Postgres and leverage better data integrity, more complex queries, and full-text search, Supabase is a better option than Firestore
- If you want to use the same SDK both on the client and on the server, Supabase is a better option than Firebase
- If you want to use Supabase in edge environments, Supabase is a better option than Firebase
- If you want to self-host your BaaS, Supabase is a better option than Firebase
- If you want to use a BaaS that is open-source and transparent, Supabase is a better option than Firebase


Firebase vs Supabase: Which one is better for your next project?


Makerkit is a collection of SaaS templates that helps you build a SaaS in just a few days.

Makerkit offers various kits such as Next.js or Remix and Firebase as a backend. The SaaS kits come with a lot of features that you can use to build your SaaS: project setup, authentication, multi-tenancy, billing, subscriptions, and more.

In this post, I want to share more transparency about whether Makerkit is the right SaaS template for you or not.

## Who is Makerkit for?

Makerkit is for developers and indie hackers who want to **build a SaaS in a few days, instead of months**.

How so? By offering most of the features that you need to build a SaaS, you can focus on building your product instead of building the boilerplate. 

For example, you won't need to worry about authentication, billing, or subscriptions. While there will be some setup outside of Makerkit that can take some time (which can take a few hours), once you have all the keys and credentials, **Makerkit's SaaS codebase is basically ready to be deployed**.

## What use case is Makerkit for?

The best use case for Makerkit is traditional SaaS products. For example, a SaaS that allows your customers to:

1. Authenticate to your app using email and password or social logins
2. Reset their own credentials without contacting you
3. Create a team/organization and share assets with other members
4. Invite other users to join their team/organization and assign them roles (owner, admin, member)
5. Manage their team/organization members: updating their roles, removing them, etc.
6. Create a subscription plan and manage billing using Stripe
7. Pre-defined landing pages such as home page, FAQ, pricing
8. Blog and documentation generated from MDX files

While the Makerkit SaaS templates can easily be customized, the above is what comes out of the box.

If you want to build a SaaS that doesn't fit the above use case, Makerkit might not be the right fit for you, and you may need something more custom/simpler.

## Which technology stack should I know?

Makerkit offers two kits at the time of writing:

1. Next.js and Firebase
2. Remix and Firebase

If you're familiar with either of these technologies, **Makerkit can be an excellent choice to build your SaaS**. 

Which one should you choose? Well, you don't need to worry too much, since you have access to both kits. My recommendation is to **take a look at both and see which code base you prefer**: I personally thing they're both excellent choices for your next SaaS.

The most important part of the stack that you should know is React. If you're not familiar with React and intend to hit the ground running, I recommend you should consider a different SaaS template. If you want to purchase the kit to learn React and you're not under a time constraint, **then Makerkit is a great choice**.

Should you use Makerkit as your SaaS Boilerplate?


Are you thinking of building your next SaaS project and not sure what to use? This blog post shares our thoughts on why you should consider using Next.js.

## Next.js is extremely popular

While popularity in and by itself is not a reason for choosing a technology,
it is also true that choosing a popular tech is usually the safe choice for
various reasons.

Riding on the popularity of React, Next.js has established itself as the
de-facto framework for building full-stack applications with React.

While it is no longer true that Next.js is the only player in town (like Remix,
Redwood, etc.) it is undeniably the most famous, well-funded, and trusted
framework today.

### Easy to work with

Next.js has gained the love of many developers due to it being incredibly
easy to work with. **The API layer is tiny**, so you don't need to
spend weeks memorizing tons of hours on it.

Secondly, Next.js is fairly production-ready from the get-go, with minimal
intervention for bootstrapping a runnable project.

### Plenty of documentation and content

Its popularity means having access to a ton of good documentation, Q&As,
blog posts, and content about it on the Internet.

This is one of the deciding
factors when choosing a technology: will you be alone when you encounter
issues, or will you be able to easily solve your problem with a simple Google
Search?

### Easy to hire talent

If you plan on hiring talent, you should know that Next.js is among the
favorite frameworks among web developers, making it easier to hire talented
developers worldwide.

It's one of the most popular frameworks in the world, and its popularity means that a ton of people know it well and can help you build your product.

The possibility of never running out of great talent can be a big factor in
using such a popular technology for companies of any size.

### Easy to sell your projects

Given its popularity, selling a SaaS built with Next.js and React can be
easier than selling a project made with a more obscure (or less in-demand)
technology.

The reason is simple: it's a lot more likely that the buyer is already able
to use Next.js than other technologies,
be this an individual or a team of developers.

If I were to build a project with the goal of flipping it, Next.js would be
at the top of my list.

## Next.js offers all the tools to build a modern SaaS

But why is Next.js so popular? Here are some reasons why the
framework built by Vercel managed to capture the love of so many developers.

### Access to a ton of open-source projects and libraries

Another reason you should consider using Next.js for your SaaS is that it gives
you access to many open-source projects and libraries already built.

That means you can take advantage of all the
hard work other developers have already put into those projects and libraries instead of reinventing the wheel yourself.

Being built using React, you have an incredible number of libraries made by small and large companies at your disposal.

### Serverless and native Vercel Hosting

Many developers don't want to be hassled with maintaining servers;
fortunately, its native integration into Vercel's hosting makes Next.js one
of the easiest frameworks to deploy to a serverless environment.

This means you can focus on what's important: **growing your business**,
not spinning and restarting servers.

You'll also have access to all the benefits of a serverless environment,
including scalability, security, and cost savings.

### Next.js is very fast

While not the fastest, it's safe to say that Next.js delivers incredible
performance, which is more than enough for most web applications,
and that can make your little application beat more established
companies when it comes to performance.

Thanks to Vercel's Edge runtime, Next.js can also get much faster for
certain use-cases, such as authentication, A/B testing, and more.

### SSR and SSG

One of the main selling points of Next.js is the ability to automatically
detect if a page needs to be server-side rendered or if it can be a simple
statically generated HTML page.

#### Can statically render pages SSG

For example, if you are rendering a blog post and this page does not need to
fetch any data at render-time, Next.js will generate a static HTML page
instead of rendering the page on the server.

Why? Of course, with no runtime
involved, **a static HTML page will be loaded considerably faster than a
server-side
rendered one**. Furthermore, it will allow developers to save money on computing
time.

This is ideal for static pages such as your marketing landing page,
blog, documentation, etc.

#### Can render pages server-side SSR

Whenever a page requires data at render-time (ie. using the special
function `getServerSideProps`,
Next.js will automatically render the page on the server without any
configuration.

This allows you to dynamically generate pages and based on the user's
context. This is ideal for the internal pages of your application, i.e. the
ones behind authentication.

## Next.js has a bright future

### Vercel has hired plenty of superstars, including from the React team

Vercel has hired plenty of brilliant open-source developers (including from
the React Core Team) to help them
improve Next.js, Vercel, and the entire Javascript ecosystem.

The continued investment into open source technologies by Vercel will help
the framework and the technologies around it keep growing and improving.

The investment into technologies such as Webpack, SWC, Svelte, Turborepo and
others also means that other frameworks will be able to gain from Vercel's
work, making it a victory for everyone.

It's safe to say that the framework is in very good hands.

### Next.js will continue to innovate

Next.js will soon release incredible features that fully use the
newest React developments, such as *Concurrent Mode*, *Server Side
Components*, *Nested Routing* (that [*Remix*](https://remix.run) nailed very
well), the new Edge runtime, Middlewares, and much more.

The above are super-exciting: **Next.js is set to become faster, more
dynamic, and easier to use than ever before**.

## Conclusion: is Next.js a safe bet for your SaaS?

While we want to stress that many great frameworks exist, we're comfortable
saying that as of today, **Next.js is one of the best technologies to start
a SaaS due to its speed, ease of use, and popularity**.

[Makerkit](/) is a SaaS starter template built with Next.js and Firebase to
help you kickstart a SaaS in under 5 minutes. If you want to build
your SaaS with Next.js, take a look at what we offer!


Why you should use Next.js for your SaaS


Firebase is a serverless platform by Google that helps developers build and
grow apps. Millions of developers every day use Firebase for building
complex and profitable SaaS projects.

Why is Firebase so popular? Firebase offers many services for developers:

- **Analytics**: Provides data about how people interact with your app on
mobile devices
or the web without writing any code

- **Cloud Functions**: Runs server-side JavaScript code in response to events
such as user
actions or real-time messages from other platforms like Slack or Facebook Messenger

- **Cloud Storage**: Lets you store and access user-generated content like
images or videos in
the cloud

- **Firestore and RealTime DB**: two serverless and NoSQL databases with
different strengths for storing
your application data

- **Messaging**: allows sending push messages and notifications to the
connected
 clients

- **AppCheck**: helps secure your applications with the invisible Recaptcha v3

## Top Reasons why Firebase is great for building a SaaS

### 1) Firebase offers everything you need to build a large SaaS

As you can see, Firebase offers a complete solution for building a SaaS.

It's easy to set up and secure and scales out automatically as you grow. In addition, it's cost-effective and easy to use, so you don't need an army of developers to maintain your database or update its security rules.

In this post, we'll detail why Firebase is one of the best solutions for building a modern SaaS and its weaknesses, so you know how to complement it with other tools should you need to.

### 2) Developers can use Firebase with the whole suite of Google Cloud products

When Firebase doesn't support what you need, you can still use all the other Google Cloud's products, such as:

- SQL databases

- Caching stores such as Redis

- Analytics Tools and DBs such as BigQuery and BigTable

- Secret Management services

- ... and all the rest of Google Cloud's products and its Marketplace that
allows you to install apps with a single click

### 3) The Firebase Emulator helps you develop locally

The Firebase emulator is a fully-functional, real-time simulator of your app that you can use to test your code locally.

The emulator covers all the Firebase products, which means you can create a local environment that almost entirely reflects your Cloud application in production.

### 4) Create different projects for each environment

Firebase isn't stingy about how many projects you create, so you can easily create a project for each environment.: This helps you save money and develop projects that most likely won't cost you anything more.

### 5) It allows to build serverless products on the Cloud

The cloud is a great place to build serverless products. You don’t need to worry about database maintenance or server uptime and reliability because everything is taken care of automatically. Firebase lets you focus on building your core product while keeping costs low.

If you are a solo developer or a small team, relying on Google's cloud reliability is incredibly helpful: in fact, all your time is best spent on building the product and gaining product-market fit, rather than fighting CIs and servers all day.

### 6) It can be used for building web and mobile apps (iOS, Android, and Web)

While Firebase is often regarded as a PaaS for Mobile apps, the truth is that you can build any application with it: Web Apps, IoT apps, and desktop ones.

Firebase has developed its SDKs to work with multiple programming languages and platforms and offers a Rest API for the unsupported ones.

### 7) The Firebase SDKs have received huge updates

Firebase has often been criticized for its SDKs: heavy on the client-side, confusing due to the various published versions, and not the best API out there.

Fortunately, the Firebase SDKs have received more love recently: starting from version 9 (the current one at the time of writing), they are lighter, more straightforward to use, and better documented.

They're finally tree-shakeable, so your client-side will only load what it uses.

### 8) It's reasonably priced

Firebase is a very reasonably priced service for what it does.

Also, thanks to its very generous free tier, it's likely that you will not spend a dollar on developing your application during its first months if your traffic is light.

This is amazing if you are a solo developer, a small startup, or quickly prototyping an internal tool for your company.

## Makerkit is one of the complete Firebase SaaS starters with Next.js

The most complete Firebase SaaS starter kit today is Makerkit: **It's a
complete solution for building a SaaS, including all the modules you need to
start**.

It's built on top of Firebase, Next.js and Tailwind CSS and offers everything
you need to kick-start a fully working SaaS application that you can use as
a starting point for shipping your next SaaS idea.

Makerkit is built on the fastest growing technologies in recent years,
designed to be quick and easy to use.

## Conclusion

In conclusion, Firebase is an excellent choice for building SaaS applications; we think it's even better today than before and will continue to improve.

Therefore, we at Makerkit believe that Firebase is one of the best options available if you're looking to build a scalable, serverless product on the cloud that supports real-time notifications.

If you want to build a new SaaS with Firebase, take a look at our starter template for creating a SaaS with Firebase and Next.js. We made it so that starting a new SaaS project won't take more than 5 minutes. It's ideal if you are a solo developer or a startup or if you feel like prototyping something new.


Is Firebase good for building a SaaS?


The idea of a modern web application can vary greatly - but at MakerKit, **we have a good idea of what it looks like**.

Most SaaS companies use different codebases (or many) for the marketing website, the product application, and the documentation website. The marketing website usually is the top-level domain. The application gets hosted on a sub-domain (such as app.example.com), and the documentation at (docs.example.com)

Historically, there have been good reasons for doing so, such as:
- **Deployment**: separate deployment means **less risk of breaking one or the other** parts of the stack
- **Engineering Time**: having its dedicated marketing website (typically using a CMS such as WordPress) means that your company won't need to involve the engineers in technical aspects, **saving costly engineering man-hours**
- **SPAs**: the growth of client-side SPA (Single-page Applications) frameworks in the past decade made it **impossible to achieve the decent speed and SEO needed for any marketing website**
- **Concerns**: better **separation of concerns**; the marketing website needs to be an SEO beast, the product a fast and secure application
- **Analytics**: separate and **more straightforward analytics tracking**

As you can see from the above points, many would argue that having a separate codebase can be advantageous in many aspects. But it's not black and white, and for many reasons, **we at MakerKit think that a portion of websites would instead benefit from having a single codebase**.

## Technical Progress with SSR and SSG

While not anything new, it's only recently that SSR (Server-side rendering) and SSG (Static-site generation) have been popularized and democratized for Product applications.

Technical progress from frameworks (React, Next.js, Svelte, Vue, Angular Universal, etc.) and PaaS (Vercel, Firebase, etc.) have been outstanding and made it easier than ever to ship a full-stack application.

MakerKit uses Next.js and **makes the most of its incredible hybrid SSR and SSG** to ship dynamic pages for the product Saas, and static, SEO-optimized web pages for the marketing website's content and documentation.

## Branding and Styling

One of the most challenging undertakings for companies using separate codebases is **delivering unique and consistent branding and styling across all the codebases**. This is especially hard when outsourcing the marketing website to external companies or when built by a different internal engineering team.

One of the ways this can be solved is by using internal UI Components systems built with Web Components that you can reuse across various applications and websites. The downside to using Web Components is the added engineering cost of developing and maintaining the code necessary to deliver the needs of all the consumers involved.

A unified codebase means a **more consistent styling/branding**, **more reusable components**, and **fewer costs** associated with outsourcing your technology stack.

## Seamless Navigation and UX

Another issue with having separate codebases is that, in many instances, the navigation between the Marketing website, the SaaS application, and the documentation website happens across different domains and technologies. From a UX perspective, this is far from ideal.

The navigation will be slower, and the UI less consistent. Furthermore, it can be harder to deliver delightful experiences for your user, such as persisting the authentication, ad-hoc and personalized content to your visitors, etc.

A unified codebase means a **more seamless and much faster navigation and User Experience**, the ability to **deliver personalized content** (for example, providing an API key for users navigating through your documentation), and ultimately happier users.

## When not to use a unified codebase?

It's undeniable that, despite the solutions listed above, a unified codebase is not the most viable solution for every company.

It's not something we'd recommend in the following situations:
- **Company Size**: if your marketing speed and team outpace your engineering team, it's clear that having a codebase that needs development work and maintenance can hinder and slow down both your teams. Having a website that the marketing team can maintain is the best decision.
- **Mission-Critical product**: if your SaaS product is mission-critical (for example, a bank), it's clear that you will want to reduce any risk to your clients; in this case, a separate, ring-fenced codebase can be the right solution

## When should you use a unified codebase?

In our opinion, smaller companies, startups, solo developers, and indie hackers would benefit significantly from having a unified codebase. **SaaS starters such as MakerKit** would be the **best way to kick-start products and ship them quickly to your customers**.

These developers are the most likely to build all in-house and are usually more technical and agile.

Does it sound like you? [Contact us](/contact), and let's find out if MakerKit can be the starter for your next SaaS.


Blog

Tutorials, Guides and Updates for building your Next.js SaaS