DEV Community: Brighton Mboya

Data Modelling for Multi tenancy apps.

Brighton Mboya — Fri, 26 Jul 2024 09:31:22 +0000

When building multi-tenancy applications, the easiest and most common architecture pattern is sharing resources across all clients and ensuring each client gets access to the data they own. In this case, sharing a single database compute shared by all clients. This comes with extra caution, as we will see later. You have to model your data layer so that you can't expose data to the person who shouldn't see it in the first place.

In this example, we will be doing data modeling for an enterprise TODO app. The end goal of this app is that an enterprise "admin" can create an account for our to-do app, create a workspace as well as invite team members to join this workspace.

Before we get to the data modeling bit, let's look at the onboarding flow to get a higher level of understanding of things.

The user will sign up, and then after successful account creation, we direct them to the welcome screen
In the welcome screen, we check if the user is already a member of any workspace; if yes, we then redirect them to their dashboard sth like /dashboard/workspaceSlug/sthElse. If the user is not a member of any workspace, we then show the UI to create a workspace and then redirect them to the dashboard.

After getting the onboarding flow logic nailed, we move on to the data modeling bits. You will notice that in most apps, the concept of workspaces is used consistently. This is a common naming convention of the tables and it represents that all other tables are linked to this table. All of your other tables should be linked to this table by primary keys. It should contain basic information such as name, link to the user table, and a unique workspace ID. Below is an initial model of the workspace table linked to the user table. Note that we use auth.js for auth but the logic should apply with any other auth solution.

The below schema file uses Prisma ORM but the syntax to other ORMs or even raw SQL should be pretty much straight forward.

model User {
  id               String         @id @default(cuid())
  name             String?
  email            String?        @unique
  emailVerified    DateTime?
  image            String?
  accounts         Account[]
  source           String?
  defaultWorkspace String?
  createdAt        DateTime       @default(now())
  updatedAt        DateTime       @updatedAt
  WorkspaceUsers   WorkspaceUsers[]
  @@index(source)
  @@index(defaultWorkspace)
}

model Account {
  userId            String
  type              String
  provider          String
  providerAccountId String
  refresh_token     String?
  access_token      String?
  expires_at        Int?
  token_type        String?
  scope             String?
  id_token          String?
  session_state     String?

  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@id([provider, providerAccountId])
}

model WorkspaceUsers {
  id        String   @id @default(cuid())
  role      Role     @default(member)
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  user      User     @relation(fields: [userId], references: [id], onDelete: Cascade)
  userId    String
  workspace   Workspace  @relation(fields: [workspaceId], references: [id], onDelete: Cascade)
  workspaceId String

  @@unique([userId, workspaceId])
  @@index([workspaceId])
}

model Workspace {
  id                   String                 @id @default(cuid())
  name                 String
  slug                 String                 @unique
  logo                 String?
  plan                 String                 @default("free")
  inviteCode           String?                @unique
  createdAt            DateTime               @default(now())
  updatedAt            DateTime               @updatedAt
  users                WorkspaceUsers[]
  invites              WorkspaceInvite[]
}

model WorkspaceInvite {
  email     String
  expires   DateTime
  workspace  Workspace  @relation(fields: [workspaceId], references: [id], onDelete: Cascade)
  workspaceId String
  createdAt DateTime @default(now())

  @@unique([email, workspaceId])
  @@index([workspaceId])
}

enum Role {
  owner
  member
}

The User and Account tables are tables for authentication, and in this case, they are handled by the auth.js library; you can replace them with any other tables where you store your user data. The following relationship should be kept for the other tables.

A user can belong to multiple workspaces. This will allow the user to switch between multiple workspaces without affecting the other people in the organization.
Each workspace should have a unique workspace invite, which will ensure that no individual invite link belongs to more than one workspace.
Each workspace slug should be unique, so check this before creating a new workspace.
All other tables should be linked to the workspace table via a primary key.

Lastly, the todo table will be the table where we handle our todo lists.

model Todo {
  id          String   @id @default(cuid())
  title       String
  description String
  dueDate     DateTime
  createdAt   DateTime
  updatedAt   DateTime
}

model Workspace {
   ... other fields
   todo Todos[]
}

This will be the basis of the data model for the multi-tenancy todo app. We can improve the performance of our queries by adding indexes to the tables.

Advanced Use Cases

