Mailgun's integration about epic-stack

[kentcdodds]

I'm currently re-evaluating Mailgun as they changed their pricing to limit the free tier to only one month. So let's hold off on making any changes for now. Thanks!

[kentcdodds]

Thanks! I'm actually considering https://resend.com/ as they just added 3k emails a month to their free tier. They also make it easy to generate the email via React which is fantastic. We could probably set that up ourselves though, so I'm still evaluating.

[kentcdodds]

I worked on integrating resend on Friday and I liked it. The react-email issue with ESM has now been fixed so that should be much better now.

[kentcdodds]

Thanks for investigating this @dawnmist. I've left a comment: resend/react-email#513 (comment)

[kentcdodds]

The server startup hanging issue was probably related to this: #183

That should now display a useful error message.

[kentcdodds]

I've officially migrated the Epic Stack to Resend. I'm still working on doing more with getting React Email set up before I officially announce it, but I thought people would appreciate a single commit that has all the necessary changes for the resend migration (along with the decision document): 400dc04

I'm closing this now that it's no longer relevant. Stay tuned for the announcement that includes React Email stuff.

[kentcdodds]

Remind setting MAILGUN_DOMAIN and MAILGUN_SENDING_KEY in .env. This is useful for local production.

The .env.example is auto copied to .env when the init script is run. I'm not sure what more we can do about that.

These others are interesting. Perhaps we need a MAILGUN_API_ENDPOINT environment variable?

[andrecasal]

The .env.example is auto copied to .env when the init script is run. I'm not sure what more we can do about that.

This is just a documentation issue. Having a reminder to set both of those in the README.md file as part of the Mailgun's integration process would prevent the first local production run to fail when sending emails (and subsequent investigation).

These others are interesting. Perhaps we need a MAILGUN_API_ENDPOINT environment variable?

That'd be useful. Having api.mailgun.net by default and //api.eu.mailgun.net commented out.

[andrecasal]

Would you like me to create a PR for this?

[xHomu]

Mailtrap looks interesting. They even have a free testing tier!
https://mailtrap.io/pricing/

[jessethomson]

SendGrid by Twilio is a nice option with a Free Tier of "100 emails/day forever"

https://sendgrid.com/pricing

(Not trying to turn this into an ad thread, but I did a fairly comprehensive assessment of email vendors a year ago, and SendGrid was who I landed on)

[kentcdodds]

I'm looking at https://postmarkapp.com/pricing as well. They offer everything free for the first 100 emails as well. Definitely more expensive, but deliverability is key and the fact they have different infrastructure for transactional and bulk email is a nice plus.

Luckily, switching email providers is pretty straightforward.

[andrecasal]

This makes me think maybe we should abstract the .env vars into something like MAIL_SERVICE_DOMAIN , MAIL_SERVICE_SENDING_KEY, and MAIL_SERVICE_API_ENDPOINT so we avoid having to change them in the code as well. Sometimes, we only need to change the .env vars and DNS settings.

If email service providers changing their free tiers is expected, we could add documentation with copy+pastable code to connect to all of them and the up-to-date recommendation.

[kentcdodds]

We want things to be adaptable, but not at the expense of keeping things simple for the built-in and default use. I believe each of these providers have their own API and trying to make a single one that wraps them all would lead to some really over-complicated code I fear.

[adamochayon]

I'm currently re-evaluating Mailgun as they changed their pricing to limit the free tier to only one month. So let's hold off on making any changes for now. Thanks!

