Deconstructing Stripe's email verification flow

Sriram Thiagarajan — Sun, 06 Mar 2022 15:53:36 +0000

I came across this tweet from @championswimmer and was intrigued about the feature & implementation.

Let's dig deeper.

Stripe's signup flow

When you sign up for a Stripe account, the app takes you to a dashboard page as soon as your account is created and shows a message asking you to verify your email address by clicking on the link sent to you email. Pretty standard right? Well, Stipe steps this UX up a notch by having a button on this landing page to open your email. And they take this to the next level by opening your email with a search query embedded to filter out only the emails sent by Stripe. This is an amazing UX.

As you might think, this doesn't work for all email addresses obviously because it's hard to know the URL for ton of email providers and not all of them support a search query in the URL to filter emails.

This flow works only for Gmail (both personal gmail.com accounts and other domains that have email hosted by Google Workspace). From my experiments, this button to open email works for Gmail & Outlook and the button clearly shows this with Open Gmail & Open Outlook labels respectively. I tried signing up with a Hey email address and there was no button to open email. Only a message was displayed to

Note: Both the email addresses shown below are not mine, Stripe one should've been obvious though :) Apologies to the owners of these emails. Sorry I had to test :P

Here's how it looks for a Hey email address:

And here's how it looks for a Gmail address (Stripe uses Gmail):

This is the URL the Open Gmail button opens:

https://mail.google.com/mail/u/sriram@stripe.com/#search/from:support@stripe.com

As you can see in the above URL, it has the search query which filters emails from support@stripe.com which is used to send out these verification emails.

Another learning from this exercise is that Gmail can take the email address in URL instead of numbers (0/ 1/ 2) as route param and open the correct one if you've logged into multiple accounts in your browser. You might have seen URLs like these:

mail.google.com/u/0
mail.google.com/u/1

You can actually put mail.google.com/u/<email> and it'll automatically redirect you to the correct account. It's brilliant that Gmail supports this and Stripe's team learnt & used it in their email verification flow to ensure that users don't land on their default Gmail account when they click on Open Gmail.

The How

So we want to find if an email address belongs to Gmail. The implementation of this seems to be fairly straightforward. If I want to implement this, I'd probably follow these steps:

1. Get the domain name from email address

This one's easy. Also check if the email is a valid one first. If the domain is gmail.com, you don't have to anything else :)

2. Do a DNS lookup and get MX records

If you're familiar with DNS records, you'd know that MX records are used for routing emails. Since we want to find if an email is hosted by Gmail, we need to first get these records for the domain.

This is quite easy with DNS-over-HTTPS (DoH). You could use the service from Google or Cloudflare.

3. Verify if MX records belong to Gmail

Google publishes MX records that one need to set if they want to get their domain configured for Google Workspace. You can find them here - https://support.google.com/a/answer/140034. So once you have the MX records of the domain, it's simply verifying if the records match at least one of the records provided by Google for Gmail. If it does, you can be sure that the email is provided by Gmail.

That's pretty much it. Once you know that the email is hosted on Gmail, you can use the same technique to add search query to the URL to filter out the mails sent by you.

What do you think about this? Have a different solution in mind? Feel free to ping me on twitter :)

Next.js' ISR vs Gatsby's DSG

Sriram Thiagarajan — Sat, 09 Oct 2021 10:37:35 +0000

When I heard about Gatsby adding a new rendering option called Deferred Static Generation in Gatsby 4, I thought it's similar to Next.js' Incremental Static Regeneration. Looking a bit deep into the DSG rendering option, it turns out there are quite a few differences. Hint: if you look closely at the names, you might be able to guess what the main difference is :) Let's see each of these options in detail.

Deferred Static Generation

From the docs - Deferred Static Generation is developers can choose to defer building certain pages until the first time a user requests it. This essentially means we're delaying the generation of the page until the first request. Once the page is generated, all subsequent users will see the same page from cache.

Incremental Static Regeneration

From the docs - Next.js allows you to create or update static pages after you’ve built your site. Incremental Static Regeneration (ISR) enables you to use static-generation on a per-page basis, without needing to rebuild the entire site. With ISR, you can retain the benefits of static while scaling to millions of pages. The key to note here is "create or update". Next.js ISR will be able delay the generation of a page until first request, and also be able to regenerate the page after a specific time has elapsed.

ISR vs DSG

As you would have seen from the above details, the main difference between ISR and DSG is that ISR will be able regenerate your page on a given interval. Once a page is generated, it'll be served from cache till the time it is regenerated and the regeneration happens in the background. This is really powerful as the page regeneration will be able to fetch updated data from your data source.

In contrast, DSG is just delaying the generation of static pages. Once a page is generated (upon first request), it's just static. If you update the content for the page after it's generated, you've to run the build once again to invalidate the cached page.

The problems that ISR & DSG solve are also different. DSG solves the problem of having a longer build times. This has been a problem with Gatsby for a while. More the number of pages, more the build time. And DSG is a pretty good option to solve this as you can build the logic yourself whether you want to generate a page at build time or not.

ISR, to me, seems like a superset of DSG - you can still do deferred generation of static pages, and also regenerate those pages automatically when the given time elapses. For example, if you have page with some data source that gets updated on a daily basis, you can set Next.js to regenerate the page every day. So your users will still be accessing static page from CDN & you get all the speed benefits, and at the same time you don't have to run the build process everyday.

Furthermore, pages generated by ISR are persisted across deployments (at least on Vercel) i.e. your users will see the cached version of the page even if you deploy a new version of your code. The page will only be regenerated based on revalidate option in your code. For more details, look at Vercel's documentation.

Okay, this is my understanding of these two and if you find something is wrong, please let me know on twitter. Feel free to tweet / DM if you want to talk about this in more detail or just wanna say hi :)

PS: I'm quite sure something like ISR will be coming to Gatsby in near future

DEV Community: Sriram Thiagarajan