We can implement Row Level Security to ensure we don't expose our data to users who shouldn't access them. You can think of RLS policies are guard rails where you can define custom rules to access the database at the row level. They help you in cases where you might forget to do the checks in the app level. Furthermore, it reduces the database round trips when it comes to perform different CRUD operations. RLS should be handled via migations so that you can easily follow up the state of your database easily.

Although most time is spent on thinking of RLS as means of tightening the security of your database, it can cause massive performance downgrade to some of your queries. You can read more on how to improve your RLS policies here

Lastly, we can add indexes on the tables to improve the performance of our queries. The choice of your indexes depends on your use cases and the nature of your tables as well.

Adding a Subscription Service to a NextJS, Prisma & Upstash

Brighton Mboya — Tue, 30 Jan 2024 07:52:43 +0000

The most common business model in building a Saas is a subscription model where users pay a certain fee to use your service in a specified time interval. In this article, we will go through the process of adding a subscription service to a NextJS project and the best practices to follow once going into production.

Our Saas will be helping our users to get a daily dose of motivation quotes every morning on their email at a fee of say, $1 per month.

To create your project, paste this command on your terminal and choose Prisma as your ORM; you can opt-out of the rest of the tools. In case you're not familiar with create-t3-app, it is one of the easiest ways to start a nextJS app and add tools like Drizzle, Prisma, trpc, and tailwind. I will be using the Pages router in this article.

pnpm create t3-app@latest

Data Modeling

A good data modeling will make your application grow easier and managing your database even more seamless. Let's start by first adding the data modelling for our quotes to be sent to our users. Open the schema.prisma file located in your prisma directory and add the following. I will be using postgres but implementation in other databases will be fairly the same.

// schema.prisma file

model Quotes {
    name String
    id   Int    @id @default(autoincrement())
    body String
}

model Users {
    name          String
    email         String @unique
    id            Int    @id @default(autoincrement())
    payments      Payments[]
    subscriptions Subscriptions[]
}

On our users' side, we are recording their name, email, every payment they have ever paid, and their subscription status. Let's go ahead and add the last two

//schema.prisma 

model Payments {
    id        Int    @id @default(autoincrement())
    userId    Int
    amount    Float
    createdAt String
    User      Users  @relation(fields: [userId], references: [id])
}

model Subscriptions {
    id              Int     @id @default(autoincrement())
    userId          Int     @unique
    expiryDate      String
    subsribed       Boolean @default(false)
    daysWithService Int     @default(0)
    User            Users   @relation(fields: [userId], references: [id])
}

We are recording the payment details that we get from our payment provider to track when a particular user paid for a service in case they ask for a refund or whatnot. The subscription table is where we will check whether this user is currently subscribed to our service. The daysWithService column is what we will be using to count how many days (or any time interval) this user has used our service.

To deploy your database, you must configure your database URL depending on where you host your database. I won't go into the details of hosting your database in this article.

Recording Payments Details

For us to be able to receive money from our users, we need to set up our payment provider. There are different options depending on your location. If you're in US, UK, or Canada you can go ahead with Stripe, as it is fairly easy to integrate with different components and setting up webhooks is relatively easy. If you're in Africa I would recommend choosing DPO Payments as it is available in many countries as compared to Flutterwave and other providers. The choice you make here depends on your business requirements and where you are located.

All providers will allow you to configure a webhook that they can ping every time someone makes a payment to your account, so go ahead and implement that. Let's say your webhook URL is https://www/yourDomain.com/api/payments, go ahead and create a payment.ts file at the API directory of your application.

import { type NextApiRequest, type NextApiResponse } from "next";



function addMonth(dateObj: Date, num: number) {
  dateObj.setMonth(dateObj.getMonth() + num);
  const dateString = dateObj?.toISOString()?.split("T")[0];
  if (dateString) {
    return dateString.replace(/-/g, "/");
  }
  return "";
}

