Forem: Rakesh Potnuru

Integrating DeepSeek API in NextJs and ExpressJs App

Rakesh Potnuru — Wed, 12 Feb 2025 18:53:21 +0000

AI is an infinity stone. Learn to use its power, you can do wonders. In this guide, build a personal accountant with DeepSeek API and a sample project.

The Project

I've created a sample project called "Finance Tracker" for this tutorial. It lets you record your financial transactions. The front end is built with NextJs and the back end is with tRPC (express adapter) and Postgres database with drizzle ORM. But you don't need to know tRPC to continue with this tutorial. (In case you want to learn tRPC, check out Build a Full-Stack App with tRPC and Next.js App Router series.)

Github repo: https://github.com/itsrakeshhq/finance-tracker

Let's add a chatbot to the product that acts as our personal accountant.

Backend

Getting DeepSeek API key

As you might already know, DeepSeek went pretty viral when it was launched because of comparable performance to OpenAI yet only a fraction of the cost. This resulted in massive downtimes since its launch. I've been trying to use their API for a long time but no luck. (If you can get it, then please continue with it.)

So instead of using API from the DeepSeek API platform directly, we can use it from OpenRouter. OpenRouter gives access to various AI models from various providers. So if one provider goes down, it switches to another one.

API Integration

Put the API key you got from above in backend/.env:

DEEPSEEK_API_KEY=your_deepseek_api_key

Since DeepSeek API is compatible with OpenAI SDK, let's install that:

yarn add openai

Create src/modules/ai/ai.controller.ts. This is where will write AI accountant code. First, create OpenAI client:

export default class AiController {
  private readonly openai: OpenAI;

  constructor() {
    this.openai = new OpenAI({
      // baseURL: "https://api.deepseek.com" // if using DeepSeek API key
      baseURL: "https://openrouter.ai/api/v1",
      apiKey: process.env.DEEPSEEK_API_KEY,
    });
  }
}

Here we've initialized Openai client.

Note: Make sure to use appropriate baseURL and apiKey based on what you are using - DeepSeek or OpenRouter.

Here's how I designed the accountant:

Fetch transactions from DB.
Include in the prompt.
Answer user queries based on transactions.
Stream response.

...
  async accountant(req: Request, res: Response) {
    try {
      const { query } = req.body;

      if (!query) {
        return res.status(400).json({ error: "Query is required" });
      }

      const userId = req.user.id;

      const data = await db
        .select()
        .from(transactions)
        .where(eq(transactions.userId, userId));

      if (data.length === 0) {
        return res.status(400).json({ error: "No transactions found" });
      }

      const formattedTxns = data.map((txn) => ({
        amount: txn.amount,
        txnType: txn.txnType,
        summary: txn.summary,
        tag: txn.tag,
        date: txn.createdAt,
      }));

      const prompt = `
    You are a personal accountant. You are given a list of transactions. You need to answer user query based on the transactions. 

    YOU MUST KEEP THESE POINTS IN MIND WHILE ANSWERING THE USER QUERY:
    1. You must give straight forward answer.
    2. Answer like you are talking to the user. 
    3. You must not output your thinking process and reasoning. This is very important.
    4. Answer should be in markdown format.

    Transactions: ${JSON.stringify(formattedTxns)}
    Currency: $ (USD)

    User Query: ${query}
    `;

      const response = await this.openai.chat.completions.create({
        model: "deepseek/deepseek-chat",
        messages: [{ role: "user", content: prompt }],
        stream: true,
      });

      res.writeHead(200, {
        "Content-Type": "text/plain",
        "transfer-encoding": "chunked",
      });

      for await (const chunk of response) {
        if (chunk.choices[0].finish_reason === "stop") {
          break;
        }

        res.write(chunk.choices[0].delta.content || "");
      }

      res.end();
    } catch (error) {
      console.error({ error });
      if (!res.headersSent) {
        res.status(500).json({ error: "Internal server error" });
      }
    }
  }
...

Note: This is just to give an idea. In real projects it's not ideal to fetch all transactions from db for every query. To provide context to AI models, you can create embeddings. DeepSeek currently does not support embeddings.

As you can see all we did was write a prompt and provide as much context as possible to get accurate results. Then we are sending the response as a stream instead of waiting for the whole response which might take a lot of time.

And then expose this controller in a route:

// src/index.ts

...
app.use(express.json());
app.post("/ai", authMiddleware, (req, res) =>
  new AiController().accountant(req, res)
);
...

authMiddleware protects the endpoint, so only logged-in users can access it. You can find the implementation in src/middleware/auth-middleware.ts.

That's all we need from the backend.

Frontend

In the front end, let's create a chat widget. Switch to frontend/ folder.

Create chat.tsx in src/components/modules/dashboard.

Chat UI

Then create a chat box UI with shadcn popover component.

// chat.tsx

export default function Chat() {
  const [conversation, setConversation] = useState<
    {
      role: "user" | "assistant";
      content: string;
    }[]
  >([
    {
      role: "assistant",
      content: "Hello, how can I help you today?",
    },
  ]);
  const [liveResponse, setLiveResponse] = useState<string>("");
  const [isThinking, setIsThinking] = useState<boolean>(false);

  // Auto scroll to bottom when new message is added
  const scrollRef = useRef<HTMLDivElement>(null);
  useEffect(() => {
    if (scrollRef.current) {
      scrollRef.current.scrollIntoView({ behavior: "smooth" });
    }
  }, [conversation, liveResponse]);

  return (
      <Popover>
      <PopoverTrigger className="absolute right-4 bottom-4" asChild>
        <Button size={"icon"} className="rounded-full">
          <BotMessageSquareIcon className="w-4 h-4" />
        </Button>
      </PopoverTrigger>
      <PopoverContent align="end" className="w-[500px] h-[600px] p-0 space-y-4">
        <h1 className="text-xl font-bold text-center p-4 pb-0">
          Personal Accountant
        </h1>
        <hr />
        <div className="pt-0 relative h-full">
          <div className="flex flex-col gap-2 h-[calc(100%-150px)] overflow-y-auto px-4 pb-20">
            {conversation.map((message, index) => (
              <div
                key={index}
                className={cn("flex flex-row gap-2 items-start", {
                  "rounded-lg bg-muted p-2 ml-auto flex-row-reverse":
                    message.role === "user",
                })}
              >
                {message.role === "assistant" && (
                  <BotMessageSquareIcon className="w-4 h-4 shrink-0 mt-1.5" />
                )}
                {message.role === "user" && (
                  <UserRoundIcon className="w-4 h-4 shrink-0 mt-1" />
                )}
                <Markdown className="prose prose-sm prose-h1:text-xl prose-h2:text-lg prose-h3:text-base">
                  {message.content}
                </Markdown>
              </div>
            ))}
            {isThinking && (
              <div className="flex flex-row gap-2 items-center">
                <BotMessageSquareIcon className="w-4 h-4" />
                <p className="animate-pulse prose prose-sm">Thinking...</p>
              </div>
            )}
            {liveResponse.length > 0 && (
              <div className="flex flex-row gap-2 items-start">
                <BotMessageSquareIcon className="w-4 h-4 shrink-0 mt-1.5" />
                <Markdown className="prose prose-sm prose-h1:text-xl prose-h2:text-lg prose-h3:text-base">
                  {liveResponse}
                </Markdown>
              </div>
            )}
            <div ref={scrollRef} />
          </div>
          <hr />
         </div>
      </PopoverContent>
    </Popover>
  );
}

Form

Now create a form to handle user input:

const formSchema = z.object({
  message: z.string().min(1),
});