@kentcdodds It is worth noting that mailgun still has the "flex" tier - It's a bit shady since it doesn't appear in their pricing, but you can still sign up without adding payment info (and therefore won't need to pay after first month):

I just confirmed it still gives you 5,000 free emails as expected:

[kentcdodds]

Thanks for doing that digging @adamochayon.

Looks like it's "limited to sandbox domains" in the screenshot. Can you confirm you get full functionality within the free tier?

[dawnmist]

It also says that accounts without a Credit Card are limited to "5 authorized recipients" in the text on the right - which can work for development/testing but is an unusable restriction for a production site.

I'm watching the epic stack closely - most of it is exactly what I'm in the process of figuring out for a project I'm working on (though I keep seeming to be about a week or two ahead of when various decisions like Sentry & email sending & logging get made).

I've currently gone with SendGrid for email (free for up to 100 emails per day vs Postmark's 100 emails per month). I've set it up in my app so that I have a generic simplified "mail" object that my email functions create, which is passed into a global sendEmail function with that global function then forwarding to a particular sender interface function. The sender interface function can then adapt the generic mail to its own format if required (e.g. map email address/display name to the specific interface's objects, or adding tracking settings/etc), and I can swap out to another sender just by creating a new sender interface pointing the global sendEmail function to use that new interface.

[onemen]

@kentcdodds

It appear that any mailing service you choose, sooner or later, will change it free tier.

maybe you should implement each of the mailing services listed here and try to find a way for users to swap it easily.

email.server.ts and maybe tests/mocks/index.ts can be generic and call controller/driver for the specific mailing service.

it can be similar for the way prisma let you choose provider = "sqlite".
user can set 'mailing-provider = "mailgun"'

if in the future you add a driver to 'resend' user can change 'mailing-provider = "resend"

[kentcdodds]

We could do as @dawnmist has suggested they're doing. And maybe we will one day, but I want to avoid overcomplicating the codebase to support multiple providers when people will only be using one when they use the Epic Stack. Most providers have similar APIs. Where things get different is if you start using their proprietary features like templates. I think I'd rather have something put together for an established way to generate the email template using React components via react.email and then people can switch out the provider easily, but we won't need to have "adapters" because pretty much every one of them has their own library on npm that allows you to create a client and send an email with html/text.

[dawnmist]

I hadn't realised when you first mentioned it that react.email could be used to send emails server-side. I'd been thinking 'react' === 'client-side emails', and I'd needed to be creating/sending them server-side.