export default async function postRequest(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  if (req.method === "POST") {
    const data = req.body;



    try {
      // find the userId
      const userId = await prisma.users
        .findUnique({
          where: {
            email: data.email,
          },
        })
        .then((user) => {
          return user?.id as number;
        });

      // use the userId to insert it on the transaction table
      const date = new Date()
        ?.toISOString()
        ?.split("T")[0]
        ?.replaceAll("-", "/") as string;
      if (userId) {
        const newPayment = await prisma.payments.create({
          data: {
            userId: userId,
            amount: parseFloat(data.TransactionAmount),
            createdAt: date,
          },
        });


        // record the Subscription table
        // HANDLE WHEN A USER MAKES 2 PAYMENTS IN A ROW
        const nextMonth: string = addMonth(new Date(), 1);

        // check if the farmer is there in subscription table
        const subscribedUser = await prisma.subscriptions.findUnique({
          where: {
            userId: userId,
          },
        });

        if (subscribedUser) {
          const updatedSubscription = await prisma.subscriptions.update({
            where: {
              userId: userId,
            },
            data: {
              expiryDate: nextMonth,
              subsribed: true,
              daysWithService: subscribedUser.daysWithService + 31,
            },
          });
        } else {
          const newSubscription = await prisma.subscriptions.create({
            data: {
              expiryDate: nextMonth,
              userId,
              subsribed: true,
              daysWithService: 31,
            },
          });
        }


      } else {
        // probably the userId wasnt found and we can just record the number on the users table
        const newUser= await prisma.users.create({
          data: {
            email: data?.email,
            name: data?.CustomerName,
          },
        });
      }
    } catch (error) {
      console.log(error);
    }


    // make sure to send a respond back according to your payment provider

  }
}

What we did here is we took the response we got back from our payment provider, extracted the userId from the email that we got back and recorded the payments in our table as well as doing the subscription logic in our table. We also handled the case where the user has made multiple payments in a row on how it will affect the subscription. We also add daysWithService table as 31 meaning this user is subscribed to the service for the next month. Ensure you check what data shape your payment provider returns and adjust the above code accordingly.

Adding CRON Jobs with Upstash

The last piece of the puzzle is adding CRON jobs to our saas. The main point of adding the CRON jobs is to unsubscribe the user from getting our service once the subscription ends.

To achieve this, we will be using upstash Qstash Service. Go ahead and create an account and head over to Qstash in your dashboard. You will be prompted with UI to publish your messages. On the Endpoint section, add your URL https://www/yourDomain.com/api/updateSubscription, type Choose Once and specify every midnight, and click schedule. This will hit your specified endpoint every midnight and allow us to trigger a database update.

Go ahead and create a updateSubscription.ts file at the API folder.


import { type NextApiRequest, type NextApiResponse } from "next";

export default async function updatedSubscription(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  try {
    //go through the subscribers table and check if the subscription is still active
    //if it is not active, update the subscription status to false
    const currentSubscribers = await prisma.subscriptions.findMany({});

    //update where the daysWithService == 0 and cancels the days of Subscription
    const subscribers = await prisma.subscriptions.updateMany({
      where: {
        daysWithService: {
          equals: 0,
        },
      },
      data: {
        subsribed: false,
        daysWithService: 0,
      },
    });

    // if the daysOfService is not 0 then reduce the daysWithService by 1
    const updatingDays = currentSubscribers.forEach(async (sub) => {
      const { subsribed, daysWithService } = sub;
      if (subsribed && daysWithService > 0) {
        await prisma.subscriptions.update({
          where: {
            id: sub.id,
          },
          data: {
            daysWithService: (sub.daysWithService -= 1),
          },
        });
      }
    });

    res.status(200).json({ message: "Message Received" });
  } catch (cause) {
    res.status(500).json({ message: "Failed to send the message" });
    console.log(cause);
  }
}

Here, we go and update our subscription table according to the remaining days of service. If the daysOfService is less than or equal to zero, we set isSubscribed field to false meaning the user subscription has expired, otherwise we reduce the daysOfService by 1.

And those are all the pieces required to add a subscription service to a saas.

Hope you enjoyed it.

Group By, Grouping Sets, Cube, and Rollup Queries in SQL

Brighton Mboya — Mon, 06 Nov 2023 10:38:07 +0000

I came across these advanced queries in SQL when going through the Postgres Docs, and I couldn't wrap the concepts across my head easily. These queries are used to give you a different angle while processing data in SQL. This article will explain these queries in a fairly simple language as you were to explain to a five-year-old, and then we will go through a code example and where you can use these queries.

Explain like I am 5 years old ...
Now Imagine you have your different toys, cars, lego, and balls. And these toys are of different colors like blue, red, green etc.

Group By. Grouping is like putting all the toys of the same color together. So, you put all the red cars in one pile, all the blue cars in another pile, and so on. Group By helps you organize your toys by a specific characteristic, like color, so that you can see and count how many of each.

