> not as a service that allows you to send email from Javascript, but rather as a service that allows you to create a predefined set of emails via the dashboard, and then just trigger the emails from the Javascript. This is quite similar to how emails are usually sent via a proprietary server code<p>So... a bold title saying something and then an explanation explicitly saying it was not true.
I was really intrigued so I signed up.<p>Essentially, this is a service which connects to different email accounts of your choosing - Yahoo, Outlook, Gmail etc. and then sends email via those.<p>I haven't tested it all the way, but in many scenarios when emails are sent via an application, the server essentially does the same thing, except that, IMHO, it takes a bit more knowhow.<p>In this case, you set up email services under your emailjs account one time and then everything is handled via Javascript on the front end via their servers.<p>Quite nice, come to think of it.<p>Except the privacy aspect, of course!<p>When we set up it up like this on our servers, the only parties that can read it are the recipients, the service provider and us. In this case, emailjs also gets to have a look at the emails.
Congrats on the launch! There’s a strong shift of devtools from the backend to the frontend, and services are often jumping through hoops to 1) remain secure, and 2) allow client-only integration.<p>For example, Stripe offers a client-only integration with similar limitations - the product catalog must be defined within the stripe dashboard.
<a href="https://stripe.com/docs/payments/checkout/client" rel="nofollow">https://stripe.com/docs/payments/checkout/client</a><p>At <a href="https://clerk.dev" rel="nofollow">https://clerk.dev</a> (disc: founder), we do all of sign up, sign in, and user profile management from just the client. We’re able to keep it secure because we also do session/cookie management, so can tell who is signed in.<p>Emailjs has an interesting concept here. It’s definitely on-trend, though I personally wouldn’t like users being able to trigger emails to other users, which seems possible today (correct me if I’m wrong?)<p>Have you considered an option to require a signed JWT with requests, which could contain the user’s email address? That would make it so users can only trigger spam to themselves (except in cases of xss), but retain a mostly client-only experience. (Generating the jwt requires a backend, but developers may already have one available if they’re using another service like Hasura that follows a similar pattern.)
On the server side, I suppose you can use this, but it usually makes sense to use a vendor SDK directly rather than rely on and hand user data to yet another middle man that might disappear at any time. I guess bridging personal email providers is an interesting idea, but it doesn’t make sense to use a personal email account when you’re beyond the free tier of a few emails a day anyway.<p>On the client side, unless you want to authorize spam sent from <i>your account</i> to <i>any recipient</i> of an attacker’s choosing, you can only use this service to send emails to fixed recipients, so most use cases of transactional email (e.g. user authentication, notification, marketing) are out of question. Sending emails on behalf of users to yourself on a contact page is the sole use case I can think of, but that market is crowded as is with more focused and less confusing offerings. Any other use cases I missed?
What would be a use case for this?<p>E.g. sending verification emails from the client is a bit hare-brained, as I can just as easily steal the verification link from the dev console…