From what I can see, using react.email gives that nice generic email interface I wanted that is provider-agnostic, so it looks like a great choice. It has explicit plugins for multiple providers, allowing the end developer to choose what they want to use easily. It also means that you don't have to manually write both the text & html portions separately, and risk those getting out of sync with each other which is another nice benefit. Using react to create the email appearance and then rendering it server-side to the text/html versions is very appealing so I think I'm going to migrate what I have (only implemented 2 emails so far, so it's not going to be a huge migration), and having the development environment to preview the emails is a really nice dev experience bonus.

---

Edit: I've taken a look at react-email - most of what I had already implemented is still relevant because the template is mostly for defining the rendering of html & text. Two issues with react-email that I have tripped over are:

• it doesn't read/use the alias paths from our tsconfig.json file (at least, not when rendering in the dev server), so all previews in the dev server generate compile errors due to not being able to find the imported files if alias imports are used, and
• all inputs to the email template need to be able to be undefined with default values provided for each prop in order for those templates to be rendered in the react.email dev server.

The first issue is a major nuisance - you cannot import any file that uses an alias import (i.e. ~/components/MyComponent/index.tsx type imports). While you can import those files by using relative paths, any imported file also needs to be using only modules or relative paths. This is a real nuisance because it limits how much of the rendering logic can be done inside the email template file and how much needs to be pre-calculated and passed as props to the email template instead. An example where I was blocked is looking up a magic link/code for login - instead of being able to pass in only the email address and then calling the function to generate the magic link + otp code to embed in the email, I've had to pass the link and code into the template as precalculated props in addition to passing in the email address. Given I already had a function wrapping the email that was doing the calculations, I can continue using that with the template doing nothing beyond providing the components to render, but it is a limitation that will need to be documented.

The second issue is easily able to be worked around by exporting the template as a function that requires the inputs for my server to use, then exporting a default wrapper around the template that allows undefined for all of the props and sets values for the react.email previews to use. That way I'm not getting accidental development test defaults being used incorrectly in production emails, and I can use the template function export instead of the template default export in my server so that typescript can enforce that the function rendering the email templates is providing the required data properly.

[dawnmist]

Update number 2: I'm running into issues with react-email breaking the remix server build - it results in the error reported at: resend/react-email#513

I'm going to create a repro using the epic stack that I can attach to the existing bug report to see if there is anything that can be done about the issue. I think it's related to using esm imports in the server - the app itself compiles, but it doesn't work when the server tries to do the remix build.

[kentcdodds]

@dawnmist, I'm trying to reproduce your issue and I'm unable to:

~/Desktop 🦚
$ git clone https://github.com/dawnmist/react-email-issue-513.git
cd react-email-issue-513
npm install
npm run build
Cloning into 'react-email-issue-513'...
remote: Enumerating objects: 244, done.
remote: Counting objects: 100% (244/244), done.
remote: Compressing objects: 100% (226/226), done.
remote: Total 244 (delta 10), reused 244 (delta 10), pack-reused 0
Receiving objects: 100% (244/244), 3.36 MiB | 1.23 MiB/s, done.
Resolving deltas: 100% (10/10), done.
npm WARN deprecated @npmcli/[email protected]: This functionality has been moved to @npmcli/fs

> postinstall
> patch-package --patch-dir ./other/patches

patch-package 7.0.0
Applying patches...
@remix-run/[email protected] ✔

added 1578 packages in 31s

> build
> run-s build:*


> build:remix
> remix build --sourcemap

Building Remix app in production mode...

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
You have enabled source maps in production. This will make your server-side code visible to the public and is highly discouraged! If you insist, please ensure you are using environment variables for secrets and not hard-coding them into your source!
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

Built in 1.6s

> build:server
> tsx ./other/build-server.ts


building...

  server-build/index.js  4.6kb

⚡ Done in 5ms

It seems to build just fine for me. Though, when trying to start the dev server it just hangs and never actually starts the server:

$ npm run dev

> dev
> remix dev -c "node ./server/dev-server.js" --no-restart

💿 Building...
💿 Built in 2s
Waiting for app server (70e5f163)
> node ./server/dev-server.js
Remix dev server ready
Debugger listening on ws://127.0.0.1:9229/e77bfaca-24a6-4e6f-a5b8-e587b3ad1b5d
For help, see: https://nodejs.org/en/docs/inspector
🔶 Mock server installed

I'm not sure what to make of that. I even tried removing references to react.email and got the same result. Can you demonstrate what changes you made to the base template?

[dawnmist]

@kentcdodds - sorry, I knew I should have done the changes as a base/untouched template followed by the changes in a separate commit, but by the time I thought of that I'd already made the changes and couldn't quickly get back to the clean template state.

I've redone the steps tonight and uploaded the resulting comparison between a freshly generated epic stack project (main branch) and the steps needed to implement a single email being rendered by react-email (react-email branch). The resulting PR showing the differences between the two branches is at: dawnmist/react-email-issue-513b#1

In terms of building - running npm run build works, but using the built application does not. Running npm run start:mocks hangs, and on testing with logging previously (logs not included in the example repo) it is hanging at the point where it is trying to import the remix build from '../build/index.js'. That's also where the dev server is hanging when running npm run dev.

It's only when running npm run start that the error message showing that the server is having trouble finding the react-email component imports becomes visible. In the other two run states (dev & start:mocks), it simply hangs with no feedback as to why it was hanging.

[andrecasal]

Thanks! I'm actually considering resend.com as they just added 3k emails a month to their free tier. They also make it easy to generate the email via React which is fantastic. We could probably set that up ourselves though, so I'm still evaluating.

I'm really enjoying resend 👌