Grouping Set: Sometimes, you want to group your toys differently. For example, you may want to group them by color and type (cars and balls). So, you create multiple groups, like one for all the red cars, one for all the blue cars, one for all the red balls, and so on. Grouping sets allow you to do this and see the data from different angles.

Roll Up: Think of this like making a summary. You have your toys grouped by color, and you want to know how many toys you have in total for each color. So, you start with individual colors, like red and blue, and then add them up to get the total number of cars and balls. It's like rolling up the numbers from smaller to bigger groups to see the bigger picture.

Cube: This is like a 3D puzzle. You have toys grouped by color and type, but you also want to know the total count for combinations of these characteristics. It's like saying, "How many red cars do I have? How many blue balls do I have?" and so on. Cubes in PostgreSQL help you explore your data in all these different combinations.

Now we have that explanation out of the way, let's now deep dive in a code implementation. I will be using a GUI in performing the SQL queries, you can get your here if you're interested.

We will start by creating a table salaries and populate it with a few data.

CREATE TABLE salaries (

    id int,

    salary int,

    revised_salary int,

    old_salary  int,

    leave  int,

    joining_date date

);

insert into salaries values(10,5000,4000,1000,5,'2019-11-15');

insert into salaries values(10,6000,9000,2000,1,'2019-11-16');

insert into salaries values(10,7000,3000,4400,2,'2019-11-17');

insert into salaries values(20,8000,4000,6600,6,'2019-11-15');

insert into salaries values(20,9000,9400,8800,10,'2019-11-16');

insert into salaries values(20,2000,7800,9400,23,'2019-11-17');

insert into salaries values(30,4400,6600,4200,44,'2019-11-15');

insert into salaries values(30,1500,3600,4300,66,'2019-11-16');

insert into salaries values(30,2000,2600,4500,77,'2019-11-17');

Now using the select command we can see the data we inserted in the salaries table.

Now using the Group By command, we are going to group together the salary, revised_salary and the leave.

select id, sum(salary) as total_salary,
sum(revised_salary) as total_revised_salary,
sum(old_salary) as total_old_salary,
sum(leave) as total_leave
from salaries
GROUP BY id
ORDER BY id;

What's happening here is that we're selecting the salary, revised_salary, old_salary and leave and summing them up, then we want to organize the information by the names of the people (in this case, each name has an id), and finally we want to sort the information in alphabetical order and with that we use the order by clause.

Similarly, we can use the joining_date column together with the group by clause to generate a report.

select joining_date, sum(salary) as total_salary,
sum(revised_salary) as total_revised_salary,
sum(old_salary) as total_old_salary,
sum(leave) as total_leave
from salaries
GROUP BY joining_date
ORDER BY joining_date;

Grouping Set:

Now we can combine the above 2 queries into one query.

select id, joining_date, sum(salary) as total_salary,
sum(revised_salary) as total_revised_salary,
sum(old_salary) as total_old_salary,
sum(leave) as total_leave
from salaries
GROUP BY GROUPING SETS (id, joining_date)
ORDER BY id;

Cube:

Cube is mostly used for report generation and extends the Group By and Grouping Sets clauses. Cube(x,y,z) will give you all the grouping sets as follows: (X, Y, Z) (, Y, Z) (X, Y, ) (X, ,Y) (X) (Y) (Z) ().

In our example, we can create all the possible combinations of id and joining_date.

select id, joining_date, sum(salary) as total_salary,
sum(revised_salary) as total_revised_salary,
sum(old_salary) as total_old_salary,
sum(leave) as total_leave
from salaries
GROUP BY CUBE (id, joining_date)
ORDER BY id;

And if you have a hard time understanding the query, here is the explanation to a five year old. This is like making a big list of people where we want to see how much money they make, how their salary changed, and how many days they took off. We also want to know when they joined, so we're looking at that too. But we're not just looking at each person alone; we want to see the money stuff for each person and for when they joined, and even all the combinations of those. Then, we want to put the list in order by the names of the people. So, we can see all this information in different ways and in order, like in a big, organized list.

Roll Up.

ROLLUP lets you create hierarchical subtotals in your query results. It's like creating a summary report with subtotals at different levels of detail. For instance, you can use ROLLUP to get subtotals not just for individual combinations of id and joining_date, but also for higher-level groupings like the total salary for each id and a grand total for all the data. This helps you analyze and summarize salary information at various levels of grouping.