export default function Chat() {
...
  const form = useForm<z.infer<typeof formSchema>>({
    resolver: zodResolver(formSchema),
    defaultValues: {
      message: "",
    },
  });

  ...
      <hr />
          <div className="absolute bottom-20 left-0 right-0 p-4 w-full">
            <Form {...form}>
              <form
                onSubmit={form.handleSubmit(onSubmit)}
                className="flex flex-row gap-2"
              >
                <FormField
                  control={form.control}
                  name="message"
                  render={({ field }) => (
                    <FormItem className="flex-1">
                      <FormControl>
                        <Input placeholder="Ask me anything..." {...field} />
                      </FormControl>
                      <FormMessage />
                    </FormItem>
                  )}
                />
                <Button size={"icon"} type="submit">
                  <SendIcon className="w-4 h-4" />
                </Button>
              </form>
            </Form>
          </div>
    ...
...

Submit handler

Finally, implement the submit handler. As I said above, we are sending responses in stream, so it's better if also show the response as it is coming.

...
  const onSubmit = async (data: z.infer<typeof formSchema>) => {
    setIsThinking(true);
    setConversation((prev) => [
      ...prev,
      { role: "user", content: data.message },
    ]);
    form.reset();

    let liveResponse = "";
    try {
      const response = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/ai`, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        credentials: "include",
        body: JSON.stringify({
          query: data.message,
        }),
      });

      const reader = response.body?.getReader();
      const decoder = new TextDecoder();

      setIsThinking(false);
      if (!reader) return;

      while (true) {
        const { done, value } = await reader.read();
        if (done) break;

        const text = decoder.decode(value, { stream: true });

        liveResponse += text;
        setLiveResponse(liveResponse);
      }

      setConversation((prev) => [
        ...prev,
        { role: "assistant", content: liveResponse },
      ]);
    } catch (error) {
      console.error(error);
    } finally {
      setIsThinking(false);
      setLiveResponse("");
    }
  };
...

Note: Make sure to set NEXT_PUBLIC_API_URL in .env.local

That's it!

If you don't want to deal with all this, you can also use Vercel's AI SDK which has all the parts you need.

Feel free to ask any questions in the comments below. Follow for more 🎸🎸🎸!

Email Verification System in Next.js and tRPC with Resend

Rakesh Potnuru — Mon, 03 Feb 2025 19:17:29 +0000

Published from Publish Studio

In the last two posts from the series "Build a Full-Stack App with tRPC and Next.js App Router", I shared a lot about authentication and authorization. But I left out one crucial part which is verifying user email upon sign up.

We have to make sure the email belongs to that user only and is not fake. For this, we are going to send an OTP to the given email after signup and if the OTP sent by the user is valid, set the email verified to true.

As usual, the project remains same - Finance Tracker (GitHub repo).

Backend

First, add emailVerified field to user schema:

// backend/src/modules/user/user.schema.ts

export const users = pgTable("users", {
...
  emailVerified: boolean("email_verified").default(false),
...
});

Push changes to the database:

yarn drizzle-kit push

Set up Resend

We are going to use Resend to send emails. One of the reasons I'm recommending Resend is it's a lot easier to set up and no verifications shit like SendGrid. The only thing you need to verify is your domain.

Sign up for a free Resend account.
Verify your domain
Get Resend API key

Modify .env:

RESEND_API_KEY=your_resend_api_key
EMAIL_FROM="John Doe <noreply@example.com>"

Install Resend Node.js SDK:

yarn add resend

Create src/utils/resend.ts and export resend client for use anywhere in our code:

import { Resend } from "resend";

export const resend = new Resend(process.env.RESEND_API_KEY);

Implement send OTP email

Inside modules/auth/auth.service.ts, write a function to send an email with OTP. We can generate a random OTP with Math.floor(100000 + Math.random() * 900000). Store this OTP in Redis and set your desired expiration time.

// src/modules/auth/auth.service.ts

  async sendOtpEmail(email: string) {
    const otp = Math.floor(100000 + Math.random() * 900000);

    try {
      await redis.set(`otp:${email}`, otp, "EX", 5 * 60); // 5 minutes

      await resend.emails.send({
        from: process.env.EMAIL_FROM!,
        to: email,
        subject: "OTP to verify your email",
        text: `Your OTP is ${otp}. It will expire in 5 minutes.`,
      });

      return {
        success: true,
      };
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Something went wrong",
      });
    }
  }

Now, it's up to you when you want your users to verify their - 1. Right after sign up or 2. Let users experience the product first and limit how long and what they can access the product based on email verification.

For now, let's ask for OTP right after signing up. So put in register method:

// src/modules/auth/auth.service.ts
...
  async register(data: typeof users.$inferInsert) {
...
      const newUser = await db
        .insert(users)
        .values({
          email,
          password: hashedPassword,
        })
        .returning();

      await this.sendOtpEmail(email); // <---- here

      return {
        success: true,
        user: newUser,
      };
...
  }
...

Implement Verify OTP

Verifying involves a few steps. Here also you can make a choice - 1. Auto-login user after verifying OTP or 2. Redirect to login. Auto-login might be a better choice in terms of UX.

Steps:

Check user entered OTP against stored OTP.
Check if the user exists and set emailVerified=true.
Auto-login user.

// src/modules/auth/auth.service.ts

  async verifyOtp(email: string, otp: string) {
    try {
      const savedOtp = await redis.get(`otp:${email}`);

      if (savedOtp !== otp) {
        throw new TRPCError({
          code: "UNAUTHORIZED",
          message: "OTP expired or invalid",
        });
      }

      await redis.del(`otp:${email}`);

      const user = (
        await db.select().from(users).where(eq(users.email, email)).limit(1)
      )[0];

      if (!user) {
        throw new TRPCError({
          code: "NOT_FOUND",
          message: "User not found",
        });
      }

      await db
        .update(users)
        .set({ emailVerified: true })
        .where(eq(users.id, user.id));

      const accessToken = this.createAccessToken(user.id);
      const refreshToken = this.createRefreshToken(user.id);

      await redis.set(
        `refresh_token:${refreshToken}`,
        user.id,
        "EX",
        7 * 24 * 60 * 60 // 7 days
      );

      await redis.sadd(`refresh_tokens:${user.id}`, refreshToken);
      await redis.expire(`refresh_tokens:${user.id}`, 7 * 24 * 60 * 60); // 7 days

      await redis.set(
        `user:${user.id}`,
        JSON.stringify(user),
        "EX",
        7 * 24 * 60 * 60
      ); // 7 days

      return {
        accessToken,
        refreshToken,
      };
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Something went wrong",
      });
    }
  }

Now, create verify OTP handler in the controller:

// src/modules/auth/auth.controller.ts

  async verifyOtpHandler(data: { email: string; otp: string }, ctx: Context) {
    const { email, otp } = data;

    const { accessToken, refreshToken } = await super.verifyOtp(email, otp);

    const cookies = new Cookies(ctx.req, ctx.res, {
      secure: process.env.NODE_ENV === "production",
    });
    cookies.set("accessToken", accessToken, { ...accessTokenCookieOptions });
    cookies.set("refreshToken", refreshToken, {
      ...refreshTokenCookieOptions,
    });
    cookies.set("logged_in", "true", { ...accessTokenCookieOptions });

    return { success: true };
  }

Also, create a resend OTP email handler to give another chance to user in case the previous email failed to deliver:

  async resendOtpHandler(email: string) {
    return await super.sendOtpEmail(email);
  }

As a final step, create routes for these two handlers:

// src/modules/auth/auth.routes.ts

...
  verifyOtp: publicProcedure
    .input(
      z.object({
        otp: z.string().length(6),
        email: z.string(),
      })
    )
    .mutation(({ input, ctx }) =>
      new AuthController().verifyOtpHandler(input, ctx)
    ),

  resendOtp: publicProcedure
    .input(
      z.object({
        email: z.string().email(),
      })
    )
    .mutation(({ input }) =>
      new AuthController().resendOtpHandler(input.email)
    ),
...

Backend part is done!

Frontend

All we have to do on the front end is add another step to the sign-up flow for OTP verification.

Before that, shadcn-ui has a nice UI component for OTP input. Let's install that:

npx shadcn@latest add input-otp

The way I approach this is to create a state for the step:

const [step, setStep] = useState<"email" | "otp">("email");

So, after the user submits the sign-up form, show them the OTP form. So let's create another form in register-form.tsx.

// src/components/modules/auth/register-form.tsx

const otpFormSchema = z.object({
  otp: z.string().min(6, {
    message: "Your one-time password must be 6 characters.",
  }),
});

export default function RegisterForm() {
  const [step, setStep] = useState<"email" | "otp">("email");
  const [email, setEmail] = useState(""); // <--- save email after sign up

  const { mutateAsync: register, isLoading } = trpc.auth.register.useMutation({
    onSuccess: () => {
      setStep("otp"); // <--- change step to otp on register success
    },
  });

  const onRegisterSubmit = async (data: z.infer<typeof formSchema>) => {
    setEmail(data.email); // <--- set email to use in otp step
    ...
  };

  const { mutateAsync: verifyOtp, isLoading: isVerifyingOtp } =
    trpc.auth.verifyOtp.useMutation({
      onSuccess: () => {
        router.replace("/login");
      },
    });

  const otpForm = useForm<z.infer<typeof otpFormSchema>>({
    resolver: zodResolver(otpFormSchema),
    defaultValues: {
      otp: "",
    },
  });

  const onOtpSubmit = async (data: z.infer<typeof otpFormSchema>) => {
    try {
      await verifyOtp({ ...data, email });
    } catch (error) {
      console.error(error);
    }
  };

  return (
    <Card>
      <CardHeader>
        <CardTitle>Create an account</CardTitle>
      </CardHeader>
      {step === "email" && (
      // sign up form
      )}
      {step === "otp" && (
        // otp form
        <Form {...otpForm}>
          <form onSubmit={otpForm.handleSubmit(onOtpSubmit)}>
            <CardContent className="space-y-4">
              <FormField
                control={otpForm.control}
                name="otp"
                render={({ field }) => (
                  <FormItem>
                    <FormLabel>One-Time Password</FormLabel>
                    <FormControl>
                      <InputOTP maxLength={6} {...field}>
                        <InputOTPGroup>
                          <InputOTPSlot index={0} />
                          <InputOTPSlot index={1} />
                          <InputOTPSlot index={2} />
                          <InputOTPSlot index={3} />
                          <InputOTPSlot index={4} />
                          <InputOTPSlot index={5} />
                        </InputOTPGroup>
                      </InputOTP>
                    </FormControl>
                    <FormDescription>
                      Please enter the one-time password sent to your email.
                    </FormDescription>
                    <FormMessage />
                  </FormItem>
                )}
              />
            </CardContent>
            <CardFooter>
              <Button
                type="submit"
                className="w-full"
                disabled={isVerifyingOtp}
              >
                Submit
              </Button>
            </CardFooter>
          </form>
        </Form>
      )}
    </Card>
  );
}

That's it! Adding email verification with OTP is that simple.

I hope you enjoyed yet another tutorial in Next.js and tRPC series. If so follow for more like this 💯.

Socials

Cookie-Based Authentication in Nextjs App Router Application

Rakesh Potnuru — Sat, 25 Jan 2025 12:24:44 +0000

Published from Publish Studio

In the previous article "Implementing Cookie-Based JWT Authentication in a tRPC Backend", I shared how to secure the backend built with tRPC. Now it's time to secure the front end built with Next.js.

Adding authentication to Next.js is a piece of cake. Thanks to Next.js middleware, it's easier than ever to protect endpoints.

This is part 4 of the "Building a Full-Stack App with tRPC and Next.js" series. I recommended reading the first 3 parts if you haven't to better understand this part.

Let's learn how to secure our Finance Tracker (GitHub repo) frontend.

Enable Credentials

If you remember from the previous article, we are using cookie-based authentication. So whenever we log in, auth tokens are sent in response headers and the browser automatically stores them in cookies.

But before we do that, we have to enable credentials in the tRPC client, so that browser knows it has to send cookies in network requests.

Add fetch method and set credentials: "include"

// src/lib/providers/trpc.tsx

const trpcClient = trpc.createClient({
  transformer: superjson,
  links: [
    loggerLink({
      enabled: () => process.env.NODE_ENV === "development",
    }),
    httpBatchLink({
      url: process.env.NEXT_PUBLIC_TRPC_API_URL,
      fetch: (url, options) => { // <--- add fetch method
        return fetch(url, {
          ...options,
          credentials: "include", // <--- set this
        });
      },
    }),
  ],
});

Now cookies will be sent in all requests.

Similarly, do this in the backend too.

// src/index.ts

app.use(
  cors({
    origin: "http://localhost:3000", // we need to specify origins in order for this to work, wildcard "*" doesn't work
    credentials: true, // <--- here
  })
);

Now backend will allow requests containing cookies.

Create Login and Register Pages

Implement register

Since auth tokens are sent only after logging in, after registration, redirect the user to the login page.

This is how I usually structure my Next.js projects.

.
└── src/
    ├── app/
    │   ├── (auth)/
    │   │   ├── login/
    │   │   │   └── page.tsx
    │   │   └── register/
    │   │       └── page.tsx
    │   └── layout.tsx
    └── components/
        └── modules/
            └── auth/
                ├── login-form.tsx
                └── register-form.tsx

app/(auth)/layout.tsx shares a common layout for login and register pages.

export default function AuthLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <main className="flex items-center justify-center min-h-screen">
      <div className="w-full max-w-md">{children}</div>
    </main>
  );
}

// app/(auth)/register/page.tsx

import RegisterForm from "@/components/modules/auth/register-form";
import { Metadata } from "next";

export const metadata: Metadata = {
  title: "Register | Finance Tracker",
};

export default function LoginPage() {
  return <RegisterForm />;
}

// app/components/modules/auth/register-form.tsx

"use client";

import { Button } from "@/components/ui/button";
import {
  Card,
  CardContent,
  CardFooter,
  CardHeader,
  CardTitle,
} from "@/components/ui/card";
import {
  Form,
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from "@/components/ui/form";
import { Input } from "@/components/ui/input";
import { trpc } from "@/utils/trpc";
import { zodResolver } from "@hookform/resolvers/zod";
import Link from "next/link";
import { useRouter } from "next/navigation";
import { useForm } from "react-hook-form";
import { z } from "zod";

const formSchema = z.object({
  email: z.string().email(),
  password: z.string(),
});

export default function RegisterForm() {
  const form = useForm<z.infer<typeof formSchema>>({
    resolver: zodResolver(formSchema),
    defaultValues: {
      email: "",
      password: "",
    },
  });

  const router = useRouter();

  const { mutateAsync: register, isLoading } = trpc.auth.register.useMutation({
    onSuccess: () => {
      router.replace("/login");
    },
  });

  const onSubmit = async (data: z.infer<typeof formSchema>) => {
    try {
      await register(data);
    } catch (error) {
      console.error(error);
    }
  };

  return (
    <Card>
      <CardHeader>
        <CardTitle>Create an account</CardTitle>
      </CardHeader>
      <Form {...form}>
        <form onSubmit={form.handleSubmit(onSubmit)}>
          <CardContent className="space-y-4">
            <FormField
              control={form.control}
              name="email"
              disabled={isLoading}
              render={({ field }) => (
                <FormItem>
                  <FormLabel>Email</FormLabel>
                  <FormControl>
                    <Input
                      type="email"
                      placeholder="me@example.com"
                      autoComplete="email"
                      {...field}
                    />
                  </FormControl>
                  <FormMessage />
                </FormItem>
              )}
            />
            <FormField
              control={form.control}
              name="password"
              disabled={isLoading}
              render={({ field }) => (
                <FormItem>
                  <FormLabel>Password</FormLabel>
                  <FormControl>
                    <Input
                      type="password"
                      placeholder="********"
                      autoComplete="new-password"
                      {...field}
                    />
                  </FormControl>
                  <FormMessage />
                </FormItem>
              )}
            />
          </CardContent>
          <CardFooter className="flex flex-col gap-4">
            <Button type="submit" className="w-full" disabled={isLoading}>
              Create account
            </Button>
            <p>
              Already have an account? <Link href="/login">Login</Link>
            </p>
          </CardFooter>
        </form>
      </Form>
    </Card>
  );
}

Implement login

Let's create a login page and test if our setup is working or not.

Create a login route.

// (auth)/login/page.tsx

import LoginForm from "@/components/modules/auth/login-form";
import { Metadata } from "next";

export const metadata: Metadata = {
  title: "Login | Finance Tracker",
};

export default function LoginPage() {
  return <LoginForm />;
}

Finally, add a login form.

// src/components/modules/auth/login-form.tsx

"use client";

import { Button } from "@/components/ui/button";
import {
  Card,
  CardContent,
  CardFooter,
  CardHeader,
  CardTitle,
} from "@/components/ui/card";
import {
  Form,
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from "@/components/ui/form";
import { Input } from "@/components/ui/input";
import { trpc } from "@/utils/trpc";
import { zodResolver } from "@hookform/resolvers/zod";
import Link from "next/link";
import { useRouter } from "next/navigation";
import { useForm } from "react-hook-form";
import { z } from "zod";

const formSchema = z.object({
  email: z.string().email(),
  password: z.string(),
});

export default function LoginForm() {
  const form = useForm<z.infer<typeof formSchema>>({
    resolver: zodResolver(formSchema),
    defaultValues: {
      email: "",
      password: "",
    },
  });

  const router = useRouter();

  const { mutateAsync: login, isLoading } = trpc.auth.login.useMutation({
    onSuccess: () => {
      router.push("/");
    },
  });

  const onSubmit = async (data: z.infer<typeof formSchema>) => {
    try {
      await login(data);
    } catch (error) {
      console.error(error);
    }
  };

  return (
    <Card>
      <CardHeader>
        <CardTitle>Login to your account</CardTitle>
      </CardHeader>
      <Form {...form}>
        <form onSubmit={form.handleSubmit(onSubmit)}>
          <CardContent className="space-y-4">
            <FormField
              control={form.control}
              name="email"
              disabled={isLoading}
              render={({ field }) => (
                <FormItem>
                  <FormLabel>Email</FormLabel>
                  <FormControl>
                    <Input
                      type="email"
                      placeholder="me@example.com"
                      autoComplete="email"
                      {...field}
                    />
                  </FormControl>
                  <FormMessage />
                </FormItem>
              )}
            />
            <FormField
              control={form.control}
              name="password"
              disabled={isLoading}
              render={({ field }) => (
                <FormItem>
                  <FormLabel>Password</FormLabel>
                  <FormControl>
                    <Input
                      type="password"
                      placeholder="********"
                      autoComplete="current-password"
                      {...field}
                    />
                  </FormControl>
                  <FormMessage />
                </FormItem>
              )}
            />
          </CardContent>
          <CardFooter className="flex flex-col gap-4">
            <Button type="submit" className="w-full" disabled={isLoading}>
              Login
            </Button>
            <p>
              Don&apos;t have an account? <Link href="/register">Register</Link>
            </p>
          </CardFooter>
        </form>
      </Form>
    </Card>
  );
}

Let's test this. Start backend and frontend. Navigate to http://localhost:3000/login. Try logging in with your email and password.

You will be redirected to the dashboard. Now, open browser console -> Application tab -> Cookies -> http://localhost:3000, you can see the stored cookies.

Protect Endpoints with Next.js Middleware

We almost had everything we needed.

Now, try to open /login and /register pages while being already logged in or dashboard (/) page while being not logged in, you are able to do so. But we shouldn't let that happen. Also, if you wait some time, accessToken and logged_in cookies disappear because they expire after 15 minutes. We have to fix this too.

Both of these problems can be solved by Next.js middleware.

Using this middleware, let's check if a user is logged in before showing a page. Accordingly, redirect the user to the appropriate page.

// src/middleware.ts

import type { NextRequest } from "next/server";
import { NextResponse } from "next/server";

export default async function middleware(request: NextRequest) {
  const response = NextResponse.next();
  const pathname = request.nextUrl.pathname;
  const loggedIn = request.cookies.get("logged_in");

  const authUrls = new Set(["/login", "/register"]);

  if (loggedIn && authUrls.has(pathname)) {
    return NextResponse.redirect(new URL("/", request.url));
  }

  return response;
}

// Don't run middleware for these files
export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - api (API routes)
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     */
    "/((?!api|_next/static|_next/image|favicon.ico).*)",
  ],
};

Here, we are checking if logged_in cookie is present. If it is present and the user is trying to access auth endpoints, the user is redirected to the dashboard page.

Now let's implement a refreshing access token so that users don't have to log in every 15 minutes.

Before we move on, I've to tell you one thing. Nextjs middleware is a server component means the tRPC client created with createTRPCReact doesn't work. To make tRPC work server-side, tRPC provides createTRPCProxyClient.

Here's the tRPC server client:

// src/utils/trpc.ts

export const createTRPCServerClient = (headers: HTTPHeaders) =>
  createTRPCProxyClient<AppRouter>({
    transformer: superjson,
    links: [
      loggerLink({
        enabled: () => process.env.NODE_ENV === "development",
      }),
      httpBatchLink({
        url: process.env.NEXT_PUBLIC_TRPC_API_URL!,
        headers() {
          return headers;
        },
        fetch: (url, options) => {
          return fetch(url, {
            ...options,
            credentials: "include",
          });
        },
      }),
    ],
  });

Since this middleware runs in edge runtime (e.g. in Vercel server if hosted with Vercel) but not in the browser, cookies will not sent in request and also cannot be sent in response. So we have to modify refreshAccessToken method in the backend to send access tokens in the response body instead of headers. Then we will set cookies in the middleware ourselves.

First, change refreshAccessToken procedure from protectedProcedure to publicProcedure since accessToken will be empty, and the server can't verify the request.

// backend/src/modules/auth/auth.routes.ts

  refreshAccessToken: publicProcedure.mutation(({ ctx }) => // <--- here
    new AuthController().refreshAccessTokenHandler(ctx)
  ),

Now, modify refreshAccessTokenHandler to send accessToken in the response body.

// backend/src/modules/auth/auth.controller.ts

  async refreshAccessTokenHandler(ctx: Context) { // <--- Context change
    const cookies = new Cookies(ctx.req, ctx.res, {
      secure: process.env.NODE_ENV === "production",
    });

    const refreshToken = cookies.get("refreshToken");
    if (!refreshToken) {
      throw new TRPCError({
        code: "UNAUTHORIZED",
        message: "Refresh token is required",
      });
    }

    const accessToken = await super.refreshAccessToken(refreshToken);

    return { success: true, accessToken }; // <--- here
  }

Switch to frontend and implement refreshing access token inside middleware:

async function refreshAccessToken(
  request: NextRequest,
  response: NextResponse,
  refreshToken: string
) {
  try {
    const client = createTRPCServerClient({
      Cookie: `refreshToken=${refreshToken}`,
    });

    const { accessToken } = await client.auth.refreshAccessToken.mutate();

    response.cookies.set("accessToken", accessToken, {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      path: "/",
    });

    response.cookies.set("logged_in", "true", {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      path: "/",
    });

    return NextResponse.next();
  } catch {
    return NextResponse.redirect(new URL("/login", request.url));
  }
}

Use it in middleware:

import type { NextRequest } from "next/server";
import { NextResponse } from "next/server";
import { createTRPCServerClient } from "./utils/trpc";

/**
 * Middleware function to handle authentication and redirection based on user login status and URL path.
 *
 * @param {NextRequest} request - The incoming request object.
 * @returns {Promise<NextResponse>} - The response object after processing the middleware logic.
 *
 * This middleware performs the following checks:
 * 1. If the user is logged in and trying to access authentication-related pages (login or register),
 *    it redirects them to the root URL ("/").
 * 2. If the user does not have a valid refresh token and is trying to access a page that requires authentication,
 *    it redirects them to the login page ("/login").
 * 3. If the user is not logged in but has a refresh token and is trying to access a page that requires authentication,
 *    it attempts to refresh the access token.
 */
export default async function middleware(request: NextRequest) {
  const response = NextResponse.next();
  const pathname = request.nextUrl.pathname;
  const loggedIn = request.cookies.get("logged_in");
  const refreshToken = request.cookies.get("refreshToken")?.value;

  const authUrls = new Set(["/login", "/register"]);

  if (loggedIn && authUrls.has(pathname)) {
    return NextResponse.redirect(new URL("/", request.url));
  }

  if (!refreshToken && !authUrls.has(pathname)) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  if (!loggedIn && refreshToken && !authUrls.has(pathname)) {
    await refreshAccessToken(request, response, refreshToken);
  }

  return response;
}

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - api (API routes)
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     */
    "/((?!api|_next/static|_next/image|favicon.ico).*)",
  ],
};

async function refreshAccessToken(
  request: NextRequest,
  response: NextResponse,
  refreshToken: string
) {
  try {
    const client = createTRPCServerClient({
      Cookie: `refreshToken=${refreshToken}`,
    });

    const { accessToken } = await client.auth.refreshAccessToken.mutate();

    response.cookies.set("accessToken", accessToken, {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      path: "/",
    });

    response.cookies.set("logged_in", "true", {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      path: "/",
    });

    return NextResponse.next();
  } catch {
    return NextResponse.redirect(new URL("/login", request.url));
  }
}

I've added comments to the code to make things clearer.

That's it! It's that easy.

Let me know if you have any doubts.

Follow for more amazing content in this series 🎸.

Socials

Implementing Cookie-Based JWT Authentication in a tRPC Backend

Rakesh Potnuru — Thu, 16 Jan 2025 18:56:59 +0000

Published from Publish Studio

Authentication is an important part of a full-stack app. This is the only thing left before you can call yourself a full-stack developer or engineer or whatever. So, in this article, I will share how to add classic (email + password) authentication to a full-stack app using Next.js middleware for the front end and tRPC for the back end.

For the sake of learning I'm not going to use third-party auth solutions like better-auth, Auth.js, Clerk, auth0, or Supabase auth. But in real apps it's better to use an auth solution because they handle everything for you and they are more secure.

This is part 3 of "Building a Full-Stack App with tRPC and Next.js" series. I recommended reading first 2 parts if you haven't to better understand this part.

Let's say we want to allow others to use our product Finance Tracker (GitHub repo). Before giving them access to the product, we have to do something, so they can't access each other’s data and keep their info secure. This is where auth comes in.

To achieve this goal, we have to let them create an account in our server and verify every time someone makes a request like adding a transaction so that we add that transaction to that specific user account.

Two important terms to understand before we move on:

Authentication: Letting the user into the server (through login).
Authorization: Giving permission to the user to perform certain actions (e.g.: add transaction, view transactions).

The Concept of Access and Refresh Tokens

Access tokens, as the name implies used to access resources from server. They often set to expire within 10 minutes to 1 hour. While refresh tokens are used only to get new access token after previous one expires and they often are long-lived (mostly 7+ days).

Then why do we need refresh tokens and why not make access tokens long-lived?

The whole point of refresh tokens is to minimize the attack window. Since access tokens are sent frequently, they have higher risk of getting compromised (like man-in-the middle attacks) than refresh tokens. And as they are short-lived, they reduce damage.

But if you don't use refresh tokens, you have to ask the user to log in again and again which is a bad user experience.

Securing Backend

Before adding auth, we have to create a user model to create accounts and create a relation with transactions.

So, open backend/src/modules and create user module and user.schema.ts file. Then create basic user schema along with zod schema for insert operation:

import { pgTable, serial, text, timestamp } from "drizzle-orm/pg-core";
import { createInsertSchema } from "drizzle-zod";

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull().unique(),
  password: text("password").notNull(),
  createdAt: timestamp("created_at").defaultNow(),
  updatedAt: timestamp("updated_at")
    .defaultNow()
    .$onUpdate(() => new Date()),
});

export const insertUserSchema = createInsertSchema(users).omit({
  id: true,
  createdAt: true,
  updatedAt: true,
});

Next, create a relation between the transaction and the user. Since one user can have many transactions, let's create one-to-many a relation.

In user.schema.ts:

import { relations } from "drizzle-orm";

export const usersRelations = relations(users, ({ many }) => ({
// each user can have multiple transactions
  transactions: many(transactions),
}));

In transaction.schema.ts:

export const transactions = pgTable("transactions", {
...
    userId: integer("user_id") // <--- add userId
        .references(() => users.id, { onDelete: "cascade" }) // <--- delete transaction when referenced user is deleted
        .notNull(), 
...
});

export const transactionsRelations = relations(transactions, ({ one }) => ({
// each transaction belongs to only one user
  user: one(users, {
    fields: [transactions.userId],
    references: [users.id],
  }),
}));

export const insertTransactionSchema = createInsertSchema(transactions).omit({
  ...
  userId: true, // <--- Remove userId from zod schema because we will get that from auth context which will be explained later
});

Now run migrations:

npx drizzle-kit push

You will get a warning (THIS ACTION WILL CAUSE DATA LOSS AND CANNOT BE REVERTED) because we are adding a required field user_id but we have some data from the previous tutorial. Since it's just a tutorial, select truncate data.

Alright, it's time to add authentication.

First, install

bcryptjs - to hash password
jsonwebtoken - to generate access and refresh tokens
cookies - to store tokens in secure cookies and include them in response when logging in so they can be stored in the user's browser to keep them logged in from the client side
ioredis - to store the user ID and refresh token in Redis to keep users logged in from the server side and identify them later when requesting resources or new access token

yarn add bcryptjs jsonwebtoken cookies ioredis

Here's the flow of authentication:

Why store refresh tokens in Redis? Why not just store the user and then decode the user from the refresh token?

Let's say a user is logged in from two devices, if you only store user, you create a single session. When one refresh token is compromised and you want to invalidate that, you have to logout user from all devices.

But if you store refresh token, user can have multiple sessions and you can have fine-grained control over user sessions and avoid misuse of the server resources. And also let user know how many sessions they currently have and show session info like device and location. This is why you see helpful email notifications like "Your account has been accessed from a new ip".

If you don't want advanced session management then a single session with just user data is enough.

Set up Redis

Create src/utils/redis.ts file. Configure Redis and create a Redis client:

import { Redis } from "ioredis";

export const redis = new Redis(process.env.REDIS_URL!);

Make sure to add REDIS_URL to env. If using local Redis, the URL looks like this:

REDIS_URL=redis://localhost:6379

Creating, and verifying tokens

Create another module called auth. In there, create auth.service.ts. Here, we will write reusable functions and generate and verify tokens:

import jwt from "jsonwebtoken";

const ACCESS_TOKEN_SECRET = process.env.ACCESS_TOKEN_SECRET!;
const REFRESH_TOKEN_SECRET = process.env.REFRESH_TOKEN_SECRET!;

export default class AuthService {
  createAccessToken(userId: number) {
    const accessToken = jwt.sign({ sub: userId }, ACCESS_TOKEN_SECRET, {
      expiresIn: "15m",
    });

    return accessToken;
  }

  createRefreshToken(userId: number) {
    const refreshToken = jwt.sign({ sub: userId }, REFRESH_TOKEN_SECRET, {
      expiresIn: "7d",
    });

    return refreshToken;
  }

  verifyAccessToken(accessToken: string) {
    try {
      const decoded = jwt.verify(accessToken, ACCESS_TOKEN_SECRET) as {
        sub: string;
      };

      return decoded.sub;
    } catch (error) {
      console.log(error);

      return null;
    }
  }

  verifyRefreshToken(refreshToken: string) {
    try {
      const decoded = jwt.verify(refreshToken, REFRESH_TOKEN_SECRET) as {
        sub: string;
      };

      return decoded.sub;
    } catch (error) {
      console.log(error);

      return null;
    }
  }

As you can see, we are creating tokens by signing them with a secret and then we use that same secret to verify them.

Open .env and create two new env variables - ACCESS_TOKEN_SECRET and REFRESH_TOKEN_SECRET. Secrets can be any strings but for real projects I recommend using RSA keys.

Implement login

Steps in login:

Find the user in the db with email.
Verify if the password is correct by comparing it against the password in the db using bcrypt (since we store hashed passwords).
If all good, generate access and refresh tokens, store refresh token along with user id in Redis and return tokens.
Then in the user controller class, call this method and send the tokens in response as HTTP cookies.

// user.service.ts
import { db } from "../../utils/db";
import { redis } from "../../utils/redis";
import { users } from "../user/user.schema";
import bcrypt from "bcryptjs";
import { eq } from "drizzle-orm";

export default class AuthService {
...
  async login(data: typeof users.$inferInsert) {
    const { email, password } = data;

    try {
      const user = (
        await db.select().from(users).where(eq(users.email, email)).limit(1)
      )[0];

      if (!user) {
        throw new TRPCError({
          code: "UNAUTHORIZED",
          message: "Invalid email or password",
        });
      }

      const isPasswordCorrect = await bcrypt.compare(password, user.password);

      if (!isPasswordCorrect) {
        throw new TRPCError({
          code: "UNAUTHORIZED",
          message: "Invalid email or password",
        });
      }

      const accessToken = this.createAccessToken(user.id);
      const refreshToken = this.createRefreshToken(user.id);

      // Store refresh token in redis to track active sessions
      await redis.set(
        `refresh_token:${refreshToken}`,
        user.id,
        "EX",
        7 * 24 * 60 * 60 // 7 days
      );

      // Store refresh token in redis set to track active sessions
      await redis.sadd(`refresh_tokens:${user.id}`, refreshToken);
      await redis.expire(`refresh_tokens:${user.id}`, 7 * 24 * 60 * 60); // 7 days

      // Store user in redis to validate session
      await redis.set(
        `user:${user.id}`,
        JSON.stringify(user),
        "EX",
        7 * 24 * 60 * 60
      ); // 7 days

      return {
        accessToken,
        refreshToken,
      };
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "UNAUTHORIZED",
        message: "Something went wrong",
      });
    }
  }
...
}

Create user.controller.ts:

// user.controller.ts

import Cookies, { SetOption } from "cookies";
import { Context } from "../../trpc";
import { users } from "../user/user.schema";
import AuthService from "./auth.service";

const cookieOptions: SetOption = {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  sameSite: "strict",
  path: "/",
  domain: "localhost" // for production, put something like ".example.com"
};

const accessTokenCookieOptions: SetOption = {
  ...cookieOptions,
  maxAge: 15 * 60 * 1000, // 15 minutes
};

const refreshTokenCookieOptions: SetOption = {
  ...cookieOptions,
  maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
};

export default class AuthController extends AuthService {
  async loginHandler(data: typeof users.$inferInsert, ctx: Context) {
    const { accessToken, refreshToken } = await super.login(data);

    const cookies = new Cookies(ctx.req, ctx.res, {
      secure: process.env.NODE_ENV === "production",
    });
    cookies.set("accessToken", accessToken, { ...accessTokenCookieOptions });
    cookies.set("refreshToken", refreshToken, {
      ...refreshTokenCookieOptions,
    });
    cookies.set("logged_in", "true", { ...accessTokenCookieOptions });

    return { success: true };
  }
}

Create auth.routes.ts file:

import { publicProcedure, router } from "../../trpc";
import { insertUserSchema } from "../user/user.schema";
import AuthController from "./auth.controller";

const authRouter = router({
  login: publicProcedure
    .input(insertUserSchema)
    .mutation(({ input, ctx }) =>
      new AuthController().loginHandler(input, ctx)
    ),
});

export default authRouter;

Add this auth route group to src/routes.ts.

import authRouter from "./modules/auth/auth.routes";

const appRouter = router({
  ...
  auth: authRouter,
});

Implement register

Register is simple, we just have to create an account. (I'm going to cover email verification in a later article since a lot of products ask users to verify email after giving access to the platform as part of their marketing strategy.)

Steps:

Check if the user already exists.
If not, hash the password and create a user.

// auth.service.ts

...
  async register(data: typeof users.$inferInsert) {
    try {
      const { email, password } = data;

      const user = (
        await db.select().from(users).where(eq(users.email, email)).limit(1)
      )[0];
      if (user) {
        throw new TRPCError({
          code: "CONFLICT",
          message:
            "This email is associated with an existing account. Please login instead.",
        });
      }

      const salt = await bcrypt.genSalt(12);
      const hashedPassword = await bcrypt.hash(password, salt);

      const newUser = await db
        .insert(users)
        .values({
          email,
          password: hashedPassword,
        })
        .returning();

      return {
        success: true,
        user: newUser,
      };
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Something went wrong",
      });
    }
  }
...

// auth.controller.ts

...
  async registerHandler(data: typeof users.$inferInsert) {
    return await super.register(data);
  }
...

// auth.routes.ts

...
  register: publicProcedure
    .input(insertUserSchema)
    .mutation(({ input }) => new AuthController().registerHandler(input)),
...

Implement access token refresh

To implement access token refresh:

Check if a refresh token exists in active sessions.
Verify token.
Check if the user still exists.
If allis good, generate a new access token and send it as a cookie.

// auth.service.ts

...
  async refreshAccessToken(refreshToken: string) {
    try {
      const isTokenExist = await redis.get(`refresh_token:${refreshToken}`);
      if (!isTokenExist) {
        throw new TRPCError({
          code: "UNAUTHORIZED",
          message: "Invalid refresh token",
        });
      }

      const userId = await this.verifyRefreshToken(refreshToken);
      if (!userId) {
        throw new TRPCError({
          code: "UNAUTHORIZED",
          message: "Invalid refresh token",
        });
      }

      const accessToken = this.createAccessToken(parseInt(userId));

      return accessToken;
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Something went wrong",
      });
    }
  }
...

// auth.controller.ts

...
  async refreshAccessTokenHandler(ctx: AuthenticatedContext) {
    const cookies = new Cookies(ctx.req, ctx.res, {
      secure: process.env.NODE_ENV === "production",
    });

    const refreshToken = cookies.get("refreshToken");
    if (!refreshToken) {
      throw new TRPCError({
        code: "UNAUTHORIZED",
        message: "Refresh token is required",
      });
    }

    const accessToken = await super.refreshAccessToken(refreshToken);
    cookies.set("accessToken", accessToken, { ...accessTokenCookieOptions });
    cookies.set("logged_in", "true", { ...accessTokenCookieOptions });

    return { success: true };
  }
...

// auth.routes.ts

...
  refreshAccessToken: protectedProcedure.mutation(({ ctx }) =>
    new AuthController().refreshAccessTokenHandler(ctx)
  ),
...

Implement logout

Finally, let's implement logout endpoint. For this, all we have to do is clear Redis and cookies.

Two types of logouts:

Single session: Clear currently active session i.e. the device the user currently using and want to logout from.

// auth.controller.ts

...
  async logoutHandler(ctx: AuthenticatedContext) {
    const { req, res, user } = ctx;

    try {
      const cookies = new Cookies(req, res, {
        secure: process.env.NODE_ENV === "production",
      });
      const refreshToken = cookies.get("refreshToken");

      if (refreshToken) {
        await redis.del(`refresh_token:${refreshToken}`);
        await redis.srem(`refresh_tokens:${user.id}`, refreshToken);
      }

      cookies.set("accessToken", "", { ...accessTokenCookieOptions });
      cookies.set("refreshToken", "", { ...refreshTokenCookieOptions });
      cookies.set("logged_in", "false", { ...accessTokenCookieOptions });

      return { success: true };
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Something went wrong",
      });
    }
  }
...

// auth.routes.ts

...
  logout: protectedProcedure.mutation(({ ctx }) =>
    new AuthController().logoutHandler(ctx)
  ),
...

All sessions: This is often given as security feature if user notices some suspicious activity happening in their account. (I've seen a lot of products that don't give this feature and I truly hate them.)

// auth.controller.ts

...
  async logoutAllHandler(ctx: AuthenticatedContext) {
    const { req, res, user } = ctx;

    try {
      const refreshTokens = await redis.smembers(`refresh_tokens:${user.id}`);

      const pipeline = redis.pipeline();

      refreshTokens.forEach((refreshToken) => {
        pipeline.del(`refresh_token:${refreshToken}`);
      });
      pipeline.del(`refresh_tokens:${user.id}`);
      pipeline.del(`user:${user.id}`);

      await pipeline.exec();

      const cookies = new Cookies(req, res, {
        secure: process.env.NODE_ENV === "production",
      });
      cookies.set("accessToken", "", { ...accessTokenCookieOptions });
      cookies.set("refreshToken", "", { ...refreshTokenCookieOptions });
      cookies.set("logged_in", "false", { ...accessTokenCookieOptions });

      return { success: true };
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Something went wrong",
      });
    }
  }
...

// auth.routes.ts

...
  logoutAll: protectedProcedure.mutation(({ ctx }) =>
    new AuthController().logoutAllHandler(ctx)
  ),
...

Set up auth middleware

Let's set up tRPC context and middleware and pass user data for authenticated requests, so we can use that to create protected procedures.

First, open src/trpc.ts and modify createContext to check for authenticated requests.

Steps:

Get accessToken from request headers.
Verify access token.
Check if the user has an active session in Redis.
Check if the user still exists in the db.
Return req, and res in the tRPC context. And user object if it is an authenticated request.

// src/trpc.ts
import Cookies from "cookies";

export const createContext = async ({
  req,
  res,
}: CreateExpressContextOptions) => {
  try {
    const cookies = new Cookies(req, res);
    const accessToken = cookies.get("accessToken");
    if (!accessToken) {
      return { req, res };
    }

    const userId = await new AuthService().verifyAccessToken(accessToken);
    if (!userId) {
      return { req, res };
    }

    const session = await redis.get(`user:${userId}`);
    if (!session) {
      return { req, res };
    }

    const user = (
      await db
        .select()
        .from(users)
        .where(eq(users.id, parseInt(userId)))
        .limit(1)
    )[0];
    if (!user) {
      return { req, res };
    }

    return {
      req,
      res,
      user,
    };
  } catch (error) {
    console.log(error);

    throw new TRPCError({
      code: "INTERNAL_SERVER_ERROR",
      message: "Something went wrong",
    });
  }
};

We can use this to identify which requests are authenticated.

Now let's create a reusable tRPC procedure called protectedProcedure to protect some endpoints and a tRPC middleware called isAuthenticted.

// src/trpc.ts

// Create another context type for protected routes, so ctx.user won't be null in authed requests
export type AuthenticatedContext = Context & {
  user: NonNullable<Context["user"]>;
};

// Middleware to check if user is authenticated
const isAuthenticated = t.middleware(({ ctx, next }) => {
  if (!ctx.user) {
    throw new TRPCError({
      code: "UNAUTHORIZED",
      message: "You must be logged in to access this resource",
    });
  }

  return next({
    ctx: {
      ...ctx,
      user: ctx.user,
    },
  });
});

// Using the middleware, create a protected procedure
export const protectedProcedure = publicProcedure.use(isAuthenticated);

In a later article, we will create proProtectedProcedure for paid features when integrating a payment provider 👀. Follow for updates 🤫.

Now use this procedure in all transaction routes.

// src/modules/transaction/transaction.routes.ts

const transactionRouter = router({
  create: protectedProcedure // <--- here
    .input(insertUserSchema)
    .mutation(({ input, ctx }) => 
      new TransactionController().createTransactionHandler(input, ctx) // pass context 
    ),

  getAll: protectedProcedure.query(({ ctx }) => // <--- here
    new TransactionController().getTransactionsHandler(ctx) // pass context 
  ),
});

Then, open transaction.controller.ts and modify it like this to use the user id from ctx.user:

...
  async createTransactionHandler(
    data: Omit<typeof transactions.$inferInsert, "userId">, // <-- Omit userId as we get it from ctx, not input
    ctx: AuthenticatedContext // <-- add ctx param
  ) {
    return await super.createTransaction({
      ...data,
      userId: ctx.user.id,
    });
  }

  async getTransactionsHandler(ctx: AuthenticatedContext) { // <-- same here
    return await super.getTransactions(ctx.user.id);
  }
...

Test Everything

Let's test our API using Postman to verify everything is working as expected. Testing tRPC API in Postman is a little different than traditional REST/Graphql APIs.

Limitations:

Cannot use superjson. So, before testing let's comment out superjson transformer in trpc.ts.

const t = initTRPC.context<Context>().create({
  // transformer: SuperJSON,
});

You cannot test queries. For this, just change query to mutation. After testing, make sure to revert changes.

POST /auth.register

POST /auth.login

If you have Redis Insight downloaded, you can easily see your keys.

POST /auth.refreshAccessToken

POST /auth.logout

If you observe the cookies and headers tab, you can see tokens are empty and if you check Redis insight, the refresh token will be deleted. Same with /auth.logoutAll but this time, all refresh tokens belonging to the user including the user session will be deleted.

Also, after logging in, try to test transaction routes.

That's it!

In the next article, I will share how to secure the Next.js front end.

Follow for updates 🚀.

Socials

My 2025 Tech Stack: Tools & Tech I'm Using This Year

Rakesh Potnuru — Wed, 01 Jan 2025 17:25:34 +0000

Published from Publish Studio

Happy New Year! In this article, I shared all the tech I used and going to use this year to build awesome products.

Device

Macbook Pro. I switched to macOS from Windows in 2023. Honestly, for web development, there isn't much difference in terms of dev experience. But I still prefer macOS over Windows and also I love the macOS community. There are a lot of awesome apps/tools built by the community that help you get the most out of your $2000 computer.

Here are my favorites:

IDE/Code Editor

Visual Studio Code. It's unbelievable that still there isn't a serious competition for VS code. It remains my favorite editor every single year. The only thing that I think needs improvement is performance because it becomes slow when working with large projects (e.g. Monorepos) and for some reason, git stops working.

My favorite extensions last year:

Terminal

VS code's built-in terminal with Oh My ZSH! for my Zsh config. I'm a GUI person, so I don't care much about fancy terminals.

AI Tools

GitHub Copilot. I've been using GitHub Copilot for more than 2 years and my productivity has increased a lot. I also tried Supermaven recently. While Supermaven is a lot faster it's not as accurate as Copilot, so I switched back. Also, the ability to choose different models (including Claude) is great.

Publish Studio. Shameless self-promotion :) - I use Publish Studio for my blogging process. It helps me from brainstorming new ideas (with AI!!) to publishing to multiple blogging platforms at once. I literally published this article on Medium, Hashnode, and Dev in a single click.

Frontend

Next.Js. Next.Js is my go-to front-end framework for web apps. But I never use its server-side features (except middleware) because I'm always the separate-frontend-backend guy.

Tailwindcss. This is another thing in my tech stack that I can't replace and I don't have to because it's just awesome. And with Shadcn-UI, it's even better.

State Management

Zustand + Immer. I never used a state management tool because React context API was enough for me until I discovered Zustand last year. It's a simpler and straightforward alternative to Redux.

Backend

NestJS. Last year I tried NestJS for the first time and I regret not trying long ago. It would have saved me a ton of time, not made my code messy, and reduced the amount of code I have to write for basic things that other non-js backend frameworks have built-in.

tRPC. tRPC is great if you love mono repos. It would be nice if they had some kind of support for NestJS. Other downsides include it can't be used for multipart-part/form-data (file uploads) and streaming. I'm going to use this for every project that's not NestJS.

Auth

I roll my own auth and use social connections or Supabase auth when using Supabase.

Database

Postgres (SQL). I use SQL DBs for strictly structured data projects and picked Postgres. I also learned the fact that you can build an entire backend with just Postgres (except the API layer of course).

MongoDB (NoSQL). I use NoSQL DBs for data-heavy projects and MongoDB is my go-to DB.

ORM

Prisma/Drizzle. I like Prisma's schema and migrations features but it looks like a really bad choice for querying because it's too slow. I guess you have to sacrifice one thing for another. And I tried Drizzle last year but this year I going to use it in my next project and see if it's any better. By the way, I wrote a tutorial on Drizzle: Setting Up Drizzle & Postgres with tRPC and Next.js App.

Cloud

Last year I realized you might not never need the cloud unless you have a serious amount of traffic/users/your use case needs tech that only cloud providers can offer like communicating with a satellite in space.

Hosting

Vercel/Netlify. My go-to platforms for front-end hosting.

Railway. My go-to platform for backend/database hosting.

Analytics

Posthog. Posthog has a lot of sub products but I use it mainly for analytics and session replays. I have to say Posthog is an impressive product. Everything from dev experience to dashboards is just awesome. Great to see GA finally got some real competition. I'm looking forward to try all the other products from them.

Payments

Paddle. I'm using Paddle for Publish Studio. I had no issues getting approved, integration, or anything so far. Also, the ability to show prices in local currency and change prices based on purchasing power parity has been a great help. (I recommend this to my fellow Indians who couldn't get a Stripe account.)

Emails

Resend. I've been using Sendgrid for more than 2 years but I switched to Resend recently. Resend provides better value and it's a lot simpler to set up and use. I hope it stays like that.

Observability

Better Stack. I've been using Better Stack for over 1.5 years for logs and website monitoring. It has good APIs, and integrations and works well for me.

Secrets Management

Doppler. I would like to keep all my project secrets in one place and connect to different platforms from there where I want to use them, so it's easy to manage. Doppler helps me with that exact thing.

Feel free to share your stack in the comments 💬 and let me know if I'm missing anything that I might find useful!

Follow me for more! 🫡

Socials

Setting Up Drizzle & Postgres with tRPC and Next.js App

Rakesh Potnuru — Wed, 25 Dec 2024 14:28:37 +0000

Published from Publish Studio

In this tutorial, let's learn how to connect a Postgres database to a tRPC express backend using Drizzle ORM. I have also created a simple frontend for our finance tracker application. You can copy frontend code from the repo here.

This is part 2, read part 1 here: Let's Build a Full-Stack App with tRPC and Next.js 14

Backend

If you don't have Postgres installed locally, please do or you can also use a hosted database.

Once you have Postgres ready, add DATABASE_URL to your .env:

DATABASE_URL=postgres://postgres:password@localhost:5432/myDB

Setting up db with drizzle

To set up drizzle, start off by installing these packages:

yarn add drizzle-orm pg dotenv
yarn add -D drizzle-kit tsx @types/pg

Now, all you have to do is connect drizzle to the DB. To do that, create src/utils/db.ts file and configure drizzle:

import { drizzle } from "drizzle-orm/node-postgres";
import pg from "pg";
const { Pool } = pg;

export const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: process.env.NODE_ENV === "production",
});

export const db = drizzle(pool);

That's it! Our db setup is ready. We can now create tables and interact with our db using drizzle ORM.

Create the first module

Regarding the project structure, there are mainly two types:

Modules: Divide features into different modules and keep all related files together. Popular frameworks like NestJs and Angular use this structure.

.
└── feature/
    ├── feature.controller.ts
    ├── feature.routes.ts
    ├── feature.schema.ts
    └── feature.service.ts

Separate folders based on the purpose:

.
├── controllers/
│   ├── feature1.controller.ts
│   └── feature2.controller.ts
├── services/
│   ├── feature1.service.ts
│   └── feature2.service.ts
└── models/
    ├── feature1.model.ts
    └── feature2.model.ts

I personally prefer modules because it just makes sense (plz stop using 2nd one).

Now, let's create our first module called transaction. This is our core feature. Start by creating src/modules/transaction/transaction.schema.ts file. This is where we define transaction schema using drizzle.

The great thing about using drizzle to write schemas is it lets us use typescript. So you don't have to learn a new syntax and ensure type safety for your schemas.

To record a transaction (txn), the most basic things we need are:

txn amount
txn type - credit or debit
description - a simple note to refer to later
tag - a category like shopping/travel/food, and so on.

First, let's create enums for txn type and tag:

import {
  pgEnum,
} from "drizzle-orm/pg-core";

export const txnTypeEnum = pgEnum("txnType", ["Incoming", "Outgoing"]);
export const tagEnum = pgEnum("tag", [
  "Food",
  "Travel",
  "Shopping",
  "Investment",
  "Salary",
  "Bill",
  "Others",
]);

Then, let's create the schema:

import {
  integer,
  pgTable,
  serial,
  text,
  timestamp,
} from "drizzle-orm/pg-core";

export const transactions = pgTable("transactions", {
  id: serial("id").primaryKey(),
  amount: integer("amount").notNull(),
  txnType: txnTypeEnum("txn_type").notNull(),
  summary: text("summary"),
  tag: tagEnum("tag").default("Others"),
  createdAt: timestamp("created_at").defaultNow(),
  updatedAt: timestamp("updated_at")
    .defaultNow()
    .$onUpdate(() => new Date()),
});

As you can see, we simply wrote typescript code and created a table!

Run migrations

One final step before we can start interacting with our db is to apply changes to our database so that all the tables will be created. To do that we have to run migrations. Drizzle has this amazing tool called drizzle-kit which handles migrations for us, so all we have to do is run a command.

Before doing that we have to create a file called drizzle.config.ts in the project root, which includes all the information about the database and schemas.

import "dotenv/config";
import { defineConfig } from "drizzle-kit";

export default defineConfig({
  schema: "./src/**/*.schema.ts",
  out: "./drizzle",
  dialect: "postgresql",
  dbCredentials: {
    url: process.env.DATABASE_URL!,
    ssl: process.env.NODE_ENV === "production",
  },
});

With that ready, run the below command:

yarn dlx drizzle-kit push

That's it! Now we can start interacting with db and write our business logic.

Business logic

Let's add logic to add new transactions.

If you already don't know:

Service - where we interact with DB and write most of the business logic
Controller - handle request/response

Create transaction/transaction.service.ts and write logic to add new transactions to db:

import { TRPCError } from "@trpc/server";
import { db } from "../../utils/db";
import { transactions } from "./transaction.schema";

export default class TransactionService {
  async createTransaction(data: typeof transactions.$inferInsert) {
    try {
      return await db.insert(transactions).values(data).returning();
    } catch (error) {
      console.log(error);

      throw new TRPCError({
        code: "INTERNAL_SERVER_ERROR",
        message: "Failed to create transaction",
      });
    }
  }
}

Another benefit of using drizzle ORM is it provides type definitions for different CRUD methods like $inferInsert, $inferSelect so there is no need to define the types again. Here, by using typeof transactions.$inferInsert we don't have to provide values for fields like primary key, and fields with default values like createdAt, and updatedAt, so typescript won't throw an error.

Drizzle also has extensions like drizzle-zod which can be used to generate zod schemas. Another headache was prevented by drizzle 🫡. So open transaction.schema.ts and create zod schema for insert operation:

import { createInsertSchema } from "drizzle-zod";

export const insertUserSchema = createInsertSchema(transactions).omit({
  id: true,
  createdAt: true,
  updatedAt: true,
});

Let's use this in the controller, create transaction/transaction.controller.ts:

export default class TransactionController extends TransactionService {
  async createTransactionHandler(data: typeof transactions.$inferInsert) {
    return await super.createTransaction(data);
  }
}

Now, all that remains is to expose this controller through an endpoint. For that, create transaction/transaction.routes.ts. Since we are using tRPC, to create an endpoint, we have to define a procedure:

import { publicProcedure, router } from "../../trpc";
import TransactionController from "./transaction.controller";
import { insertUserSchema } from "./transaction.schema";

const transactionRouter = router({
  create: publicProcedure
    .input(insertUserSchema)
    .mutation(({ input }) =>
      new TransactionController().createTransactionHandler(input)
    ),
});

export default transactionRouter;

If you remember from part 1, we created a reusable router that can be used to group procedures and publicProcedure which creates an endpoint.

Finally, open src/routes.ts and use the above transactionRouter:

import transactionRouter from "./modules/transaction/transaction.routes";
import { router } from "./trpc";

const appRouter = router({
  transaction: transactionRouter,
});

export default appRouter;

That's it! The backend is ready. This is the final backend structure:

.
├── README.md
├── drizzle
│   ├── 0000_true_junta.sql
│   └── meta
│       ├── 0000_snapshot.json
│       └── _journal.json
├── drizzle.config.ts
├── package.json
├── src/
│   ├── index.ts
│   ├── modules/
│   │   └── transaction/
│   │       ├── transaction.controller.ts
│   │       ├── transaction.routes.ts
│   │       ├── transaction.schema.ts
│   │       └── transaction.service.ts
│   ├── routes.ts
│   ├── trpc.ts
│   └── utils/
│       ├── db.ts
│       └── migrate.ts
├── tsconfig.json
└── yarn.lock

Challenge for you

Before proceeding to frontend integration, as a challenge, create an endpoint for getting all transactions.

Frontend

It's time to integrate the created endpoints in our frontend. Since this is not a frontend tutorial, I'll let you just copy the code from the repo.

All I've changed is:

Set up shadcn/ui
Change src/components/modules/dashboard/index.tsx

Also, as you observe, I'm using a modules-like structure here too. If you also like this structure, you can learn more from my previous projects Publish Studio and My One Post

In part 1, we queried data using built-in tRPC react-query.

...
  const { data } = trpc.test.useQuery();

  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      {data}
    </main>
  );
...

So, if you already know react-query, there's isn't much to learn except with tRPC we don't have to create queryFn or mutationFn because we directly call backend methods.

This is how mutations are used:

...
  const { mutateAsync: createTxn, isLoading: isCreating } =
    trpc.transaction.create.useMutation({
      onSuccess: async () => {
        form.reset();
        await utils.transaction.getAll.invalidate();
      },
    });

  const addTransaction = async (data: z.infer<typeof formSchema>) => {
    try {
      await createTxn(data);
    } catch (error) {
      console.error(error);
    }
  };
...

See In Action

I hope you like this tutorial. Feel free to extend the functionality. In the next article, I'll share how to add authentication.

Project source code can be found here.

Follow me for more 🚀. Socials

Let's Build a Full-Stack App with tRPC and Next.js App router

Rakesh Potnuru — Fri, 19 Jul 2024 09:45:11 +0000

Published from Publish Studio

Are you a typescript nerd looking to up your full-stack game? Then this guide is for you. The traditional way to share types of your API endpoints is to generate schemas and share them with the front end or other servers. However, this can be a time-consuming and inefficient process. What if I tell you there's a better way to do this? What if I tell you, you can just write the endpoints and your frontend automatically gets the types?

🥁 Let me introduce you to tRPC - a better way to build full-stack typescript apps.

What is tRPC?

To understand tRPC, it's important to first know about RPC (Remote Procedure Call). RPC is a protocol for communication between two services, similar to REST and GraphQL. With RPC, you directly call procedures (or functions) from a service.

tRPC stands for TypeScript RPC. It allows you to directly call server functions from the client, making it faster and easier to connect your front end to your back end.

(tRPC in action 👆: source)

As you can see, you immediately get feedback from the client as you edit the endpoint.

Things I like about tRPC:

It's like an SDK - you directly call functions.
Perfect for monorepos.
Autocompletion
and more...

Let's build a full-stack application to understand tRPC capabilities.

Note: To use tRPC both your server and client should be in the same directory (and repo).

The Project

We are going to build a Personal Finance Tracker app to track our income, and expenses and set goals. I will divide this guide into a series to keep it interesting. Today, let's setup the backend (tRPC with ExpressJs adapter), and front end (Next.Js app router).

Start off by creating a folder for the project.

mkdir finance-tracker && cd finance-tracker

Backend - tRPC with ExpressJs adapter

You can use tRPC standalone adapter but if you like to use a server framework, tRPC has adapters for most of them. Note that tRPC is a communication protocol (like REST) and not a server.

Create a folder called server inside the project folder and initialize the project.

mkdir backend && cd backend && yarn init

Setup Typescript

Note: If you are using yarn v4 you have to create yarnrc.yml and put this nodeLinker: node-modules.

Install deps:

yarn add typescript tsx

tsx - Used to run typescript directly in nodejs without the need to compile to javascript.

yarn add --dev @types/node

Create tsconfig.json and copy this.

// tsconfig.json
{
    "compilerOptions": {
        /* Language and Environment */
        "target": "ESNext" /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */,
        "lib": [
            "ESNext"
        ] /* Specify a set of bundled library declaration files that describe the target runtime environment. */,

        /* Modules */
        "module": "ESNext" /* Specify what module code is generated. */,
        "moduleResolution": "node" /* Specify how TypeScript looks up a file from a given module specifier. */,
        "rootDir": "src" /* Specify the root folder within your source files. */,
        "outDir": "dist" /* Specify an output folder for all emitted files. */,
        "esModuleInterop": true /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables 'allowSyntheticDefaultImports' for type compatibility. */,
        "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,

        /* Type Checking */
        "strict": true /* Enable all strict type-checking options. */,
        "skipLibCheck": true /* Skip type checking all .d.ts files. */
    },
    "include": ["src/**/*"],
    "exclude": ["node_modules"]
}

Project setup

Install deps:

yarn add @trpc/server cors dotenv express superjson zod

yarn add --dev @types/cors @types/express nodemon cross-env

Open package.json and add these.

{
    "scripts": {
        "build": "NODE_ENV=production tsc",
        "dev": "cross-env NODE_ENV=development nodemon --watch '**/*.ts' --exec node --import tsx/esm src/index.ts",
        "start": "node --import tsx/esm src/index.ts"
    },
    "type": "module",
    "main": "src/index.ts",
    "files": [
        "dist"
    ]
}

Create .env

PORT=4000

Add these to .gitignore

node_modules/
dist
.env

Let's start by creating trpc.ts inside src. This is the bare minimum required to create API endpoints with tRPC:

// src/trpc.ts

import { initTRPC, type inferAsyncReturnType } from "@trpc/server";
import type { CreateExpressContextOptions } from "@trpc/server/adapters/express";
import SuperJSON from "superjson";

/**
 * Creates the context for tRPC by extracting the request and response objects from the Express context options.
 */
export const createContext = ({
  req,
  res,
}: CreateExpressContextOptions) => ({});
export type Context = inferAsyncReturnType<typeof createContext>;

/**
 * The tRPC instance used for handling server-side requests.
 */
const t = initTRPC.context<Context>().create({
  transformer: SuperJSON,
});

/**
 * The router object for tRPC.
 */
export const router = t.router;
/**
 * Exported constant representing a tRPC public procedure.
 */
export const publicProcedure = t.procedure;

First, we created tRPC context which can be accessed by routes. You can pass whatever you want to share with your routes. The best example will be passing user object, so we can access user information in routes.

Next, we initialized tRPC with initTRPC. In this, we can use a transformer like superjson - which is used to serialize JS expressions. For example, if you pass Date, it will be inferred as Date instead of string. So it's perfect for tRPC since we tightly couple frontend and backend.

After that, we defined a router with which we can create endpoints.

Finally, we created a reusable procedure called publishProcedure. procedure in tRPC is just a function that the frontend can access. Think of them like endpoints. The procedure can be a Query, Mutation, or Subscription. Later we will create another reusable procedure called protectedProcedure that will allow only authorized user access to certain endpoints.

Let's create an endpoint. I like to keep all the routes inside a dedicated routes file. So create routes.ts and create an endpoint.

// src/routes.ts

import { publicProcedure, router } from "./trpc";

const appRouter = router({
  test: publicProcedure.query(() => {
    return "Hello, world!";
  }),
});

export default appRouter;

Here, test is a query procedure. It's like GET a request.

Now, let's create index.ts to create express app.

// src/index.ts

import { createExpressMiddleware } from "@trpc/server/adapters/express";
import cors from "cors";
import "dotenv/config";
import type { Application } from "express";
import express from "express";
import appRouter from "./routes";
import { createContext } from "./trpc";

const app: Application = express();

app.use(cors());

app.use("/health", (_, res) => {
  return res.send("OK");
});

app.use(
  "/trpc",
  createExpressMiddleware({
    router: appRouter,
    createContext,
  })
);

app.listen(process.env.PORT, () => {
  console.log(`✅ Server running on port ${process.env.PORT}`);
});

export type AppRouter = typeof appRouter;

If you have worked with ExpressJs before, then you should be familiar with this code. We created a server and exposed it on a specified PORT. To expose tRPC endpoints to the express app, we can use createExpressMiddleware function from the tRPC express adapter.

Now, we can access all the routes we are going to create in routes.ts from base endpoint /trpc.

To test it out, start the server by running yarn dev and go to http://localhost:4000/trpc/test. You will see the output:

{
  "result": {
    "data": {
      "json": "Hello, world!"
    }
  }
}

That's it, our backend is ready. Now let's create a frontend with Next.Js to consume the endpoint we just created.

Frontend - Next.Js with App Router

Go back to the project root and create a Next.Js project with these settings:

yarn create next-app@latest

What is your project named? frontend
Would you like to use TypeScript? Yes
Would you like to use ESLint? No
Would you like to use Tailwind CSS? Yes
Would you like to use `src/` directory? Yes
Would you like to use App Router? (recommended) Yes
Would you like to customize the default import alias (@/*)? No
What import alias would you like configured? @/*

Move into the folder:

cd frontend

The final folder structure will be:

.
└── finance-tracker/
    ├── frontend
    └── backend

Let's integrate tRPC in our frontend:

Install deps: (make sure to add yarnrc.yml file)

yarn add @trpc/react-query superjson zod @trpc/client @trpc/server @tanstack/react-query@4.35.3 @tanstack/react-query-devtools@4.35.3

tRPC is a wrapper around react-query, so you can use all your favorite features from react-query.

First, put the backend url in env. Create .env.local and put:

NEXT_PUBLIC_TRPC_API_URL=http://localhost:4000/trpc

Create tRPC react client:

// src/utils

import { createTRPCReact } from "@trpc/react-query";
import { AppRouter } from "../../../backend/src/index";

export const trpc = createTRPCReact<AppRouter>();

Here, we created a tRPC client for react with createTRPCReact provided by tRPC and imported from previously created AppRouter which contains all routes information.

Now, let's create a tRPC provider, so our whole app can access the context, I prefer to put all the providers in one place to make the entry file more readable:

// src/lib/providers/trpc.tsx

"use client";

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { ReactQueryDevtools } from "@tanstack/react-query-devtools";
import { httpBatchLink, loggerLink } from "@trpc/client";
import superjson from "superjson";

import { trpc } from "@/utils/trpc";

if (!process.env.NEXT_PUBLIC_TRPC_API_URL) {
  throw new Error("NEXT_PUBLIC_TRPC_API_URL is not set");
}

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 1000 * 60 * 2,
      refetchOnWindowFocus: false,
      retry: false,
    },
  },
});

const trpcClient = trpc.createClient({
  transformer: superjson,
  links: [
    loggerLink({
      enabled: () => process.env.NODE_ENV === "development",
    }),
    httpBatchLink({
      url: process.env.NEXT_PUBLIC_TRPC_API_URL,
    }),
  ],
});

export function TRPCProvider({
  children,
}: Readonly<{ children: React.ReactNode }>) {
  return (
    <trpc.Provider client={trpcClient} queryClient={queryClient}>
      <QueryClientProvider client={queryClient}>
        {children}
        <ReactQueryDevtools position="bottom-left" />
      </QueryClientProvider>
    </trpc.Provider>
  );
}

If you are familiar with react-query, then this is not new to you. As an extra step, we just wrapped QueryClientProvider with the tRPC provider.

Similar to the backend we are using superjson as the transformer. loggerLink helps us debug network requests directly in the console. You can learn more about links the array here.

Create index.tsx inside providers to export all the individual providers from a single file:

// src/lib/providers/index.tsx

import { TRPCProvider } from "./trpc";

export function Providers({
  children,
}: Readonly<{ children: React.ReactNode }>) {
  return <TRPCProvider>{children}</TRPCProvider>;
}

Finally, wrap the app with providers, the best place to do this is in the root layout:

// src/app/layout.tsx

import { Providers } from "@/lib/providers";
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Finance Tracker",
  description: "Track your finances",
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={inter.className}>
        <Providers>{children}</Providers>
      </body>
    </html>
  );
}

Let's test the integration, edit page.tsx:

// src/app/page.tsx

"use client";

import { trpc } from "@/utils/trpc";

export default function Home() {
  const { data } = trpc.test.useQuery();

  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      {data}
    </main>
  );
}

Here, we imported the trpc client that we created above and you get all the auto completions from it.

If you start both backend and frontend and go to http://localhost:3000 in your browser, you can see it working.

Now, if make any changes to your API, you get changes in the front end instantly. For example, change the spelling of test API to hello and see page.tsx throwing error. This ultimately improves your development experience and makes building typescript apps awesome.

This is all you need to get started with tRPC and Next.Js. In the next article, we'll integrate the database and create some CRUD operations.

Project source code can be found here.

Follow for more 🚀.

Socials

✨ Introducing Publish Studio

Rakesh Potnuru — Tue, 05 Mar 2024 06:16:20 +0000

Published from Publish Studio

UPDATE: Publish Studio is now generally available. Sign Up for free and start writing.

It’s been a really long time since I last published an article here. I’ve been inactive due to some personal career reasons. But I’m back now with so many exciting things I learned last year and can’t wait to share them with you.

Quick Intro

First of all, say “Hi” to Publish Studio, a platform I’ve building for the past few months. If you are a content writer, then you should definitely check it out. And if you are someone who has an audience on multiple blogging platforms and need an easy way to manage your content across platforms, then you should 100% give it a try.

Currently, Publish Studio is in beta, so please join the waitlist. I would appreciate your feedback on any issues before making it generally available.

Join waitlist: https://publishstudio.one

Main Features

1. Rich Text Editing

Elevate your content with rich text editing. It provides you with robust formatting tools to refine your writing and make it visually appealing.

2. Dictation

Simplify your content creation process with the dictation feature. Speak naturally, and let the platform transcribe your words accurately into text. It's a convenient tool that saves time and effort, allowing you to focus on expressing your ideas effectively.

3. Tone Analysis

Gain insights into the emotional tone of your content with the tone analysis feature. It helps you understand how your writing resonates with your audience, enabling you to fine-tune your messaging accordingly. Whether you aim for a casual or formal tone, the analysis tool assists you in crafting content that connects authentically.

4. Import Content

If you got your stuff scattered everywhere, you can bring them all together into the platform with the import feature, making it easy to consolidate your content library in one place.

5. Integrated Media Tools

Integrated media tools! With access to gems like Pexels, Unsplash, Imagekit, and Cloudinary right on the platform.

6. Export Content

A small but helpful feature. Export your content in different file formats.

7. Publish to Multiple Platforms

I want to clear up any confusion that might come in the future. Publishing to multiple platforms is one of the core features of Publish Studio but it’s not the only goal.

With Publish Studio, publishing to multiple platforms is a breeze! Spread your content far and wide with just a few clicks.

8. Schedule Posts

You don’t have to publish right away. With the schedule feature, you're the master of your content calendar. Plan ahead, set the dates, and let Publish Studio do the rest.

9. Writing Stats

Curious about your writing habits? Dive into your writing stats and discover your creative superpowers!

…and a lot more already planned but need a little time and your big support ❤️.

This is just the start with more features coming in the future.

Follow me for more! Onwards and upwards 🚀.

Deploying a MERN App to AWS Elastic Beanstalk with CI/CD

Rakesh Potnuru — Fri, 24 Feb 2023 20:37:06 +0000

In the previous article "Automate MERN App Deployment with GitHub Actions CI/CD", we learned till pushing images to the docker hub. So far, you've done an excellent job! But that isn't enough; we now require a server that runs our containers 24 hours a day, seven days a week, and should be accessible to anyone with an internet connection. It is not a good idea to set up your own server 😅. So we'll need to rent a server. Who will give us a rented server and how to set it up are what you will learn in this article.

Let's Get Started

Prerequisites

Get source code from here if haven't followed previous tutorials in this series.
Read previous articles in this series so that you won't get confused.
AWS account.
All the AWS services we use in this tutorial are free but you need a credit/debit card to create an account.

Before we proceed, note that our super simple productivity-app doesn't need AWS. This is just for learning purposes.

⚠️ Warning: Don't forget to turn off any running instances, and environments as soon as you finish this tutorial to avoid getting billed.

What is AWS?

As I mentioned in the beginning, we need someone who will let us rent a server and that is what AWS is about. Not physically like a room and bunch of boxes but on the cloud means you can rent servers from anywhere in the world.

This is how it looks like if you set up your own servers physically 😂:

If you haven't been living under a rock, you've probably heard of AWS. It is an abbreviation for Amazon Web Services. AWS (by Amazon) offers a wide range of cloud computing services, such as computing, storage, database, analytics, machine learning, networking, mobile, developer tools, security, and enterprise applications. for all of your requirements, eliminating the need for you to set up your own servers. It provides a flexible and scalable infrastructure that can be tailored to each user's unique requirements, and it is widely regarded as one of the leading cloud platforms available today. Google Cloud (by Google) and Azure (by Microsoft) are both major competitors to AWS.

Big Brain Time 💡: If you are following from the beginning, in the first article "Let's build and deploy a full stack MERN web application", we deployed our frontend application on Netlify and backend on Heroku. Those are fine but most companies need IaaS (Infrastructure as a Service) over PaaS (Platform as a Service).

Infrastructure as a Service (IaaS) VS Platform as a Service (PaaS)

This image clearly shows the difference between Iaas and PaaS:

Setting up NGINX

NGINX is a popular web server that is frequently used as a load balancer, reverse proxy, and HTTP cache. Consider it a traffic controller that manages traffic across multiple servers based on how busy a server is.

As a reverse proxy, NGINX serves as a go-between for the client and the server. When you (the client) send a request to the server, it is routed through the reverse proxy and then to the web server. This reverse proxy is useful in several ways: it can distribute requests across multiple servers, cache frequently-requested content, reduce response time, and protect against malicious requests.

If you want to learn more about NGINX, I would recommend reading "The NGINX Handbook" written by Farhan Hasin Chowdhury on freeCodeCamp.

Okay! Why do we care? Instead of deploying frontend and backend separately, we can simply use a load balancer like NGINX to combine both the frontend and backend into one web server, which can then distribute incoming requests to the appropriate server based on the type of request and server load. This simplifies the deployment process and helps to ensure better performance and scalability of the application.

Configuring NGINX

Open the project in your code editor. In the root, create a folder called nginx.

In that folder, create a file called nginx.conf and paste this code.

# Defining a server group called `client` that has one server in it called `client` on port `3000`.
upstream client {
    server client:3000;
}

# Defining a server group called `server` that has one server in it called `server` on port `5000`.
upstream server {
    server server:5000;
}

# Listening on port 80 and redirecting requests to the client and server.
server {
    listen 80;
    listen [::]:80;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;

    location / {
        proxy_pass http://client;
    }

    location /server {
        rewrite /server/(.*) /$1 break;
        proxy_pass http://server;
    }
}

The upstream directive is used to define the server groups, one for the client on port 3000 and another for the server on port 5000.
The server directive is used to define the server that listens on port 80 for incoming requests. The listen directive specifies the port and the proxy_http_version, proxy_set_header, and proxy_cache_bypass directives are used to configure the proxy settings.
The location directive is used to define the URL paths that are redirected to each server group. The first location / directive redirects all requests to the client server group. The second location /server directive matches any request with the path /server and uses the rewrite directive to remove /server from the path before redirecting to the server server group using the proxy_pass directive.

Even I'm using NGINX for the first time, so please read the article I mentioned above to clearly understand how to write NGINX config files.

Now, create Dockerfile in that same folder and paste this.

FROM nginx:stable-alpine

RUN rm /etc/nginx/conf.d/*

COPY ./nginx.conf /etc/nginx/conf.d/

CMD [ "nginx", "-g", "daemon off;" ]

Setting up AWS

We are going to use three AWS services:
1) Elastic Beanstalk - A fully-managed service that makes it easy to deploy applications.
2) EC2 - Elastic Compute is a computing service that offers scalable computing capacity. You can quickly start a virtual machine with your preferred configurations such as operating system, software, storage, and more.
3) S3 Bucket - A highly scalable storage service. All of your app data will be stored here.

Only Elastic Beanstalk needs to be configured; the other two will be configured automatically.

So, go ahead and log in to your AWS management console.

Create a user

To begin, we must create a user who will manage cloud resources. Because we're automating the deployment with GitHub Actions, we need a way for Actions to modify our resources, such as deploying code to AWS, and that's what this user is for. Make sure to grant the appropriate permissions.

In the search bar, type "IAM" (Identity and Access Management) and click on Users under Access management.

Click on Add users and give your user a name -> click Next.

In Set permissions select Attach policies directly -> check AdministratorAccess-AWSElasticBeanstalk -> click Next -> finally click Create user.

Create and configure an application in Elastic Beanstalk

Again in the search bar, type "Elastic Beanstalk".

Click Create Application.

Give your application a name, leave Application tags blank, select "Docker" as Platform, and leave the rest default. Click Create application.

Congrats 🎊! Your application has been created. You can visit it by clicking the URL shown in the application environment. This is a sample application provided by EB.

Configure environment variables

Before we deploy our application we need to add environment variables in EB.

To do so, go to the application Configuration page and click Edit under the Software category.

Scroll to the very bottom of the page -> under Environment variables and add the following env variables.

REACT_APP_BACKEND_URL = /server
MONGODB_URI = your MongoDB URI
TOKEN_KEY = random string
EMAIL = email
PASSWORD = password

That's it! It's now time to add the deployment step to our CI/CD pipeline.

Deploying MERN App on AWS with CI/CD

Open pipeline.yml and add this step right below pushing images to the docker hub step.

      # This is the step that is deploying the application to Elastic Beanstalk.
      - name: Deploy to Elastic Beanstalk
        uses: einaregilsson/beanstalk-deploy@v21
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: ${{ secrets.EB_APP_NAME }}
          environment_name: ${{ secrets.EB_ENV_NAME }}
          region: ${{ secrets.EB_REGION }}
          version_label: "version-${{ github.run_number }}"
          deployment_package: docker-compose.yml

Here we are using a pre-defined GitHub action einaregilsson/beanstalk-deploy@v21 so that we don't need to write from scratch. There's nothing needed to explain, it's pretty straightforward.
Add AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY to GitHub secrets. You can get these from the IAM dashboard. Just click on the user you created and go to the Security credentials tab and copy from there.
EB_APP_NAME is your EB application name and EB_ENV_NAME is your application environment name (ends with "-env" in my case it is "Productivityapp-env").
EB_REGION is the region assigned to you.

Because docker-compose cannot read GitHub environment variables, we are now creating a second image with the word 'latest' at the end of the image tag instead of github.run_number. This is the final YAML file. (You can build a single image if you want, just remove the tag with github.run_number)

# The name of the workflow.
name: Build and Deploy

# Run the workflow when code is pushed to the main branch
on:
  push:
    branches:
      - main

# Set environment variables
env:
  MONGODB_URI: ${{ secrets.MONGODB_URI }}
  TOKEN_KEY: ${{ secrets.TOKEN_KEY }}
  EMAIL: ${{ secrets.EMAIL }}
  PASSWORD: ${{ secrets.PASSWORD }}

# This is the workflow that is being run.
jobs:
  build-and-deploy:
    # This is telling GitHub to run the workflow on the latest version of Ubuntu.
    runs-on: ubuntu-latest
    steps:
      # Checkout the code from the GitHub repository
      - name: Checkout code
        uses: actions/checkout@v3

      # Install dependencies and run tests for the client application
      - name: Install and Test Client
        working-directory: ./client
        run: |
          npm install
          npm run test

      # Install dependencies, export environment variables to be used by application and run tests for the server application
      - name: Install and Test Server
        working-directory: ./server
        run: |
          npm install
          export MONGODB_URI=$MONGODB_URI
          export TOKEN_KEY=$TOKEN_KEY
          export EMAIL=$EMAIL
          export PASSWORD=$PASSWORD
          npm run test

      # Build a Docker image for the client application
      - name: Build Client Docker Image
        working-directory: ./client
        # Build image with tag rakeshpotnuru/productivity-app:client
        run: |
          docker build -t rakeshpotnuru/productivity-app:client-${{github.run_number}} -t rakeshpotnuru/productivity-app:client-latest .

      # Build a Docker image for the server application
      - name: Build Server Docker Image
        working-directory:
          ./server
          # Build image with tag rakeshpotnuru/productivity-app:server
        run: |
          docker build -t rakeshpotnuru/productivity-app:server-${{github.run_number}} -t rakeshpotnuru/productivity-app:server-latest .

      # Build a Docker image for the NGINX reverse proxy
      - name: Build NGINX Docker Image
        working-directory: ./nginx
        # Build image with tag rakeshpotnuru/productivity-app:nginx
        run: |
          docker build -t rakeshpotnuru/productivity-app:nginx-${{github.run_number}} -t rakeshpotnuru/productivity-app:nginx-latest .

      # Login to Docker Hub using credentials from repository secrets
      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Push the Docker images to Docker Hub
      - name: Push Docker Images to Docker Hub
        run: |
          docker push rakeshpotnuru/productivity-app:client-${{github.run_number}}
          docker push rakeshpotnuru/productivity-app:server-${{github.run_number}}
          docker push rakeshpotnuru/productivity-app:nginx-${{github.run_number}}
          docker push rakeshpotnuru/productivity-app:client-latest
          docker push rakeshpotnuru/productivity-app:server-latest
          docker push rakeshpotnuru/productivity-app:nginx-latest

      # This is the step that is deploying the application to Elastic Beanstalk.
      - name: Deploy to Elastic Beanstalk
        uses: einaregilsson/beanstalk-deploy@v21
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: ${{ secrets.EB_APP_NAME }}
          environment_name: ${{ secrets.EB_ENV_NAME }}
          region: ${{ secrets.EB_REGION }}
          version_label: "version-${{ github.run_number }}"
          deployment_package: docker-compose.yml

deployment_package

There are two ways you can provide a package for deployment package - 1. Zip file or 2. docker-compose file. Since we are pushing images to the docker hub we will use the docker-compose.yml file.

Rename the previous docker-compose.yml file as docker-compose.dev.yml and create a new docker-compose.yml file. Paste this code.

version: "3.8"

services:
  nginx:
    image: rakeshpotnuru/productivity-app:nginx-latest
    restart: always
    depends_on:
      - client
      - server
    ports:
      - "80:80"

  client:
    image: rakeshpotnuru/productivity-app:client-latest
    environment:
      - CHOKIDAR_USEPOLLING=true
      - REACT_APP_BACKEND_URL=${REACT_APP_BACKEND_URL}

  server:
    image: rakeshpotnuru/productivity-app:server-latest
    environment:
      - MONGODB_URI=${MONGODB_URI}
      - TOKEN_KEY=${TOKEN_KEY}
      - EMAIL=${EMAIL}
      - PASSWORD=${PASSWORD}

Instead of re-building Docker images with Dockerfile, we pull pre-built images from Docker Hub. And those environment variables are derived from variables we previously defined in the EB application environment.

That's all! Push the code to GitHub and allow all checks in the GitHub Actions workflow to pass. You can see your application in action 🎉🚀🤩.

Terminating the Environment

Don't forget to terminate the environment after finishing this tutorial if you no longer use that application.

To terminate, go to Environments -> select the environment you want to terminate -> click Actions -> click Terminate environment. This will also terminate any instances that were created by your application.

If you've made it this far from "Let's build and deploy a full stack MERN web application", kudos. Give yourself a shoulder pat.

This is not the end of the story. Many exciting articles are on the way! Follow me for more - Onwards and Upwards 🚀!

Automate MERN App Deployment with GitHub Actions CI/CD

Rakesh Potnuru — Sat, 18 Feb 2023 07:44:21 +0000

As you continue to develop your software, you must also continue to integrate it with previous code and deploy it to servers. Manually doing this is a time-consuming process that can occasionally result in errors. So we need to do this in a continuous and automated manner, which is what you will learn in this article.

Let's Get Started

The Problem

Consider our productivity app. There are numerous steps we must complete, from building the application to pushing it to the docker hub. First, we must run tests with a command to determine whether all tests are passed or not; if all tests are passed, we build docker images and then push those images to Docker Hub. If your application is extremely complex, you may need to take additional steps. Now, we're doing everything manually, which takes time and can lead to mistakes.

The Solution

To address this problem, we can create a CI/CD Pipeline. So, whenever you add a feature or fix a bug, this pipeline is triggered, which automatically performs all of the steps from testing to deploying.

What is CI/CD and Why it's Important?

Continuous Integration and Continuous Deployment is a series of steps performed to automate software integration and deployment. CI/CD is the heart of DevOps.

From development to deployment, our MERN app goes through four major stages: testing, building docker images, pushing to a registry, and deploying to a cloud provider. All of this is done manually by running various commands. This must be done every time a new feature is added or a bug is fixed. However, this will significantly reduce developer productivity, which is why CI/CD is required to automate this process. (In this article, we will cover till pushing to the registry.)

What is "GitHub Actions"?

A CI/CD server is required to run a CI/CD pipeline; this is where all of the steps written in a pipeline run. There are numerous services available on the market, including Jenkins, Travis CI, Circle CI, GitLab CI/CD, AWS CodePipeline, Azure DevOps, and Google Cloud Build. I chose GitHub Actions because it is natively integrated with Git, works well with GitHub, and is extremely simple to use. It is also sufﬁcient for small/medium-sized applications such as ours. For more complex applications, you can use any of the other services listed above.

How do GitHub Actions work?

GitHub actions is not a CI/CD platform, CI/CD is one of its use cases.

Events

Workflows are triggered by events such as pull requests, pushed, PR merged, the issue created, and a few others. For example, you can trigger a workflow running a bot that says "Thanks for opening the issue, our maintainers will review it." whenever an issue is created.

Workflows

Workflows are YAML files that contain all of the instructions that are executed after an event is triggered. Workflow files are typically kept in the .github/workflows/ directory.

Jobs

Jobs is a group set of steps called a job. Each workflow must include at least one job. A job is a set of steps that must be executed in a virtual environment.

Runners

This is my favorite feature of GitHub Actions. Runners are virtual environments where jobs are carried out. You can either use GitHub-hosted runners that contains pre-installed packages or host your own.

Adding a CI/CD Pipeline to the MERN App

Prerequisites

Get source code from here if haven't followed previous tutorials in this series.
Read previous articles in this series so that you won't get confused.
Basic YAML understanding.
GitHub account.

To begin, we must define pipeline configurations in a YAML file. Where should I save this YAML file? - If you're familiar with GitHub, you've probably heard of the .github directory, which is a special directory used for GitHub-specific items such as issue templates, pull request templates, workflow files, and so on. So we must place our pipeline file in the workflows folder, which is located in the .github folder.

Go ahead and create a YAML file and name it something like pipeline.yml or pipeline.yaml. Your folder structure should now look like this:

.
└── my-project/
    ├── .github/
    │   └── workflows/
    │       └── pipeline.yml
    ├── client/
    ├── server/
    └── docker-compose.yml

First, we have to mention the name of the workflow.

name: Build and Deploy

Then, mention a trigger - on commit/on push/on pull request, etc.., along with branches.

on:
  push:
    branches:
      - main

Since our application uses some environment variables while running tests, we have to set environment variables in the YAML file that will be used by workflow steps.

But, first, let's add environment variables in the GitHub repository. To do so, go to repository Settings -> expand Secrets and variables -> Actions.

Click on New repository secret and add the following secrets.

Now in the YAML file, you can access them like this:

env:
  MONGODB_URI: ${{ secrets.MONGODB_URI }}
  TOKEN_KEY: ${{ secrets.TOKEN_KEY }}
  EMAIL: ${{ secrets.EMAIL }}
  PASSWORD: ${{ secrets.PASSWORD }}

Let's get to the interesting part!
These are the only steps we have to perform with GitHub Actions. As simple as that.

Start by adding jobs, let's add a job called build-and-deploy.

jobs:
  build-and-deploy:
    # This is telling GitHub to run the workflow on the latest version of Ubuntu.
    runs-on: ubuntu-latest

Adding Continuous Integration

In this job, let's add steps to pull code from the repo and run some tests.

steps:
      # Checkout the code from the GitHub repository
      - name: Checkout code
        uses: actions/checkout@v3

      # Install dependencies and run tests for the client application
      - name: Install and Test Client
        working-directory: ./client
        run: |
          npm install
          npm run test

      # Install dependencies, export environment variables to be used by application and run tests for the server application
      - name: Install and Test Server
        working-directory: ./server
        run: |
          npm install
          export MONGODB_URI=$MONGODB_URI
          export TOKEN_KEY=$TOKEN_KEY
          export EMAIL=$EMAIL
          export PASSWORD=$PASSWORD
          npm run test

name - You can provide a name for each step.
uses - Set which action to use. checkout is a pre-defined action provided by GitHub that checks out a repo
working-directory - Set working directory. This is where all the commands mentioned in that step will run.
run - Run commands. You can run multiple commands by putting | (pipe). Learn more about YAML in this YouTube tutorial.

Now if you push these changes to GitHub. It will automatically run your workflow. You can see the running workflow in the Actions tab of your GitHub repository.

Click on the commit and then the job to see the running steps.

Adding Continuous Deployment

Now it's time to build docker images and push them to the docker hub.

# Build a Docker image for the client application
      - name: Build Client Docker Image
        working-directory: ./client
        # Build image with tag rakeshpotnuru/productivity-app:client
        run: |
          docker build -t rakeshpotnuru/productivity-app:client-${{github.run_number}} .

      # Build a Docker image for the server application
      - name: Build Server Docker Image
        working-directory:
          ./server
          # Build image with tag rakeshpotnuru/productivity-app:server
        run: |
          docker build -t rakeshpotnuru/productivity-app:server-${{github.run_number}} .

      # Login to Docker Hub using credentials from repository secrets
      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Push the Docker images to Docker Hub
      - name: Push Docker Images to Docker Hub
        run: |
          docker push rakeshpotnuru/productivity-app:client-${{github.run_number}}
          docker push rakeshpotnuru/productivity-app:server-${{github.run_number}}

Before pushing to the docker hub we need to log into the hub. That's why there's a step before pushing images. With with we can use secrets directly without setting them in the environment.
github.run_number - This is because it's a good practice to give a unique identifier for every image on the hub. And this environment variable (run_number) will be generated automatically by GitHub Actions.

Here's the complete YAML file.

# The name of the workflow.
name: Build and Deploy

# Run the workflow when code is pushed to the main branch
on:
  push:
    branches:
      - main

# Set environment variables
env:
  MONGODB_URI: ${{ secrets.MONGODB_URI }}
  TOKEN_KEY: ${{ secrets.TOKEN_KEY }}
  EMAIL: ${{ secrets.EMAIL }}
  PASSWORD: ${{ secrets.PASSWORD }}

# This is the workflow that is being run.
jobs:
  build-and-deploy:
    # This is telling GitHub to run the workflow on the latest version of Ubuntu.
    runs-on: ubuntu-latest
    steps:
      # Checkout the code from the GitHub repository
      - name: Checkout code
        uses: actions/checkout@v2

      # Install dependencies and run tests for the client application
      - name: Install and Test Client
        working-directory: ./client
        run: |
          npm install
          npm run test

      # Install dependencies, export environment variables to be used by application and run tests for the server application
      - name: Install and Test Server
        working-directory: ./server
        run: |
          npm install
          export MONGODB_URI=$MONGODB_URI
          export TOKEN_KEY=$TOKEN_KEY
          export EMAIL=$EMAIL
          export PASSWORD=$PASSWORD
          npm run test

      # Build a Docker image for the client application
      - name: Build Client Docker Image
        working-directory: ./client
        # Build image with tag rakeshpotnuru/productivity-app:client
        run: |
          docker build -t rakeshpotnuru/productivity-app:client-${{github.run_number}} .

      # Build a Docker image for the server application
      - name: Build Server Docker Image
        working-directory:
          ./server
          # Build image with tag rakeshpotnuru/productivity-app:server
        run: |
          docker build -t rakeshpotnuru/productivity-app:server-${{github.run_number}} .

      # Login to Docker Hub using credentials from repository secrets
      - name: Login to Docker Hub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Push the Docker images to Docker Hub
      - name: Push Docker Images to Docker Hub
        run: |
          docker push rakeshpotnuru/productivity-app:client-${{github.run_number}}
          docker push rakeshpotnuru/productivity-app:server-${{github.run_number}}

Resources

Learn more about CI/CD and GitHub Actions.

GitHub Actions 101 written series by Victoria Lo.
Introduction to GitHub Actions CI/CD by Kunal Kushwaha.
CI/CD Tutorials YouTube playlist by TechWorld with Nana.

In the next article, we will learn how to deploy to a cloud service provider (Generally the last step in a CI/CD pipeline).

Build strong pipelines. Don't be like this 💀 - https://youtu.be/M_jjG9K5KEo

Follow me for more, seriously!

Getting Started with Firebase for Web Development

Rakesh Potnuru — Wed, 08 Feb 2023 17:30:12 +0000

Building a full-stack web application can be daunting and overwhelming because there are so many factors to take into account, such as user authentication, database, security, hosting, and so on. If you are a solopreneur or an indie hacker, building these from scratch will be a nightmare. Fortunately, there is one breakthrough technology that can handle all of these issues simultaneously. And that tool is Firebase.

Let's Get Started

Note: This is a series of articles sorted into categories. Each category is dedicated to a separate firebase tool. The first part is an introduction to firebase and its benefits.

Introduction

What is Firebase?

Firebase is a backend-as-a-service platform that provides a comprehensive suite of tools for web developers. It offers a variety of services such as authentication, database, storage, hosting, and more, all in one platform. With Firebase, web developers can build robust and scalable web applications with ease and efficiency. In this blog, we will be exploring the basics of Firebase and how to get started with using it for web development with a simple project. We will be covering topics such as setting up a Firebase project, integrating Firebase into your web application, and using the various services offered by Firebase. By the end of this blog, you will have a solid understanding of Firebase and be ready to start building your own web applications with it.

Benefits of using Firebase for web development

Firebase is an all-in-one platform that provides everything from authentication to analytics.

1. Backend-as-a-Service (BaaS) model

Firebase provides a whole backend infrastructure for web apps, removing the need for developers to build their own backend as well as set up and maintain their own servers.

Need to implement authentication? - Select from several providers or use native methods.
Need storage? Use Firestore or a real-time database, depending on your requirements.
Want to deploy in seconds? - Make use of Firebase hosting.
Want to test and monitor your app? - Make use of Crashlytics, Test lab, Performance report, and Remote configuration.
Looking for a way to expand your audience? - Experiment with A/B testing, Cloud messaging, Dynamic links, and so on.
Want to make money with your apps the smart way? - AdMob is here to help.

2. Real-Time Database

Firebase features a real-time NoSQL database (document-type database like MongoDB), allowing developers to store and retrieve data in real-time, enabling real-time updates and collaboration in web applications. You don't have to worry about building, deploying, or managing the database because Firebase manages the entire infrastructure.

This real-time database is also accessible for offline use. When a user's internet connection is lost, Firebase uses data from the local cache, which is then synchronized when the user reconnects. We'll see it in action in a future article.

3. Authentication

Firebase provides a comprehensive authentication system that supports multiple authentication methods, including email and password, social media logins, and more.

Firebase authentication supports a variety of sign-in methods, including native providers such as Email/Password, Phone, or even anonymous, as well as other providers such as Google, Yahoo, Facebook, Twitter, GitHub, Google Play, Apple, Microsoft, and Game Center, as well as custom providers such as SAML and OpenID Connect.

4. Storage

Firebase offers secure cloud storage for storing and serving user-generated content, such as images and videos. These files can be uploaded, downloaded, or deleted without the use of any server-side code. All of these files are protected by firebase security rules, so simply use firebase storage and relax.

5. Hosting

Firebase provides hosting for web applications, allowing developers to quickly and easily deploy their applications without having to set up their own servers. You can also add custom domains.

6. Analytics

Firebase provides detailed analytics for web applications, allowing developers to track user behavior and make data-driven decisions to improve their applications.

7. Integration with other Google services

Firebase integrates seamlessly with other Google services, such as Google Cloud Functions and Google Analytics, enabling developers to build more powerful and feature-rich web applications.

The Project

The project is a simple e-commerce application built with NextJs.

Main features:

Different authentication methods using firebase authentication.
Store users' data like avatars, product review images, and so on with firebase storage.
Update product info in real-time with firebase real-time database.
Send different types of notifications to users using firebase cloud messaging.
And a lot more.

Excited? Follow to get updates.

How Feature Flags Can Help You Ship Faster and Smarter?

Rakesh Potnuru — Tue, 31 Jan 2023 05:38:22 +0000

Are you tired of long development cycles and hesitant to push new features to production? Feature flags may be the solution you're looking for. In this blog post, we'll explore how feature flags can streamline your development process, reduce the risk of errors, and give you more control over the features you release to your users. From testing new features to rolling out changes to a select group of users, feature flags can help you do it all. Keep reading to learn how you can start using feature flags in your development workflow today.

Let's Get Started

What are Feature Flags?

Feature flags are a way to control what features your users see. You can use them to experiment with new features, collect data and make sure things are working correctly before you roll them out to everyone.

Consider feature flags to be switches. You can use feature flags to turn on and off features of your product in the same way that you would turn on and off lights using a switch. You don't have to rewire your house to toggle the light, and you don't have to make code changes to toggle features with feature flags.

With feature flags, you may test your features on a small group of users. If all goes well and you and that small group of people are satisfied with the new feature, you can make it available to the general public. This enables you to develop your product smarter than ever before 😎. Also, this style of software development is usually less expensive than traditional software development.

What is ConfigCat?

ConfigCat is a feature flag management service and LaunchDarkly alternative. It allows software engineers/developers to remotely control the behavior of their applications without needing to redeploy the code. This means that new features can be tested and rolled out to production gradually, and bugs can be fixed without having to take the entire application offline. With ConfigCat, developers can use feature flags to implement a continuous deployment process, enabling them to release new features and updates faster, with less risk.

Not only that, but you can also create batches of users to target specific users. You can create groups if, for example, you wish to disable a feature for users in a specific country or only enable beta users to access certain features.

ConfigCat Vs LaunchDarkly

Both ConfigCat and LaunchDarkly are feature flag management services that allow developers to remotely control the behavior of their applications without needing to redeploy the code. Some of the key differences are:

LaunchDarkly pricing Vs ConfigCat

Freemium - ConfigCat's generous forever free plan with unlimited team size, monthly active users, and connected instances is one of the main reasons to choose them over LaunchDarkly.
Team Size - ConfigCat provides unlimited team size for all plans, but LaunchDarkly charges per seat.
ConfigCat costs by the number of feature flags, whereas LaunchDarkly charges by the number of monthly active users (only client side).
Furthermore, ConfigCat offers its pro plan for free to students and has a custom pricing plan for teachers. ConfigCat's pricing plan is honestly more appealing to me than LaunchDarkly's.

Privacy and Security

ConfigCat includes security features (2FA, SSO, SAML, and Active Directory) in all of their plans, whereas LaunchDarkly requires a fee and most security features are only available in the pro and enterprise subscriptions. And LaunchDarkly has no data governance.

Find out more differences here.

See it in Action

Let's learn how to add feature flags in a React project and manage them with ConfigCat. For this, I built a sample React project or you can try with your own project.

Prerequisites

Sign up for a free ConfigCat account. (If you are a student you can opt for pro plan)
Basics of React are good to have but not necessary.

The Project

Our sample application is a very simple note-taking app.

Clone/download the project from the GitHub
Familiarize yourself with the project.
Install the dependencies with this command.

yarn

Start the project.

yarn start

Open a browser and navigate to http://localhost:3000.

Creating feature flags in ConfigCat

Open the ConfigCat dashboard to begin creating feature flags. An example feature flag called isMyFirstFeatureEnabled has been provided for you. You can either delete it by clicking the X or leave it alone.
Click + ADD FEATURE FLAG.

Give your flag a name, use isTitleFeatureEnabled for the key, set the initial values to "On," and then click ADD FEATURE FLAG. A flag will be created.

Configure React app

First, install the configcat-react npm package.

yarn add configcat-react

Launch your editor and open the project. Create a .env file in the project's root directory and include this environment variable. You can obtain the SDK key from the ConfigCat dashboard by clicking the VIEW SDK KEY button in the upper-right corner.

REACT_APP_CONFIGCAT_SDK_KEY=YOUR_CONFIGCAT_SDK_KEY

Open the index.js file which is located in the /src folder. Wrap the </App> component with ConfigCatProvider

<ConfigCatProvider
    sdkKey={process.env.REACT_APP_CONFIGCAT_SDK_KEY}
    pollingMode={PollingMode.AutoPoll}
    options={{ pollIntervalSeconds: 30 }}
  >
    <App />
</ConfigCatProvider>

pollingMode - Polling is a method for retrieving setting values from ConfigCat. PollingMode. Autopoll was used in this case. In this mode, ConfigCat SDK automatically downloads the most recent values and keeps them in the cache. We set pollIntervalSeconds to 30, which means ConfigCat downloads the most recent values every 30 seconds. This will be demonstrated in a moment. Now we can use feature flags in our project.

Feature flags usage

1. Title feature

If you tried the project, when you add a new note, you give it a title. Because a note may not require a title, we decided to test it with beta users. We will eventually extend out to all users based on feedback and usage from beta users.

To do so, let's first add a feature flag to the title input. This title input is located in /src/components/CreateArea.jsx file and at line 41.

...
import { useFeatureFlag } from "configcat-react";
...

function CreateArea(props) {
    ...
    const {
        value: isTitleFeatureEnabled,
        loading: isTitleFeatureEnabledLoading,
    } = useFeatureFlag("isTitleFeatureEnabled", false);
    ...

    return (
    ...
        {!isTitleFeatureEnabledLoading && isTitleFeatureEnabled && (
            <input
                onChange={handleChange}
                name="title"
                placeholder="Title"
                value={inputText.title}
                autoComplete="off"
            />
        )}
    ...
    )
}

What we did above is really straightforward. Using the useFeatureFlag hook, we first obtained the isTitleFeatureEnabled flag values and used them while rendering the UI. So we simply hide and expose the UI, which is good.

All you have to do now is toggle flags on the ConfigCat dashboard. Changes will be reflected within 30 seconds.

2. Delete feature

Let's say we are adding a delete feature to notes. But we first want to release it in one country and gradually roll it out to other countries. Let's learn how to use target rules but first add a feature flag. I already created a flag in the ConfigCat dashboard with the key isDeleteFeatureEnabled. So go ahead and create this flag.

The delete button and its implementation are located in /src/components/Note.jsx file.

...
import { useFeatureFlag } from "configcat-react";
...

function CreateArea(props) {
    ...
    const userObject = {
        identifier: "643564",
        email: "rakesh@example.com",
        country: "Japan",
    };
  
    const {
        value: isDeleteFeatureEnabled,
        loading: isDeleteFeatureEnabledLoading,
    } = useFeatureFlag("isDeleteFeatureEnabled", false, userObject);

    function handleClick() {
        if (!isDeleteFeatureEnabled) {
            return;
        }
        props.deleteNote(props.id);
    }
    ...

    return (
    ...
        {!isDeleteFeatureEnabledLoading && (
            <button onClick={handleClick} disabled={!isDeleteFeatureEnabled}>
              <DeleteIcon />
            </button>
         )}
    ...
    )
}

Here, we not only hide and expose UI but also disable the delete functionality.
In the above code, you see userObject. You need to pass this object to make the target rules to work. Usually, we get this data from the backend; however, because this is only an example, I hard-coded values.

Creating target rules

As the name suggests, target rules are the rules used to target specific users. Let's create our first target rule.
Click ADD NEW TARGETING RULE. Select Country from the first dropdown, IS ONE OF (cleartext) from the second dropdown, and fill in the next text field with the countries where you want to release this feature.

To test this out, change the country in userObject and see.

Resources

Learn more about ConfigCat and feature flags from these resources,

ConfigCat blog
ConfigCat SDK references

Conclusion

Feature flags (sometimes loosely and erroneously referred to as feature toggle switches) are becoming a crucial component of modern software development. Whether you're a developer trying to make your code more modular, or a product manager looking to experiment more quickly, it's likely that feature flags can help you. The general concept is simple: for any given feature, a flag—either on or off—signals whether that functionality should be included in the application or not. Depending on the use case, that flag can be set by several different actors in the development process: the product owner who's vetting new features based on business value, a QA engineer who wants to exercise different test scenarios or an end user who wants to give their feedback on an upcoming version.

Follow me for more.