Javascript

How to Set Up OAuth with a Stripe App

Published May 24, 2022

Updated Feb 13, 2023

8 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Stripe Apps are a great way to extend Stripe dashboard functionality using third-party integrations. But when using these integrations, developers must prioritize security. The best way to do this is by using OAuth with the third-party product with which you would like to integrate.

However, there are some constraints, and we cannot use cookies to set up a cookie based authentication front-end only. In this article, we would like to show you how to do it with a NestJS back-end.

Stripe signatures

The best way to secure your API is by making sure that every request comes from a verified Stripe App instance. The @stripe/ui-extension-sdk package provides a way to generate a signature on the front-end side. This signature is valid for 5 minutes, and you can send it as a header for every request you make. For this to work, you need to have @stripe/ui-extension-sdk installed in your repository.

import fetchStripeSignature from "@stripe/ui-extension-sdk/signature";
// fetchStripeSignature returns with a Promise<string>

In order to properly validate this signature on your API, you will need some additional information to be sent in the request headers as well. That information is the Stripe user's ID, and the Stripe account's ID. We found that the best way is to implement a global context with this information.

import { createContext } from "react";
import { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
export const GlobalContext = createContext<{
  userContext: ExtensionContextValue["userContext"] | null;
  environment: ExtensionContextValue["environment"] | null;
}>({ userContext: null, environment: null });

The above context stores the ExtensionContextValue that gets passed from the Stripe dashboard to the app when it opens in the view. For example, if you are on a payment detail page, the userContext will contain information about your Stripe user, while the environment will provide you access to the object that you are viewing. In the above example, that would be the payment's ID as the objectContext.id property.

Let's set up the view with this global context.

import type { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
import { ContextView } from "@stripe/ui-extension-sdk/ui";
import { GlobalContext } from "./common/global-context";
const PaymentDetailView = ({
  userContext,
  environment,
}: ExtensionContextValue) => (
  <ContextView title={title || " "} description={description}>
    <GlobalContext.Provider value={{ userContext, environment }}>
      TODO: navigation and login will come here.
    </GlobalContext.Provider>
  </ContextView>
);
export default PaymentDetailView;

Now, we can set up a hook to provide a proper fetch method that always appends a Stripe signature, and the other required fields to the headers.

useFetchWithCredentials hook

In order to make our future job easier, we need to set up a hook that creates a proper wrapper around fetch. That wrapper will handle setting the headers for us. It needs to have access to our GlobalContext, so we can get the Stripe user's, and their account's, IDs.

import { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
import fetchStripeSignature from "@stripe/ui-extension-sdk/signature";
import { useCallback, useContext } from "react";
import { GlobalContext } from "../common/global-context";
export function useFetchWithCredentials() {
  const globalContext = useContext(GlobalContext);
  return useCallback(
    async (uri: string, { headers, ...options }: RequestInit = {}) => {
      const stripeSignature = await fetchStripeSignature();
      const headersObject = new Headers(headers);
      headersObject.append("stripe-signature", stripeSignature);
      headersObject.append("Content-Type", "application/json");
      headersObject.append(
        "stripe-user-id",
        globalContext.userContext?.id ?? ""
      );
      headersObject.append(
        "stripe-account-id",
        globalContext.userContext?.account.id ?? ""
      );
      return fetch(uri, {
        ...options,
        headers: headersObject,
      });
    },
    [globalContext]
  );
}

Let's set up a very basic component for demonstrating the use of the useFetchWithCredentials hook. This component will be the default route for our app's navigation wrapper. It is going to handle more later. But for now, let's just implement a basic use for our hook. The AUTH_INIT_URL constant will point at our back-end's /api/oauth/userinfo endpoint.

Please note that, for this to work, you are going to need to install react-router-dom.

import { Box, Spinner } from "@stripe/ui-extension-sdk/ui";
import { useEffect } from "react";
import { useNavigate } from "react-router-dom";
import { AUTH_INIT_URL } from "../constants/auth.urls";
import { setUser } from "../auth/state";
import { useFetchWithCredentials } from "../hooks/useFetchWithCredentials";
export const AuthInit: React.FC<{ redirectPath: string }> = ({
  redirectPath,
}) => {
  // Please note, that we are going to set the whole routing up in a later article.
  const navigate = useNavigate();
  const fetchWithCredentials = useFetchWithCredentials();
  useEffect(() => {
    fetchWithCredentials(AUTH_INIT_URL)
      .then((user) => {
        // Make sure you set the user in your chosen global state management tool.
        setUser(user);
        // For now if the response is a success response (status 200), we are going to navigate to the first authenticated route.
        navigate(redirectPath);
      })
      .catch((e) => {
        console.error(e.message);
        // If the request returns with an error (status 401), it means that the user is unauthenticated, so we send them to the login page
        navigate("/login");
      });
  }, [redirectPath]);
  // Let's display a spinner while we wait for our initial request to return.
  return (
    <Box
      css={{
        layout: "column",
        alignX: "center",
        alignY: "center",
      }}
    >
      <Spinner size="large" />
      Loading...
    </Box>
  );
};

As we can see from the above implementation, this component will be the initial component that gets rendered inside of the application. It will send out a request to determine if the user is logged in. If they are logged in, we are going to send them to a route that is the first page of our application. If they are not signed in, we are going to redirect them to our login page. This initial call, just as every other API call, must be verified and always have a Stripe signature.

Let's visualise how routing looks like right now:

import type { ExtensionContextValue } from "@stripe/ui-extension-sdk/context";
import { ContextView } from "@stripe/ui-extension-sdk/ui";
import { GlobalContext } from "./common/global-context";
import { Route, Routes } from 'react-router-dom';
import { PaymentInfo } from './components/PaymentInfo;
const PaymentDetailView = ({
  userContext,
  environment,
}: ExtensionContextValue) => (
  <ContextView title={title || " "} description={description}>
    <GlobalContext.Provider value={{ userContext, environment }}>
      <Router basename="/" initialEntries={['/init']}>
        <Routes>
          <Route
            path="/init"
            element={<AuthInit redirectPath={'/payment-details'} />}
          />
          <Route path="/login" element={<Login />} />
          <Route path="/payment-details" element={<PaymentInfo />}>
        </Routes>
      </Router>
    </GlobalContext.Provider>
  </ContextView>
);
export default PaymentDetailView;

Stripe secrets and the Stripe API

In order to be able to use the Stripe NodeJS Api, you will need two secrets from Stripe. One is your Stripe account's API key, and the other one is your Stripe-app's secret. You need to set up your .env file as the following.

STRIPE_API_KEY='your api key goes here'
STRIPE_APP_SECRET='your app secret goes here'

Stripe API key

You can find your Stripe API key at https://dashboard.stripe.com/apikeys, under the Standard keys section. The key you are looking for is called Secret key, and you need to reveal it by clicking the button that hides it.

Stripe App Secret

For this key, you are going to need to upload your stripe-app using the stripe apps upload command. Make sure that you set a development app ID in your app manifest (stripe-app.json). After you uploaded your app, visit https://dashboard.stripe.com/apps. Under My Apps, you should see your uploaded application. Open it and search for the Signing secret. Reveal it and copy it into your .env file.

Stripe NodeJS API

Please make sure you have installed the stripe nmp package for your server code. In this example series, we use NestJS as our framework for our API. We need the above two secret keys to be able to start up our Stripe API.

// verify-signature.ts
import { BadRequestException, Logger } from "@nestjs/common";
import { Stripe } from "stripe";
const STRIPE_API = new Stripe(process.env.STRIPE_API_KEY, {
  apiVersion: "2020-08-27",
});
const APP_SECRET = process.env.STRIPE_APP_SECRET;
export function verifySignature(
  userId: string,
  accountId: string,
  signature: string,
  logger: Logger
): void {
  // Signature verification will come here
}

NestJS VerifySignatureInterceptor implementation

In NestJS, we can use interceptors to abstract away repetitive logic that needs to be done on multiple requests. In our case, we need to verify almost every API for a valid Stripe signature. We have access to the proper secret keys, and we have a Stripe NodeJS API set up. Let's create our VerifySignatureInterceptor.

import {
  BadRequestException,
  CallHandler,
  ExecutionContext,
  Injectable,
  Logger,
  NestInterceptor,
} from "@nestjs/common";
import { Request } from "express";
import { Observable } from "rxjs";
import { Stripe } from "stripe";
const STRIPE_API = new Stripe(process.env.STRIPE_API_KEY, {
  apiVersion: "2020-08-27",
});
const APP_SECRET = process.env.STRIPE_APP_SECRET;
@Injectable()
export class VerifySignatureInterceptor implements NestInterceptor {
  // We set up a logger instance, so we can properly log errors
  private readonly logger = new Logger(VerifySignatureInterceptor.name);
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const req: Request = context.switchToHttp().getRequest();
    const signature = req.headers["stripe-signature"] as string;
    const userId = req.headers["stripe-user-id"] as string;
    const accountId = req.headers["stripe-account-id"] as string;
    verifySignature(userId, accountId, signature, this.logger);
    return next.handle();
  }
}

Every interceptor must implement the intercept() method. We extract the Request object from the execution context, and we get the headers that we previously set in our useFetchWithCredentials hook. We call our verifySignature function which will throw errors if the signature is invalid. We also pass the Logger instance, so we can determine when an error comes from this interceptor in our logs.

Please be aware that there are several reasons signature verification can go wrong, like if we provide the wrong Stripe account keys or app secrets. In order for you to be able to easily debug these issues, proper logging is a must. That is why we set up a Logger instance in our interceptor.

// ...
export function verifySignature(
  userId: string,
  accountId: string,
  signature: string,
  logger: Logger
): void {
  if (!(user_id && account_id && signature)) {
    throw new BadRequestException("Missing user identifiers");
  }
  try {
    stripe.webhooks.signature.verifyHeader(
      JSON.stringify({ user_id, account_id }),
      signature,
      APP_SECRET
    );
  } catch (e: any) {
    logger.error(`Could not verify signature due to: ${e.message}`);
    throw new BadRequestException("Could not verify signature");
  }
}

If the user_id, account_id, or the signature are missing, that could mean that the request came from outside a stripe application, or the useFetchWithCredentials hook was not used. We throw a BadRequestException that will result in the request sending back a status: 400 HTTP response.

If the signature verification fails, that could mean that a not valid signature was used in the request, or that the API environment variables might have the wrong keys.

Set up the userinfo endpoint

Let's quickly set up our /api/oauth/userinfo endpoint. For that, we are going to create the OauthModule and the OauthController.

// oauth.module.ts
import { Module } from "@nestjs/common";
import { OauthController } from "./oauth.controller";
@Module({
  controllers: [OauthController],
})
export class OauthModule {}

In our controller, we decorate our getUserInfo() method, with the @Get() decorator, so we set up the route. We also decorate the method with the @UseInterceptors() decorator, where we pass our VerifySignatureInterceptor.

// oauth.controller.ts
import {
  Controller,
  Get,
  Headers,
  Logger,
  UnauthorizedException,
  UseInterceptors,
} from "@nestjs/common";
import { VerifySignatureInterceptor } from "./interceptors/verify-signature.interceptor";
import { UserInfo } from "../interfaces/user";
@Controller("oauth")
export class OauthController {
  // We set up our Logger instance here as well
  private readonly logger = new Logger(OauthController.name);
  @Get("userinfo")
  @UseInterceptors(VerifySignatureInterceptor)
  async getUserInfo(
    @Headers("stripe-account-id") accountId: string,
    @Headers("stripe-user-id") userId: string
  ): Promise<UserInfo> {
    // For now, we always throw an unauthorised exception, so our front-end will load the login page
    throw new UnauthorizedException();
  }
}

This setup will enable us to call the /api/oauth/userinfo endpoint which will, in-turn, check if we have a valid signature present in the headers. If the request is invalid, it will throw a 400 Bad Request exception. If the signature is valid, for now, we will throw a 401 Unauthorized exception just to make our front-end navigate to the login page.

Just to keep this example simple, our login page will only have a button in the center that will start our login flow with our API.

import fetchStripeSignature from '@stripe/ui-extension-sdk/signature';
import { LOGIN_URI } from '../../constants/url.constants';
import { Box, Button } from '@stripe/ui-extension-sdk/ui';
import { GlobalContext } from '../../common/global-context';
export const Login: React.FC = () => {
  const globalContext = useContext(GlobalContext);
  const [stateKey, setStateKey] = useState<string | null>(null);
  // setting the stateKey will be implemented here
  const queryParams = new URLSearchParams({
    state: stateKey as string,
  })
  // LOGIN_URI points to our API at the '/api/oauth/login' endpoint
  const loginUrl = `${LOGIN_URI}?${queryParams}`
  return (
      <Box css={{
            height: 'fill',
            width: 'fill,
            layout: 'row',
            alignX: 'center',
            alignY: 'center'
      }}>
        <Button
            type="primary"
            css={{
                width: 'fill',
                alignX: 'center',
            }}
            disabled={!stateKey}
            href={loginUrl}
        >
          Sign in
        </Button>
      </Box>
  )
}

We need to create a state key, that can be validated before we fetch the token. This state key will first be sent to our third-party oauth client, and it will be returned to us when the authentication is finished. This key is passed securely and over https. Therefore, it can be a stringified object. While the key is not set, we disable the button.

import fetchStripeSignature from "@stripe/ui-extension-sdk/signature";
import { LOGIN_URI } from "../../constants/url.constants";
import { Box, Button } from "@stripe/ui-extension-sdk/ui";
import { GlobalContext } from "../../common/global-context";
export const Login: React.FC = () => {
  const globalContext = useContext(GlobalContext);
  const [stateKey, setStateKey] = useState<string | null>(null);
  useEffect(() => {
    // we create an async function which will get all the necessary data and then call JSON.stringify() on it
    const getStateKey = async () => {
      const signature = await fetchStripeSignature();
      const userId = globalContext.userContext?.id;
      const accountId = globalContext.userContext?.account.id;
      return JSON.stringify({ userId, accountId, signature });
    };
    getStateKey().then(setStateKey);
  }, [globalContext.userContext]);
  const queryParams = new URLSearchParams({
    state: stateKey as string,
  });
  // LOGIN_URI points to our API at the '/api/oauth/login' endpoint
  const loginUrl = `${LOGIN_URI}?${queryParams}`;
  return {
    /* ... */
  };
};

Pressing the Sign in button will call our API that will redirect us to our third-party login screen. When the login happens, it will redirect us to our API, where we can fetch a valid token and redirect again to the Stripe dashboard. Let's extend our environment variables.

STRIPE_API_KEY='your api key goes here'
STRIPE_APP_SECRET='your app secret goes here'
STRIPE_REDIRECT_URL='https://dashboard.stripe.com/test/apps-oauth/your.app.id'
## The above url is set to the development preview redirect url. In production, this url will look like the following:
## STRIPE_REDIRECT_URL='https://dashboard.stripe.com/apps-oauth/your.app.id'
## Don't forget that your app-id in development and in production should be different
THIRD_PARTY_CLIENT_ID='your client id goes here'
THIRD_PARTY_CLIENT_SECRET='your client secret goes here'
THIRD_PARTY_URL_BASE='https://third-party.com'
API_HOST_URL='http://localhost:3333'
## In production, the above url should point to your deployed back-end

Now that we have every environment variable set up, let's implement our api/oauth/login and api/oauth/authorise endpoints in our OauthController.

// ...
const THIRD_PARTY_OAUTH_URL = `${process.env.THIRD_PARTY_URL_BASE}/oauth`;
const API_AUTH_CALLBACK_URL = `${process.env.API_HOST_URL}/api/oauth/authorise`;
@Controller("oauth")
export class OauthController {
  // ...
  @Get("login")
  @Redirect(THIRD_PARTY_OAUTH_URL, 303)
  // the HasValuePipe checks if the state is not an empty string or undefined.
  login(@Query("state", HasValuePipe) state: string): { url: string } {
    const queryParams = new URLSearchParams({
      response_type: "code",
      client_id: process.env.THIRD_PARTY_CLIENT_ID,
      redirect_uri: API_AUTH_CALLBACK_URL,
      state,
    });
    // with the query parameters set, we redirect to our third-party oauth page
    return {
      url: `${THIRD_PARTY_OAUTH_URL}?${queryParams.toString()}`,
    };
  }
}

The login endpoint, if everything is correct, redirects us to the login page where the user should be able to log in. Make sure that if you oauth client needs to have configured redirect urls, you configure them. For example, for development, the http://localhost:3333/api/oauth/authorise endpoint should be in the allowed redirect url list.

@Controller("oauth")
export class OauthController {
  // ...
  @Get("authorize")
  @Redirect(process.env.STRIPE_REDIRECT_URL, 303)
  async loggedIn(
    @Query("state", HasValuePipe) state: string,
    @Query("code", HasValuePipe) code: string
  ) {
    // If either the state or the code is missing, we return with a 400 Bad Request response
    if (!state || !code) {
      throw new BadRequestException();
    }
    let userId: string;
    let accountId: string;
    let signature: string;
    try {
      const _ = ({ userId, accountId, signature } = JSON.parse(state));
    } catch (error: any) {
      // If the state is not a valid JSON we can be sure that we won't be able to
      this.logger.error(`Invalid state returned to the authorise endpoint`);
      throw new BadRequestException();
    }
    // We verify the signature to make sure it comes from our Stripe app.
    verifySignature(userId, accountId, signature, this.logger);
    // see implementation below
    await this.fetchToken(accountId, userId, code).catch(
      (error: AxiosError) => {
        if (error.response) {
          throw new UnauthorizedException();
        }
        throw new InternalServerErrorException(
          "Cannot contact authentication server"
        );
      }
    );
  }
}

We validate everything to be sure that this endpoint was called from our third-party OAuth page. With the information available to us, we can fetch the access token and store it in the Stripe Secret Storage. In this example, we use axios in our bakc-end to send requests to our third-party API.

// ...
const THIRD_PARTY_TOKEN_URI = `${process.env.THIRD_PARTY_URL_BASE}/token`;
@Controller("oauth")
export class OauthController {
  // ...
  constructor(private secretService: SecretService) {}
  // ...
  private async fetchToken(
    accountId: string,
    userId: string,
    code: string
  ): Promise<void> {
    const data = {
      grant_type: "authorization_code",
      client_id: process.env.THIRD_PARTY_CLIENT_ID,
      client_secret: process.env.THIRD_PARTY_CLIENT_SECRET,
      code,
    };
    const response = await axios.post(THIRD_PARTY_TOKEN_URI, data, {
      responseType: "json",
    });
    // Please note that the third-party API you integrate with might have a different response structure.
    const { access_token } = response.data;
    // We set the token in the secret store. See the implementation below. The Secret Store only accepts strings as values.
    // The accountId is needed so we can scope the request to the requestor user's Stripe account.
    // The userId is needed so we can use the requestor user's secrets
    // We set the secret name to 'access_token', and we pass the token as its value.
    await this.secretService.addSecret(
      accountId,
      userId,
      "access_token",
      access_token
    );
  }
}

We exchange our code returned from our OAuth client to a valid access token, and then store it in the Stripe Secret Store. That logic got extracted into a SecretService class, because the logic implemented in it can be reused later for other API calls. Please make sure you set up a NestJS module that exports this service.

Stripe Secret Store

Stripe's Secret Store API enables your app to securely store and retrieve strings that can be authentication credentials, tokens, etc. This API enables users to stay logged in to third party services even when they log out of their Stripe dashboard. Let's set up a service that handles access to the Secret Store on our back-end.

import { Stripe } from "stripe";
interface Secret {
  id: string;
  name: string;
  payload: string;
}

// With the below setup, we can communicate with the Stripe Secret Store.
const SecretResource = Stripe.StripeResource.extend({
  find: Stripe.StripeResource.method({
    method: "GET",
    path: "apps/secrets/find",
  }) as (...args: any[]) => Promise<Secret>,
  set: Stripe.StripeResource.method({
    method: "POST",
    path: "apps/secrets",
  }) as (...args: any[]) => Promise<Secret>,
  delete: Stripe.StripeResource.method({
    method: "POST",
    path: "apps/secrets/delete",
  }) as (...args: any[]) => Promise<Secret>,
});
@Injectable()
export class SecretService {
  // To make calls for connected accounts, we should create a new Stripe API instance every time.
  private getSecretResource(stripeAccount: string): Stripe {
    const client = new Stripe(process.env.STRIPE_API_KEY, {
      apiVersion: "2020-08-27",
      stripeAccount,
    });
    return new SecretResource(client);
  }
}

Adding secrets

As we can see above, the Secret Storage needs some preliminary setup, which we do in our SecretService. The StripeResource sets up the find, set, and delete methods on the Stripe Api, and interacts with the Secret Store. Let's implement the addSecret method, so we can actually store our returned token.

import { Stripe } from "stripe";
interface Secret {
  id: string;
  name: string;
  payload: string;
}
@Injectable()
export class SecretService {
  // ...
  async addSecret(
    accountId: string,
    userId: string,
    secretName: string,
    value: string
  ): Promise<Secret | null> {
    return this.getSecretResource(accountId)
      .set({
        "scope[type]": "user",
        "scope[user]": userId,
        name: secretName,
        payload: value,
      })
      .catch((error: any) => {
        this.logger.error(
          `Could not set secret to Stripe Secret Store: ${error.statusCode} - ${error.message}`
        );
        return null;
      });
  }
}

With the above, we can finally store our token with which we can make authenticated requests.

Getting secrets

Let's implement the getSecret so we can retrieve secrets. The principles are the same. We will need the accountId, the userId, and the secret's name for it.

import { Stripe } from "stripe";
interface Secret {
  id: string;
  name: string;
  payload: string;
}
@Injectable()
export class SecretService {
  // ...
  async getSecret(
    accountId: string,
    userId: string,
    secretName: string
  ): Promise<Secret | null> {
    const secret = await this.getSecretResource(accountId)
      .find({
        "scope[type]": "user",
        "scope[user]": userId,
        name: secretName,
        "expand[]": "payload",
      })
      .catch((error: any) => {
        if (error.statusCode === 404) {
          throw new UnauthorizedException();
        } else {
          this.logger.error(
            `Could not get secret from Stripe Secret Store: ${error.statusCode} - ${error.message}`
          );
          return null;
        }
      });
    if (!secret) {
      throw new UnauthorizedException();
    }
    return secret.payload;
  }
}

Let's close the login flow, and implement the final version of the api/oauth/userinfo endpoint.

// ...
const THIRD_PARTY_WHO_AM_I_URL = `${process.env.THIRD_PARTY_URL_BASE}/oauth/whoami`;
@Controller("oauth")
export class OauthController {
  // ...
  constructor(private secretService: SecretService) {}
  @Get("userinfo")
  @UseInterceptors(VerifySignatureInterceptor)
  async getUserInfo(
    @Headers("stripe-account-id") accountId: string,
    @Headers("stripe-user-id") userId: string
  ): Promise<UserInfo> {
    const token = await this.secretService.getSecret(
      accountId,
      userId,
      "access_token"
    );

  const user = await axios
      .get<UserInfo>(THIRD_PARTY_WHO_AM_I_URL, {
        responseType: "json",
        headers: {
          authorization: `Bearer ${token}`,
        },
      })
      .catach(() => {
        throw new UnauthorizedException();
      });
    // We add an extra layer of security by requiring the user to verify their e-mail.
    if (!user.email_verified) {
      throw new UnauthorizedException();
    }
    return user;
  }
}

Deleting secrets

We want our users to have ability to log out from our third-party API as well. That can be achieved by deleting their access_token from the Secret store.

import { Stripe } from "stripe";
// ...
@Injectable()
export class SecretService {
  // ...
  async deleteSecret(
    accountId: string,
    userId: string,
    secretName: string
  ): Promise<boolean> {
    return this.getSecretResource(accountId)
      .delete({
        "scope[type]": "user",
        "scope[user]": userId,
        name: secretName,
      })
      .then(() => true)
      .catch((error: any) => {
        this.logger.error(
          `Could not delete secret from Stripe Secret Store: ${error.statusCode} - ${error.message}`
        );
        return false;
      });
  }
}

The /api/oauth/logout endpoint is going to be a GET request, that will delete the token from the Secret Store.

// ...
@Controller("oauth")
export class OauthController {
  // ...
  @Get("logout")
  @HttpCode(204)
  @UseInterceptors(VerifySignatureInterceptor)
  async deleteToken(
    @Headers("stripe-account-id") accountId: string,
    @Headers("stripe-user-id") userId: string
  ): Promise<boolean> {
    return this.secretService.deleteToken(accountId, userId, "access_token");
  }
}

We can create a SignOutLink that will send the request to our back-end and navigates to the /login page. You can put this component into the footerContent property of your ContextView.

import { LOGOUT_URI } from "../../constants/url.constants";
import { useFetchWithCredentials } from "../../hooks/useFetchWithCredentials";
import { Link } from "@stripe/ui-extension-sdk/ui";
import { useNavigate } from "react-router-dom";
export const SignOutLink = () => {
  const navigate = useNavigate();
  const fetchWithCredentials = useFetchWithCredentials();
  return (
    <Link
      onPress={() => {
        fetchWithCredentials(LOGOUT_URI).then(() => {
          navigate("/logout");
        });
      }}
    >
      Sign out
    </Link>
  );
};

And now we are ready with our authentication setup. When the user opens our app, it will call the /api/oauth/userinfo endpoint. Initially, it will return with a 401 error, and our front-end will navigate to the /login route. When the user presses the Sign in button, it will redirect them to the third-party OAuth page. After they log in, our back-end also redirects them back to their Stripe dashboars where the application will open. The app will call the /api/oauth/userinfo endpoint again. But this time, it will return an actual user information and it routes to the protected route.

To help visualize the whole flow, you can also use the following sequence diagram for reference:

Conclusion

As you can see, there are many steps involved in setting up a proper OAuth flow. However, it's necessary to make it right, since this is the most critical part of the app. We hope blog post article will help you to set up some good foundations when implementing your own Stripe app.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Balázs Tápai
He is a Software Engineer with a passion for automated testing. He loves Angular on the Front-End and NestJS on the Back-End. He also uses Cypress to reduce developer anxiety before demo meetings.
@TapaiBalazs @TapaiBalazs
Dario Djuric
Dario is a full-stack engineer who has spent most of his career doing enterprise Java projects. He has always had a hidden passion for frontend, though -- and he is now able to pursue that passion at This Dot. He spends most of his free time with his two sons, but occasionally, he manages to squeeze in some casual sports activities such as jogging, cycling, and soccer.
@dario_djuric @dariodjuric

Deploying apps and services to AWS using AWS Copilot CLI

Copilot has become a household name for developers, all thanks to GitHub’s popular AI tooling. Before GitHub released Copilot, AWS already had a developer tool in the wild, also named Copilot. I stumbled across AWS Copilot a year or two ago and found it to be a really great tool for easily deploying Serverless applications and services to AWS infrastructure. Since deploying to AWS has been such a huge pain point for so many developers, Copilot CLI is one of many tools that is designed to make this process a lot easier. AWS Copilot is a command-line interface (CLI) that simplifies the process of deploying and managing containerized applications on AWS. It abstracts away the complexity of managing infrastructure, allowing us to focus on writing code. This blog post will provide an overview of AWS Copilot CLI and explore its practical use cases. AWS Copilot CLI is designed to simplify the building, releasing, and operating of production-ready containerized applications on Amazon ECS and AWS Fargate. It offers an intuitive interface for developers to launch and manage environments, jobs, pipelines, and services in the cloud. Although ECS and Fargate are considered ‘Serverless’; you are actually deploying to more traditional, stateful, web servers on EC2 _(these are cool again)_. Installation You can install the Copilot CLI using Homebrew. ` Otherwise use one of the scripts from the installation page. Credentials You need to add AWS credentials with proper permissions to your ~/aws/.credentials file to use Copilot. See the credentials docs for more details on this. ` Overview All you need is a Dockerfile that knows how to build and run your application and Copilot will handle the rest. Copilot provides a simple declarative set of commands, including examples and guided experiences built-in. These commands make it easy to start from scratch and get a containerized application running in the cloud in just a few steps. The configuration files that Copilot generates (called manifests) allow us to easily configure and adjust the amount of compute resources available to our web service _(cpu, memory, instances, etc)_. Here’s an architecture diagram for a load-balanced web service running on AWS and deployed with Copilot. The outermost layer is the region your application is deployed to on AWS ie: us-east-1, us-west-1, etc. Copilot handles all the networking for your application which includes a VPC, and public subnets that your server instances can be reached from. The load balancer (ALB) sits at the top, listens for requests, and directs traffic to the ECS Cluster (instances of your application server). Typically, the work involved with setting all of these pieces up and getting them working together is cumbersome to put it lightly. Concepts Before we dive into some of the commands, a quick look at the concepts that Copilot is built on so we have a clear understanding of what we can achieve with it. Applications Applications in Copilot is the top-level parent of all the AWS infrastructure managed by your Copilot setup. In this article I will generally refer to an application as any kind of software that you are deploying (api server, etc). In Copilot your ‘Application’ is the entire collection of all the environments and services that you have configured. Here’s the diagram from the documentation. The Vote application can consist of a number of different services, jobs, pipelines, etc. Services In AWS Copilot, “Services” refer to the type of application (not to be confused with the definition of Application in the previous section) that you’re deploying and the underlying AWS service infrastructure that supports it. Using the Load Balanced Web Service service from the diagram above, the service consists of the ECS (Elastic Container Service) service, the application load balancer, and the network load balancer. These are some of the AWS infrastructure that Copilot orchestrates for you when deploying this type of “Service”. There are a few main types of services that you can deploy with Copilot - Internet-facing web services (Static Site, Load Balanced Web Service, etc) - Backend services (services that can only be accessed internally) - Worker services (pub/sub queues, etc) Environments When setting up your project and your first service you will supply Copilot with the name of the environment you want to deploy to. For example, you can create a production environment initially to deploy your application and services to and then later on add additional environments like a staging environment. Jobs You might also know these as ‘crons’ but these are just tasks or some code that runs on a schedule. Pipelines Pipelines are for automating tests and releases. This is AWS’s CI/CD service somewhat similar to something like GitHub actions. Copilot can initialize and create new pipelines for you. We can configure this as a manifest in our codebase that declares instructions on how we build and deploy our application(s). Configuration Copilot is configured through various configuration files called ‘Manifests’. The documentation contains examples on how to configure your application, services, environments, jobs, and pipelines. You can also refer to it to learn what options are available. Since Copilot is a CLI tool they make a lot of the configuration process pretty painless by providing walkthrough prompts and generating configuration files for you. The CLI Now that we have a pretty good idea of what AWS Copilot is and the types of things we can accomplish with it, let's walk through using the CLI. ` This is where you will most likely want to start to get your application ready for deployment to AWS. The init command will prompt you with questions like what kind of service you want to generate and once you’re done, it will generate all the initial configuration files for you. Example setup: ` You’ll pick your service type, tell Copilot where your Dockerfile lives, name your environment, and let it do its magic from there. Copilot will generate your Manifest/config files which in turn become CloudFormation stacks that set up all your infrastructure on AWS. Other Commands There are commands for each concept that we covered above. There are Create, Delete, and Deploy operation commands for Environments, Services, Jobs, and Pipelines. If you wanted to add a staging environment to your application you could just run copilot env init . There are also commands to manage your Application or things like tasks. To see details about your Application you can run copilot app show -n [name] Conclusion AWS Copilot CLI is a powerful tool that simplifies the deployment and management of containerized applications on AWS. It abstracts away the complexities of the underlying infrastructure, allowing developers to focus on writing code and delivering value to their customers. Whether you're deploying a simple web service or managing multiple environments, AWS Copilot CLI can make your cloud development process more efficient and enjoyable....

Jan 3, 2024

6 mins

AWSToolingDocker

How Vim Transformed My Workflow for the Better

> Before getting into this article, I want to say that this is just my personal experience. I don’t think Vim is the best editor for everyone, but it worked well for me. What is Vim for you who don’t know? Well, Vim is a text editor, which is a tool you use to write and edit text or code on your computer. What makes Vim unique is that it has lots of keyboard shortcuts. Instead of using the mouse to click around, you can keep your fingers on the keyboard, making you faster once you get the hang of it. I've always heard good things about Vim. People say it’s great and that once you learn it, it can speed up your coding. Vim users sometimes act like they’re in a special club, which is funny. But jokes aside, I was curious because of all the good things I heard, especially about how comfy and efficient it is for coding. I knew learning Vim wouldn’t be easy. From past experiences (like learning touch typing), I knew it would be like climbing a steep hill. It's akin to learning to ride a bike with special gear. At first, it might feel tricky, but once you get used to it, you can ride faster and smoother. There’s a stage I like to call the "Hybrid" point. It's when you’re getting to grips with something new, and you're not proficient at it yet, but you also start losing comfort with the old way of doing things. This phase is a bit frustrating, and I wasn’t sure I wanted to go through this again as it could have led to a decrease in productivity, which was the opposite of what I was aiming for. However, the prospect of a smoother and faster coding experience kept me excited to try Vim. Discovering a New Coding Comfort Zone So, I began my journey with Vim. I started learning the basic moves by chatting with GPT and playing Vim Snake – A fun game that's like the classic snake game, but with Vim controls – Slowly but surely, I got the hang of it. Once I felt more at ease, I decided to add a Vim plugin to my IDE. Right now, I'm using IntelliJ. This plugin let me use Vim right inside IntelliJ. It was the best of both worlds—I could use Vim’s quick commands and still have my IDE’s features, plus the option to use my mouse when I wanted to. In the beginning, the transition was rough. I felt out of my element, constantly reaching for my mouse. My coding speed took a hit as I was making more mistakes. For instance, I’d try to edit a line of code, and end up deleting it or accidentally switching to another tab. It was frustrating. But I pushed through the initial hurdles, working in this odd hybrid mode with both my mouse and Vim commands. Gradually, things started to click and my workflow began to improve. As the weeks went by, I got more and more comfortable. There were times I’d code without touching the mouse, and let me tell you, it felt AMAZING. Here's why: Just using your keyboard to zip around your code is a total game-changer. Here's a simple example to illustrate this. Let's say you want to move the line of code you're on to the line below. Normally, you'd grab your mouse, highlight the code, cut it, hit enter to create a new line, paste the code, then put the mouse down to continue coding. With Vim, you just press the "dd" keys to cut and copy the line, then “p” to paste it below. And just like that, you're done! It may seem small, but when all these little time-savers add up, you end up saving a TON of time. Without Vim With Vim --- But the magic of Vim doesn't end there. You can tweak Vim in numerous ways by adding your own commands, modifying existing ones, or loading up on plugins to extend its functionality. For instance, I tried out the easy-motion plugin and it’s been a game-changer for navigating through files. I also set up shortcuts to switch between tabs, which has made things even smoother. With all these enhancements, I found myself breezing through code like a pro and seeing what I needed in no time. And if I ever need a new command, a quick chat with GPT sets me right back on track! The more I explored Vim, the more I discovered its immense potential. It's not just a text editor; it's a powerful tool that can be molded to fit your coding style. From creating custom key mappings to defining your own text objects, Vim allowed me to tailor my editing environment exactly how I wanted. And the community around Vim is incredible. There’s a plethora of resources: tutorials like vimtutor, courses such as Vim Basics Course, Learning Vim in a Week, interactive apps, blogs, and plugins available that can help overcome any challenge I faced. It's been a rewarding journey that not only improved my efficiency but also broadened my perspective on what's possible with the right tools. The journey with Vim has also opened up a new world of exploration for me. I’ve started checking out other text editors and tools that prioritize keyboard use, seeking to refine my setup further. Each new discovery, whether it's a handy plugin or a clever command, feels like unlocking a new level in a game. It’s exciting to think that there's so much more to learn and that I can continue to fine-tune my workflow. I know there's still much to explore, but the excitement keeps growing—it's genuinely enjoyable! Up next on my adventure is diving into Neovim, and I can't wait to share my experiences with it. Conclusion It's clear that stepping out of my comfort zone and delving into Vim has been nothing short of transformative. But it revamped my coding workflow and ignited a newfound curiosity to explore and learn. The hurdles encountered along the way were just stepping stones to achieving a level of proficiency that I now enjoy. Vim, with its simplicity yet profound flexibility, has proven to be more than just a text editor—it's a coder's companion on the journey towards efficiency and mastery. As I venture further, experimenting with Neovim and other tools, the horizon of possibilities keeps expanding. In the realm of coding, time is of the essence, and Vim has gifted me the ability to reclaim it, one keystroke at a time. It's not just about the shortcuts or the plugins; it's about the mindset of continuous learning and improvement that Vim instills. This blog post is not just an endorsement of Vim but a testament to the boundless exploration that awaits when one is willing to embrace new tools and methodologies....

Dec 20, 2023

5 mins

VimToolingSoftware EngineeringTips

Introducing the express-typeorm-postgres Starter Kit

Here at This Dot, we've been working with ExpressJS APIs for a while, and we've created a starter.dev kit for ExpressJS that you can use to scaffold your next backend project. The starter kit uses many well-known npm packages, such as TypeORM or BullMQ and integrates with databases such as PostgreSQL and Redis. Kit contents The express-typeorm-postgres starter kit provides you with infrastructure for development, and integrations with these infrastructures. It comes with a working Redis instance for caching and a second Redis instance for queues. It also starts up a Postgres instance for you, which you can seed with TypeORM. The infrastructure runs on docker using docker-compose. The generated project comes with prettier and eslint set-up, so you only need to spend time on configuration if you want to tweak or change the existing rules. Unit testing is set up using Jest, and there are some example tests provided with the example controllers. How to initialise API development usually requires more infrastructure than front-end development. Before you start, please make sure you have docker and docker-compose installed on your machine. To initialize a project with the express-typeorm-postgres kit, run the following: 1. Run npx @this-dot/create-starter to run the scaffolding tool 2. Select the Express.js, TypeORM, and PostgreSQL kit from the CLI library options 3. Name your project 4. cd into your project directory, and install dependencies using the tool of your choice (npm, yarn or pnpm) 5. copy the contents of the .env.example file into a .env file With this setup, you have a working starter kit that you can modify to your needs. TypeORM and Database When we started developing the kit, we decided to use PostgreSQL as the database, because it is a powerful, open-source object-relational database system that is widely used for storing and manipulating data. It has a strong reputation for reliability, performance, and feature richness, making it a great choice for a wide range of applications. It can also handle high levels of concurrency and large amounts of data, and supports complex queries and data types. Postgres is also highly extensible because it allows developers to add custom functions and data types to the database. It has a large and active community of developers and users who contribute to its ongoing development and support. The kit uses TypeORM to connect to the database instance. We chose TypeORM because it makes it easy to manage database connections and perform common database operations, such as querying, inserting, updating and deleting data. It supports TypeScript and a wide range of databases, such as PostgreSQL, MySQL, SQLite and MongoDB, therefore if you want to be able to switch between databases, it makes it easier. TypeORM also includes features such as database migrations, which help manage changes to database schema over time, and an entity model that allows you to define your database schema using classes and decorators. Overall, TypeORM is a useful tool for improving the efficiency and reliability of database-related code, and it can be a valuable addition to any TypeScript or JavaScript project that needs to interact with a database. To seed an initial set of data into your database, run the following commands: 1. npm run infrastructure:start - this starts up the database instance 2. npm run db:seed - this leverages TypeORM to seed the database. The seed command runs the src/db/run-seeders.ts file, where you can introduce your seeders for your own needs. The kit uses TypeORM-extension for seeding. Please refer to the src/db/seeding/technology-seeder.ts file for an example. Caching Storing response data in caches allows subsequent requests for the same data to be served more quickly. This can improve the performance and user experience of an API by reducing the amount of time it takes to retrieve data from the server. It can reduce the load on the database or mitigate rate limiting on third-party APIs called from your back-end. It also improves the reliability of an application by providing a fallback mechanism in case the database or the server is unavailable or slow to respond. There is a Redis instance set up in the kit to be used for caching data. Under the hood, we use the cachified library to store cached data in Redis. The kit has a useCache method exported from src/cache/cache.ts, which requires a key and a callback function to be called to fetch the data. ` When you need to invalidate cache entries, you can use the clearCacheEntry method by supplying a key string to it. It will remove the cached data from Redis, and the next request that fetches from the database will cache the new values. ` Under the src/modules/technology folder, you can see a complete example of a basic CRUD REST endpoint with caching enabled. Feel free to use those handlers as examples for your development needs. Queue A message queue allows different parts of an application, or different applications, to communicate with each other asynchronously by sending and receiving messages. This can be useful in a variety of situations, such as when one part of the application needs to perform a task that could take a long time, or when different parts of the application need to be decoupled from each other for flexibility and scalability. We chose BullMQ because it is a fast, reliable, and feature-rich message queue system. It is built on top of the popular Redis in-memory data store, which makes it very performant and scalable. It has support for parallel processing, rate limiting, retries, and a variety of other features that make it well-suited for a wide range of use cases. BullMQ has a straightforward API and good documentation. The kit has a second Redis instance set up to be used with BullMQ, and there is a queue set up out of the box, so resource-intensive tasks can be offloaded to a background process. The src/queue/ folder contains all the configuration and setup steps for the queue. Both the queue and its worker is set up in the queue.ts file. The job-processor.ts file contains the function that will process the data. To run int in a separate thread, we must pass the path to this file into the worker: ` When to use this kit This kit is most optimal when you: - want to build back-end services that can be consumed by other applications and services using ExpressJS - need a flexible and scalable way to build server-side applications - need to deal with CPU-intense operations on the server and you need a messaging queue - need to build an API with relational data - would like to just jump right into API development with ExpressJS using TypeORM and Postgres Conclusion The express-typeorm-postgres starter kit can help you kickstart your development by providing you with a working preset. It has testing configured, and it comes with a complete infrastructure orchestrated by docker-compose....

Jan 13, 2023

5 mins

NodeJSExpress.jsTypeScriptPostgreSQL

Increasing development velocity with Cursor

If you’re a developer, you’ve probably heard of Cursor by now and have either tried it out or are just curious to learn more about it. Cursor is a fork of VSCode with a ton of powerful AI/LLM-powered features added on. For around $20/month, I think it’s the best value in the AI coding space. Tech giants like Shopify and smaller companies like This Dot Labs have purchased Cursor subscriptions for their developers with the goal of increased productivity. I have been using Cursor heavily for a few months now and am excited to share how it’s impacted me personally. In this post, we will cover some of the basic features, use cases, and I’ll share some tips and tricks I’ve learned along the way. If you love coding and building like me, I hope this post will help you unleash some of the superpowers Cursor’s AI coding features make possible. Let’s jump right in! Cursor 101 The core tools of the Cursor tool belt are Autocomplete, Ask, and Agent. Feature: Autocomplete The first thing that got me hooked was Autocomplete. It just worked so much better than the tools I had used previously, like GitHub Copilot. It was quicker and smarter, and I could immediately notice the amount of keystrokes that it was saving me. This feature is great because it doesn’t really require any work or skilled prompting from the user. There are a couple of tricks for getting a little bit more out of it that I will share later, but for now, just enjoy the ride! Feature: Ask If you’ve interacted with AI/LLMs before, like ChatGPT - this is what the Ask feature is. It’s just a chat feature you can easily provide context to from your code base and choose which Model to chat with. This feature is best suited for just asking more general questions that you might have queried Google or Stack Overflow for in the past. It’s also good for planning how to implement a feature you’re working on. After chatting or planning, you can switch directly to Agent mode to pick up and take action on something you were cooking up in Ask mode. Here’s an example of planning a simple tic-tac-toe game implementation using the Ask feature: Feature: Agent Agent mode lets the AI model take the wheel and write code, make edits, or take other similar actions on your code base. The goal is that you can write prompts and give instructions, and the Agent can generate the code and build features or even entire applications for you. With great power comes great responsibility. Agents are a feature where the more you put into them, the more you get out. The more skilled you become in using them by providing better prompts and including the right context, you will continue to get better results. The AI doesn’t always get it right, but the fact that the models and the users are both getting better is exciting. Throughout this post, I will share the best use cases, tips, and tricks I have found using Cursor Agent. Here’s an example using the Agent to execute the implementation details of the tic-tac-toe game we planned using Ask: Core Concept: Context After understanding the features and the basics of prompting, context is the most important thing for getting the best results out of Cursor. In Cursor and in general, whenever you’re prompting a chat or an agent, you want to make sure that it has all the relevant information that it needs to provide an answer or result. Cursor, by default, always has some context of your code. It indexes your code base and usually keeps the open buffer in the context window at the very least. At the top left of the Ask or Agent panel, there is an @ button, and next to that are badges for all the current items that have been explicitly added to the context for the current session. The @ button has a dropdown that allows you to add files, folders, web links, past chats, git commits, and more to the context. Before you prompt, always make sure you add the relevant content it needs as context so that it has everything it needs to provide the best response. Settings and Rules Cursor has its own settings page, which you can access through Cursor → Settings → Cursor Settings. This is where you log in to your account, manage various features, and enable or disable models. In the General section, there is an option for Privacy Mode. This is one setting in particular I recommend enabling. Aside from that, just explore around and see what’s available. Models The model you use is just as important as your prompt and the context that you provide. Models are the underlying AI/LLM used to process your input. The most well-known is GPT-4o, the default model for ChatGPT. There are a lot of different models available, and Cursor provides access to most of them out of the box. Model pricing A lot of the most common models, like GPT-4o or Sonnet 3.5/3.7, are included in your Cursor subscription. Some models like o1 and Sonnet 3.7 MAX are considered premium models, and you will be billed for usage for these. Be sure to pay attention to which models you are using so you don’t get any surprise bills. Choosing a Model Some models are better suited for certain tasks than others. You can configure which models are enabled in the Cursor Settings. If you are planning out a big feature or trying to solve some complex logic issue, you may want to use one of the thinking models, like o1, o3-mini, or Deep Seek R1. For most coding tasks and as a good default, I recommend using Sonnet 3.5 or 3.7. The great thing about Cursor is that you have the options available right in your editor. The most important piece of advice that I can give in this post is to keep trying things out and experimenting. Try out different models for different tasks, get a feel for it, and find what works for you. Use cases Agents and LLM models are still far from perfect. That being said, there are already a lot of tasks they are very good at. The more effective you are with these tools, the more you will be able to get done in a shorter amount of time. Generating test cases Have some code that you would like unit tested? Cursor is very good at generating test cases and assertions for your code. The fewer barriers there are to testing a piece of code, the better the result you will get. So, try your best to write code that is easily testable! If testing the code requires some mocks or other pieces to work, do your best to provide it the context and instructions it needs before writing the tests. Always review the test cases! There could be errors or test cases that don’t make sense. Most of the time, it will get you pretty close to where you want to be. Here’s an example of using the Agent mode to install packages for testing and generate unit tests for the tic-tac-toe game logic: Generating documentation This is another thing we know AI models are good at - summarizing large chunks of information. Make sure it has the context of whatever you want to document. This one, in particular, is really great because historically, keeping documentation up to date is a rare and challenging practice. Here’s an example of using the Agent mode to generate documentation for the tic-tac-toe game: Code review There are a lot of up-and-coming tools outside of Cursor that can handle this. For example, GitHub now has Copilot integrated in pull requests for code reviews. It’s never a bad idea to have whatever change set you’re looking to commit reviewed and inspected before pushing it up to the remote, though. You can provide your unstaged changes or even specific commits as context to a Cursor Ask or Agent prompt. Getting up to speed in a new code base Being able to query a codebase with the power of LLM’s is truly fantastic. It can be a great help to get up to speed in a large new codebase quickly. Some example prompts: > Please provide an overview of this project and how to get started developing with it > I need to make some changes to the way that notifications are grouped in the UI, please provide a detailed analysis and pseudo code outlining how the grouping algorithm works If you have a question about the code base, ask Cursor! Refactoring Refactoring code in a code base is a much quicker process in Cursor. You can execute refactors depending on their scope in a couple of distinct ways. For refactors that don’t span a lot of files or are less complex, you can probably get away with just using the autocomplete. For example, if you make a change to something in a file and there are several instances of the same pattern following, the autocomplete will quickly pick up on this and help you tab through the changes. If you switch to another file, this information will still be in context and can be continued most of the time. For larger refactors spanning several files, using the Agent feature will most likely be the quickest way to get it done. Add all the files you plan to make changes to the Agent tab’s context window. Provide specific instructions and/or a basic example of how to execute the refactor. Let the Agent work, if it doesn’t get it exactly right initially, you can always give it corrections in a follow-up prompt. Generating new code/features This is the big promise of AI agents and the one with the most room for mixed results. My main recommendation here is to keep experimenting. Keep learning to prompt more effectively, compare results from different models, and pay attention to the results you get from each use case. I personally get the best results building new features in small, focused chunks of work. It can also be helpful to have a dialog with the Ask feature first to plan out the feature's details that the Agent can follow up on and implement. If there are existing patterns in your codebase for accomplishing certain things, provide this information in your prompts and make sure to add the relevant code to the context. For example, if you’re adding a new form to the web page and you have other similar forms that handle validation and making back-end calls in the same way, Cursor can base the code for the new feature on this. Example prompt: Generate a form for creating a new post, follow similar patterns from the create user profile form, and look to the post schema for the fields that should be included. Remember that you can always follow up with additional prompts if you aren’t quite happy with the results of the first.. If the results are close but need to be adjusted in some way, let the agent know in the next prompt. You may find that for some things, it just doesn’t do well yet. Mentally note these things and try to get to a place where you can intuit when to reach for the Agent feature or just write some of the code the old-fashioned way. Tips and tricks The more you use Cursor, the more you will find little ways to get more out of it. Here are some of the tips and patterns that I find particularly useful in my day-to-day work. Generating UI with screenshots You can attach images to your prompts that the models can understand using computer vision. To the left of the send button, there is a little button to attach an image from your computer. This functionality is incredibly useful for generating UI code, whether you are giving it an example UI as a reference for generating new UI in your application or providing a screenshot of existing UI in your application and prompting it to change details in reference to the image. Cursor Rules Cursor Rules allow you to add additional information that the LLM models might need to provide the best possible experience in your codebase. You can create global rules as well as project-specific ones. An example use case is if your project has some updated dependency with newer APIs than the one on which the LLM has been trained. I ran into this when adding Tailwind v4 to a project; the models are always generating code based on Tailwind v3 or earlier. Here’s how we can add a rules file to handle this use case: ` If you want to see some more examples, check out the awesome-cursorrules repository. Summary Learn to use Cursor and similar tools to enhance your development process. It may not give you actual superpowers, but it may feel like it. All the features and tools we’ve covered in this post come together to provide an amazing experience for developing all types of software and applications....

Apr 18, 2025

11 mins

AICursor

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to Set Up OAuth with a Stripe App

Stripe signatures

useFetchWithCredentials hook

Stripe secrets and the Stripe API

Stripe API key

Stripe App Secret

Stripe NodeJS API

NestJS VerifySignatureInterceptor implementation

Set up the userinfo endpoint

Stripe Secret Store

Adding secrets

Getting secrets

Deleting secrets

Conclusion

Balázs Tápai

Dario Djuric

You might also like

Deploying apps and services to AWS using AWS Copilot CLI

How Vim Transformed My Workflow for the Better

Introducing the express-typeorm-postgres Starter Kit

Increasing development velocity with Cursor

Let's innovate together!

You might also like

Deploying apps and services to AWS using AWS Copilot CLI

How Vim Transformed My Workflow for the Better

Introducing the express-typeorm-postgres Starter Kit

Increasing development velocity with Cursor

Stripe signatures

useFetchWithCredentials hook

Stripe secrets and the Stripe API

Stripe API key

Stripe App Secret

Stripe NodeJS API

NestJS VerifySignatureInterceptor implementation

Set up the userinfo endpoint

The Login flow

Stripe Secret Store

Adding secrets

Getting secrets

Deleting secrets

Conclusion

Balázs Tápai

Dario Djuric

Deploying apps and services to AWS using AWS Copilot CLI

How Vim Transformed My Workflow for the Better

Introducing the express-typeorm-postgres Starter Kit

Increasing development velocity with Cursor

Let's innovate together!

Deploying apps and services to AWS using AWS Copilot CLI

How Vim Transformed My Workflow for the Better

Introducing the express-typeorm-postgres Starter Kit

Increasing development velocity with Cursor