select id, joining_date, sum(salary) as total_salary,
sum(revised_salary) as total_revised_salary,
sum(old_salary) as total_old_salary,
sum(leave) as total_leave
from salaries
GROUP BY ROLLUP (id, joining_date)
ORDER BY 1, 2;

Hopefully, you found the article interesting and learned sth new. Give this article a like and feel free to follow me on Twitter.

Using Turso DB with NextJS

Brighton Mboya — Mon, 15 May 2023 09:33:39 +0000

Turso is the new database that allows you to deploy your database easily to the edge. It solves the co-location problem by replicating the database to different regions, and the replicas are always in sync with one primary. Turso is built on top of libSQL, an open-source, open-contribution of SQLite.

We will build a popular tourist destination app showing a list of popular tourist destinations. Check out the live link, and the source code is available here.

Using Turso with NextJS is quite easy, as the way you could use any other database. First things first, we need to install the Turso CLI. You can follow the instructions on installing the CLI from the documentation here. After that, we will start a new nextJS project. I prefer starting my next app using the Create-T3-App command, but you can still use the official nextJS installation command. Select TypeScript as the language of choice, and slam Yes when prompted to use Tailwind, coz why not.

npm create t3-app@latest

After installing the Turso CLI, we need to login. Turso will open up a new browser window where you will require to grant the Github Turso app some permissions to your account.

turso auth signup

After the login process completes, the CLI receives a token that identifies you and stores it in a local file. On macOS, the file is located in $HOME/Library/Application Support/turso. On Linux, it's $HOME/.config/turso. Some things to note about this token:

Do not share this token with anyone you don't trust fully; they can use it to work with Turso on your behalf.
The token is passed along with all backend API requests made by the CLI while logged in.
You can print it using the command. turso auth token.
It expires after 7 days. After that, you must log in again with turso auth login.

After the auth part, it is time to create our database and seed some data into it. You can create the database using the turso db create command.

turso db create [DATABASE-NAME]

This will create a new database that is located geographically closer to you. Then start interacting with the database via the shell command using this command.

turso db shell [DATABASE-NAME]

This will open a SQL shell where you can interact with the database you just created. Paste this command which will create the popular_destinations table, and from there, it will seed the database with some data.

-- create the popular destinations table
CREATE TABLE popular_destinations (
    id SERIAL PRIMARY KEY,
    country VARCHAR(255) NOT NULL,
    name VARCHAR(255) NOT NULL,
    location VARCHAR(255) NOT NULL,
    image_url VARCHAR(255) NOT NULL
);

-- Seeding up the database
INSERT INTO popular_destinations (country, name, location, image_url)
VALUES
    ('United States', 'New York City', 'New York', 'https://images.unsplash.com/photo-1485871981521-5b1fd3805eee?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8M3x8bmV3JTIweW9ya3xlbnwwfDB8MHx8&auto=format&fit=crop&w=500&q=60');
INSERT INTO popular_destinations (country, name, location, image_url)
VALUES
    ('France', 'Paris', 'Ile-de-France', 'https://images.unsplash.com/photo-1502602898657-3e91760cbb34?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8M3x8cGFyaXN8ZW58MHwwfDB8fA%3D%3D&auto=format&fit=crop&w=500&q=60');
INSERT INTO popular_destinations (country, name, location, image_url)
VALUES
    ('Japan', 'Tokyo', 'Kanto Region', 'https://images.unsplash.com/photo-1578469645742-46cae010e5d4?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8NXx8a3lvdG98ZW58MHwwfDB8fA%3D%3D&auto=format&fit=crop&w=500&q=60');
INSERT INTO popular_destinations (country, name, location, image_url)
VALUES
    ('Australia', 'Sydney', 'New South Wales', 'https://images.unsplash.com/photo-1526958977630-bc61b30a2009?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=870&q=80');

INSERT INTO popular_destinations (country, name, location, image_url)
VALUES
('London', 'UK', 'United Kingdom', 'https://images.unsplash.com/photo-1513635269975-59663e0ac1ad?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8Mnx8bG9uZG9ufGVufDB8fDB8fA%3D%3D&auto=format&fit=crop&w=500&q=60');


-- Quitting the shell
.quit

Now we need to get the database URL and the authentication token of the database and configure it on the .env file. At the root of the project, create a .env file and paste these variable names.

