Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Resend (YC W23) – Email API for developers using React

resend.com

Post reply on HN
Print view View original

111–120 of 277 posts

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#111

Post by dazbradbury »

codegeek wrote: post #55

So I have used Sendgrid, Mandrill, SparkPost and SES in production and dabbled with Mailgun for side projects. The biggest issue I have is with Logs where other than Mandrill, no one shows the actual Body of the email in logs. For our purposes, we need that. Do you log the Email body ? If yes, I will give it a shot.

Mailgun will store the email body for 3-7 days (depending on plan/settings). I'm definitely not an advocate of mailgun as a whole, but their logs are really good in my opinion.

Are you stating you want the email body indefinitely though? Does Mandrill store this? I'm yet to fully check them out.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#112

Post by joao »

codersfocus wrote: post #6

I think if you’re targeting developers, SES is your biggest competitor. Their very cheap pay as you go pricing is more attractive than your monthly pricing. If email templates with react is your usp, I think I’ve seen libraries that offer that already.

Resend is, or at least at launch was, using SES as their email provider.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#113

Post by zenorocha »

joshmanders wrote: post #83

Please for the love of god do not decide for me where I want to be. I signed up, confirmed my email, opened the app and was browsing through it and was on settings tab when I got a phone call. During that call I had to look up something so I opened a new tab. After the call I went back to resend's UI to watch it blink and all of the sudden I'm on the dashboard again. So I tested it, I went to the settings page again,…

That's pretty bad, looks like some UI bug. We're investigating it right now.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#114

Post by satvikpendem »

joshmanders wrote: post #106
confoundcofound wrote: post #87

Earlier quoted context omitted.

Could you not find a million other ways to provide this feedback less abrasively? People like you unnecessarily exacerbate the stress of launching a new endeavor.

I'm sorry was I not asked to give feedback on a launch post? Did you not see this line: > I would love to hear your ideas, experiences, and feedback on any and all of the above.

There's a difference between giving feedback and giving feedback with tact, no need to be so harsh even if you are right.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#115

Post by tifani »

iamacyborg wrote: post #89

> Poor observability: Most tools keep you in the dark without knowing what really happened after you sent an email. Resend exposes all the events associated with your email via webhooks. I can't think of a single email platform I've used as an email marketer/crm marketer for a decade that didn't expose a full event stream for all emails.

SendGrid exposes it for like 14 days I believe. I tried like hell to get data from before that and support told me you're required to store that yourself. So not super helpful until you realize you needed it in the first place.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#116

Post by isnhp »

codersfocus wrote: post #6

I think if you’re targeting developers, SES is your biggest competitor. Their very cheap pay as you go pricing is more attractive than your monthly pricing. If email templates with react is your usp, I think I’ve seen libraries that offer that already.

I tried Resend and Custom Email feature reveals SES. I think it good when Resend build on top of SES

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#117

Post by satvikpendem »

kevsim wrote: post #80
zenorocha wrote: post #19

Earlier quoted context omitted.

We render the React components on the server side.

Meaning your server?

They use (and are makers of) https://react.email which works on client side or server side, through NodeJS. So you could spin up a NodeJS server, send your React components through and compile to HTML, then use whatever email service you want, but I believe Resend does all of this natively via their servers. I personally use react.email with Sendgrid.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#118

Post by goenning »

roflyear wrote: post #102
BowBun wrote: post #100

Earlier quoted context omitted.

Sendgrid doesn't log sent email bodies, as a simple example. Think harder!

Their webhook doesn't send the full body? I'm sure you at least get the data if not the exact data sent...

I don't think any email provider sends the body via webhook. AWS SES certainly doesn't, which I think Resend is built on

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#119

Post by [deleted] »

satvikpendem wrote: post #114
joshmanders wrote: post #106

Earlier quoted context omitted.

I'm sorry was I not asked to give feedback on a launch post? Did you not see this line: > I would love to hear your ideas, experiences, and feedback on any and all of the above.

There's a difference between giving feedback and giving feedback with tact, no need to be so harsh even if you are right.

[deleted]

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#120

Post by mbesto »

avree wrote: post #45
mbesto wrote: post #33

Earlier quoted context omitted.

Ya, but why does a transactional email service have anything to do with the front-end....I feel like I'm missing something very obvious but I can't seem to figure it out...

I don't mean this snarkily, but have you ever used a transactional email service? Literally all of them support frontend, I'd much rather use something like React than "Handlebars" (which Sendgrid requires https://docs.sendgrid.com/ui/sending-email/how-to-send-an-em... )

I've used pretty much all of them and in most cases you're sending the request via some message queue (front-end -> async to back-end -> message queue -> async returns to back-end DB), which is managed on the backend. I'm scratching my head as to why relying on the browsers threading to do seems like it offers any advantages...
Post reply on HN