Wasp•5w ago

SendGrid setup

Thanks for the video @Vinny (@Wasp) Did you have to setup verified domain and verified email in SendGrind for this to work?! I developed the whole thing locally while using dummy provider and now I’m trying to deploy to production but switching to SendGrid gives me a headache. Also, I notice you switched to SendGrid, but it still uses dummy locally, while for me it tries to actually use send grid on local and fails because of cors issue. What am I missing?!

22 Replies

kapa.ai•5w ago

Hi @Samir Alibabic. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the knowledge sources provided, I can offer some insights into your SendGrid setup questions: 1. Regarding domain and email verification: The knowledge sources don't specifically mention the need to set up a verified domain and email in SendGrid. However, this is generally a good practice when using SendGrid to ensure better deliverability and avoid issues. 2. Switching from Dummy to SendGrid: It's normal to use the Dummy provider during development and switch to SendGrid for production. The Wasp documentation on email providers mentions that the Dummy provider is not for production use and is meant only for development. 3. Local vs. Production setup: It seems you're experiencing an issue where SendGrid is being used locally when it shouldn't be. This is not the intended behavior. According to the Wasp documentation on email authentication, you should be able to use the Dummy provider locally and switch to SendGrid for production. To set up SendGrid for production, you need to: 1. Set the provider to SendGrid in your main.wasp file:

app Example {
  ...
  emailSender: {
    provider: SendGrid,
  }
}

app Example {
  ...
  emailSender: {
    provider: SendGrid,
  }
}

2. Get a SendGrid API key and add it to your .env.server file:

SENDGRID_API_KEY=your_api_key_here

SENDGRID_API_KEY=your_api_key_here

Wasp documentation on using SendGrid provides these steps. Regarding the CORS issue you're experiencing locally, this is not expected behavior when using SendGrid. It's possible that there might be a configuration issue in your setup. To troubleshoot: 1. Make sure your main.wasp file is correctly configured to use the Dummy provider for local development. 2. Check your environment variables to ensure SendGrid isn't being accidentally triggered in your local environment. 3. Review your CORS settings, as mentioned in this GitHub issue about CORS configuration. If the issue persists, it might be helpful to share more details about your specific setup or reach out to the Wasp community on Discord for more personalized assistance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Samir Alibabic, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Vinny (@Wasp)•5w ago

Hey Samir. Did you try out SendGrid in development mode first?

Vinny (@Wasp)•5w ago

Also, check out this article we wrote which goes into more depth on email sending: https://wasp-lang.dev/blog/2024/09/24/why-your-emails-arent-getting-delivered-and-how-to-fix-this-problem

Why Your SaaS Emails Aren’t Being Delivered and How to Fix This Iss...

If you’ve just built your SaaS web app and deployed it on a production server, you might be running into email deliverability issues. Transactional or marketing emails might not be landing in your users' inboxes. Don’t panic! This is a pretty common problem, especially for apps that run on newly registered domains.

A³Learn•4w ago

I had no idea about this blog post this is great!

Samir AlibabicOP•4w ago

Works in development. Only after deployment, the app does not send emails. I don’t even see them in SendGrid logs, meaning the request to trigger an email does not reach SendGrid. This is for signups and reset password emails. I also noticed that after deployment the date when machine was changed on fly.io does not update, only last deployed date, so I suspect it has something to do with stale docker containers. Will try to remove everything and redeploy fresh.

MEE6•4w ago

Wohooo @Samir Alibabic, you just became a Waspeteer level 2!

A³Learn•4w ago

You can actually change your local development to sendgrid, maybe then look at the logs?

Vinny (@Wasp)•4w ago

That sounds like a good idea. keep us updated. yeah good idea.

Samir AlibabicOP•4w ago

Already did. Nothing in the logs and works locally. The classic „works on my machine“ problem 🤣

A³Learn•4w ago

So locally means the messages ARE being sent via sendgrid?

Samir AlibabicOP•4w ago

Yes

A³Learn•4w ago

crazy! Hmm, your secrets are all in fly for sendgrid?

Samir AlibabicOP•4w ago

All? For SendGrid there is only API_KEY. Everything else is in main.wasp (from email, auth, etc.)

A³Learn•4w ago

Yes the SENDGRID_API_KEY (later, you'd probably do a STMP_Password SMTP_Host and so on but that's later) I think it's also very very disconcerting that you don't see anything in your logs, are you looking at your fly server logs???

Samir AlibabicOP•4w ago

After pulling my hair our for over 2 days, I've finally found what the issue was. Not sure how exactly, but cold starts at fly.io were the problem! Now I have 1 machine running all the time and it works. I have this for both server and client .toml files:

auto_stop_machines="off"
auto_start_machines="true"
min_machines_running=1

auto_stop_machines="off"
auto_start_machines="true"
min_machines_running=1

😤 I guess Wasp apps don't scale well horizontally, but it's also not a requirement for me at this stage.

matijash•4w ago

interesting - so when machine goes to sleep that would somehow mess up the access to the vars, or what? @miho any idea about this, is this something we could/should document?

miho•4w ago

This could be related, but it doesn't seem likely to me. The machine is either on or off. If you can access the server app - there is no reason for automatic scaling down to affect the turned on app. If you request goes to Fly proxy -> Fly servers -> your Firecracker VM spins up -> it loads the JS code -> it loads the env vars -> it executes the JS code that sends the email then I'm not sure this can be the reason. Could you maybe try changing the settings again to your old fly.toml and try it one more time? Just for our information to see if we are missing something 🙂

Samir AlibabicOP•4w ago

Sure. I’ll revert to how it was and share the results Just verified with different configurations. No issues this time. I'm assuming some downtime or missconfiguration at the fly.io side as temorary cause of this.

miho•4w ago

Okay, good to hear! 🙂

matijash•4w ago

btw @Samir Alibabic is your app deployed? Would be really cool to see what you built if you're up for sharing 🙂

Samir AlibabicOP•4w ago

It’s in beta. You would need a printful account / store to make any sense of it. I’ll dm the link if you want to check.

matijash•3w ago

yes please!

Gaming

Programming

SendGrid setup

Did you find this page helpful?