url=YOUR_DATABASE_URL
authToken=YOUR_AUTH_TOKEN

To get the URL, run this command

turso db show [DATABASE-NAME] --url

Then create the authentication token,

turso db show [DATABASE-NAME] --url

Lastly, we need to install a package called libsql/client which will allow us to interact with the Turso database in our application.

npm install @libsql/client

Now enough of the terminal thing, and let's write some code. Start the dev server by running npm run dev and open up localhost:3000.

At the src folder, create a folder named db, and create a turso.ts file. Paste this code in the file, this code imports the createClient from libsql/client and configures it so that we can make SQL queries to our database easily.

import { createClient } from "@libsql/client/web";

export default function Turso() {
    const config = {
        url: process.env.url,
        authToken: process.env.authToken,
    }

    return createClient(config);
}

Then create another folder called hooks and create a file called useFetch.ts this file will allow us to make queries to our database and will return as a loading and error state as well as the data that we will receive from the database.

import { useEffect, useState } from "react";
import axios from "axios";
import type { QueryResult } from "../pages";

export type fetchResponse = {
    data: QueryResult[];
    loading: boolean;
    error: string;
};


const useFetch = (url: string): fetchResponse => {
    const [data, setdata] = useState<QueryResult[]>(null);
    const [loading, setloading] = useState<boolean>(true);
    const [error, seterror] = useState<string>("");
    useEffect(() => {
        axios.get(url).then((res): void => {
            setdata(res.data as QueryResult[]);
            setloading(false);
        })
            .catch((err: unknown) => {
                if (err instanceof Error) {
                    seterror(err.message);
                    setloading(false);
                }
            });
    }, [url]);
    return { data, loading, error };
};

export default useFetch;

Then add a file in the src/api folder called turso.ts , [pardon my file naming skills]. This file will include a query that queries the popular_destination table and return the data.

import Turso from '../../db/turso';
import type { NextApiRequest, NextApiResponse } from 'next';

export default async function Handler(
    req: NextApiRequest,
    res: NextApiResponse
) {
    try {
        const client = Turso();
        const response = await client.execute("SELECT * FROM popular_destinations;");
        const posts = response.rows.map((post) => {
            return {
                id: post.id,
                country: post.country,
                name: post.name,
                location: post.location,
                image_url: post.image_url,
            }
        })

        res.status(200).json(posts);


    } catch (error: unknown) {
        console.log(error);
        if (error instanceof Error) {
            res.status(500).json({ message: error.message });
            return;
        }
    }
}

Now finally, on the index.tsx page. Here we will create a card component and style it with some tailwind. Then we will fetch the data using our useFetch hook and style the results using grid.

import { useState } from "react";
import Image from "next/image";
import useFetch from "../hooks/useFetch";
import type { fetchResponse } from "../hooks/useFetch";

export type QueryResult = {
  id: number | null;
  country: string;
  name: string;
  location: string;
  image_url: string;
};

function cn(...classes: string[]) {
  return classes.filter(Boolean).join(" ");
}

export default function MyPage() {
  const [isLoading, setLoading] = useState(true);
  const { data, loading, error }: fetchResponse = useFetch("/api/turso");

  return (
    <main className="font-montserrat flex items-center justify-center">
      <section>
        <h3 className="text-2xl font-medium ">Some Fancy Destinations</h3>
        <p className="text-base">
          List of Vacation Homes to Enjoy once in a while
        </p>

        {loading && <p>Loading...</p>}
        {error && <p>Error countered while fetching: {error}</p>}
        <div className="flex flex-col items-center justify-center gap-5 md:grid md:grid-cols-2 lg:grid-cols-3">
          {data?.map((item: QueryResult) => (
            <div
              className="w-[300px] relative flex flex-col items-center justify-center p-4 m-4 bg-white rounded-xl shadow-md hover:shadow-lg transition duration-500 ease-in-out transform hover:-translate-y-1 hover:scale-110"
              key={item.image_url}
            >
              <Image
                src={item.image_url}
                alt="Picture of the author"
                width={350}
                height={200}
                priority={false}
                onLoadingComplete={() => setLoading(false)}
                draggable={false}
                className={cn(
                  "object-cover object-top duration-700 ease-in-out border-[1px]",

                  isLoading
                    ? "scale-110 blur-2xl grayscale bg-blue-300 "
                    : "scale-100 blur-0 grayscale-0"
                )}
              />

              <h3 className="text-lg ">
                {item.name}, {item.location}
              </h3>
            </div>
          ))}
        </div>
      </section>
    </main>
  );
}

And that's it; you have created the Turso database, seeded the database, and queried it to your front-end application.

If you enjoy this, plz give it a thumbs up and check me out on Twitter.

Turso, The Data Edge

Brighton Mboya — Thu, 11 May 2023 09:35:02 +0000

So you probably have heard about the Edge thing everyone has been talking about in the front-end world. In case you haven't heard of it, the Edge is two things. The first one means placing compute closest to your user, and the second one is runtime, a distributed network of v8 engines that waits to execute your code and then throws it away. We will be looking at the first one in this article.

So, there are a lot of solutions right now that can help you bring the compute closer to your users, these include Vercel Edge Functions or Cloudflare Functions. But when it comes to Databases at the edge the problem becomes too hard to solve or once you crack the cheat code, it becomes very expensive to operate. This is mostly because of the co-location problem where it is way cheaper to make the round trip to the databases when it close to the server rather than when it is closer to the user.

We can check this out by comparing different databases using this Vercel tool. This tools lets you to choose different databases and lets you compare the latency of each on of them. But first, let's clarify a few words used on these graphs. The first one is Regional latency, which is the latency when the Edge functions are executed closer to the Database, and the second one is Global latency which is when the query is executed closest to the user. The latter takes into account the total round trip of the queries made.

Now lets choose Planetscale DB and make a query from Toronto Canada, which is pretty close to us-east1 where the database is hosted (according to the Vercel tool). I am not currently in Canada, so I took this screenshot from this original article.

Now I leave in Tanzania, East Africa so let's see how making the same query will affect me.

Well as you can see the amount of latency and the total time it takes to query the database on my end. My internet speed is roughly 17Mbps, which is quite fast enough and still I get that amount of latency. It is good to note here that is way “fast” to make the query using the Regional edge functions as compared to the Global one when I am querying it from Tanzania. Check the first graph, it doesn’t matter whether you make the query using the global or the regional edge functions, you get roughly the same result.

Now enter the Data Edge. I found this cool database called Turso, where the creators call it the Data Edge. It solves the problem of colocation by making replicas close to the user, and the replica always are in sync with one primary. This means that instead of manually configuring the database location and routing it there, you just let the query go to the nearest Database, which is closer to the user. Now we can check again how the latency behaves from the two places.

The first one is Querying the Data Edge from Toronto

And the second one is querying the Data Edge from Tanzania

As you can see that it’s way cheaper to query the database using the global edge functions than the regional one. And you don’t even need to manually set up the location for each route, you just let the request go to the nearest replica closest to the user and Turso will handle everything for you.

What’s happening here is that for the regional edge function, you go to us-east where the edge function runs. That edge function calls the Turso instance in the us-east, and you get the response back. For the global edge function, it runs to the nearest region (in my case Cape Town) and then calls the Turso instance in Johannesburg and I get the response back. You can check where the Vercel edge function routes you to by running this command on the terminal

curl -v 'https://edge-functions-add-header.vercel.app/_next/data/uZdXi2GsLkZMAjEssKNy0/index.json' 2>&1 | grep "x-vercel-id" | awk '{print $3}'

You will then get sth that looks similar to this,

cpt1:cpt1::sr2mg-1683660654794–15bb5b6f40c1

You only need to interpret the first few characters in this case, cp1 which is Cape Town. You can find the list of regions from this list below.

arn1 eu-north-1 Stockholm, Sweden bom1 ap-south-1 Mumbai, India bru1 eu-central-1 Brussels, Belgium cdg1 eu-west-3 Paris, France cle1 us-east-2 Cleveland, USA cpt1 af-south-1 Cape Town, South Africa dub1 eu-west-1 Dublin, Ireland fra1 eu-central-1 Frankfurt, Germany gru1 sa-east-1 São Paulo, Brazil hkg1 ap-east-1 Hong Kong hnd1 ap-northeast-1 Tokyo, Japan iad1 us-east-1 Washington, D.C., USA icn1 ap-northeast-2 Seoul, South Korea kix1 ap-northeast-3 Osaka, Japan lhr1 eu-west-2 London, United Kingdom pdx1 us-west-2 Portland, USA sfo1 us-west-1 San Francisco, USA sin1 ap-southeast-1 Singapore syd1 ap-southeast-2 Sydney, Australia.

Now if you are an average developer like me you might look at these numbers and say “just another few ms optimization” and probably you’re right, probably these optimizations mean nothing to you and your users can afford these delay and your business will still do just fine without any changes. But if you’re a dev who cares about perfomance who cares that your users have the best smooth experience they can possibly get then you might want to look into this database.

The application of this Data Edge (Turso DB) includes an E-commerce application where you want your products to load as fast as possible so that users are hooked up to your database and outperform the competition. It can include applications that a small data change needs to reflect as fast possible to the user, this includes an application that includes stock listings and financial information, Detection warning systems, and even IoT systems. These niche of applications will really benefits from this new Database infra and gets that smooth experience that has been missing on the other side of the web.

As of this writing, Turso includes replicas in 32 locations and I really hope that new locations will be added in the near future. You can check out the docs and play around it more.

Getting Started in React Query.

Brighton Mboya — Sat, 19 Nov 2022 16:04:02 +0000

React Query is by far hands-down the best library for data-fetching for React Apps. ~Tanner Linsley.

Mental Model on react-query

In this series, we will be looking at how React Query can help you solve all of your server state problems. React Query is a library that helps you manage server state to your React Applications. Client State is very different from Server State and its good to establish a proper mental model before we even get to React Query.
Suppose you have a hamburger menu that controls if a sidebar menu is opened or not, this state can easily be controlled by built-in solution in React, React.useState(). Server State however is much more different. To give an example consider you have a sign up form with a button. Once this button is clicked, it should send the user information to a data base. What happens when the user's network suddenly drops when they click the button, what happens if the user clicks the button more than once. These are very simple mutation scenarios that you need to think of while writing your React Apps. With React Query all these situations and many more are covered.
With the proper mental model in mind, let's go ahead and install the library. This assumes you have a react app already running. Paste this command in your terminal or cmd.
npm i @tanstack/react-query.

Query Client and Query Client Provider

Another powerful feature of the library is the Query Client, which interacts with the cache for your data, and the Query Client Provider which should be wrapped in the top level of your app i.e the App.tsx file.

import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

const queryClient = new QueryClient()

function App() {
  return <QueryClientProvider client={queryClient}>
       <MyComponent/>
</QueryClientProvider>
}

What happened here is that we have created the queryClient and we have wrapped MyComponent using the QueryClientProvider and providing the client.

Then we need to define the MyComponent function. We will now use useQuery from react-Query. This hook accepts three arguments or so. The first one is the query key, second is the function to fetch the data, and the last is the option.

The queryKey: This is a unique identifier that will tell React-Query to differentiate your data. When this key changes, React Query will refetch your data again. It is good to think of this key as the key you pass to the dependency array in React.useEffect(). It is an array and anything can be placed in this array, i.e strings, objects, etc. E.g
const queryKey = ['users', {id, location}]
The queryFunction. This is a function which returns a promise that is used to fetch the data. You can use the built in fetch() function or any other fetching library of your choice e.g Axios. as long as it returns a promise, it should work well. E.g

const fetchUsers = () => return fetch("https://dev.to/users").then(res => res.json)

The options: This is an object where you can specify different options to your query. This include staleTime (how long does the query considered fresh until fetched again), initialData (the data passed to your query before fetched), onError (a call back function that gets executed once the query fails) etc. To get more options have a look at the docs.

With that in mind, let's use a dummy api to fetch a list of random employees.

function MyComponent() {
  const {data, isLoading, isError} = useQuery(["employees"], () => {
    return fetch("https://dummy.restapiexample.com/api/v1/employees").then((res) =>
      res.json()
    );
  });


  if (isLoading) return <p>Loading ...</p>
  if (isError) return <p>{Error.message}</p>



  console.log(data);
  return <ul>
    {data.data.map((data) => (
      <li>{data.employee_name}</li>
    ))}
  </ul>;
}

What happened here is that the useQuery gives us back a couple of things and we used object destructing to get the ones we want. Now if the query is loading (isLoading) we show a loading state and likewise for the error. On the return block we accessed the data property which our api gives us and we displayed the employee_name. You can check the console output to get a sense on why we traversed the data this way.

And there you have it, you have successfullymade your first query. To get more in depth, check out the docs and you can go ahead and play with the sandbox.

If you found this helpful, give it a like and follow me on twitter