What's your email stack and your use case for Mailing?

[monicakogler]

Hey y'all. As we sequence the next set of features, it'd be great to know how you're using Mailing, and email in general, in your project. For example, this comment from @mrlubos was super informative. For context, here are a few things we have in mind:

• Sharable links to templates so you can share with people on your team and your clients
• Standalone mode so Mailing is easier to use without a next/js app embedded
• Basic analytics (sends, opens, clicks, geolocation)

Tagging a few people whose feedback has already been really helpful but whose stacks we haven't heard about – @alan-francis @tobdru @ccarollo @sebasalvarado. Thanks so much!!

[mrlubos]

Hey! If I'm understanding it right, the plan for the first bullet point is to use Storybook. That's what's we use for other projects and it works great. We can view and share components and flag diff in UI tests.

[monicakogler]

Thanks for the clarifying question! No plan for how to implement yet, but the idea is to let you share public links to each of the previews – a URL for a live preview to what's local on your machine, and/or your site's latest deploy. This is a feature we've wanted in the past e.g. for design QA or for sharing customer journeys with PMs. We could just add a little share button to the header:

We heard something similar from another Mailing user: "One thing that would be really cool is if I could hook up the developer email preview into the admin part of my web app so my coworkers could access it and even trigger sending emails."

Hope that makes more sense...

[mrlubos]

For sure, thank you!

[tobdru]

Currently we "render" mails in our c# backend, with some type of custom templating mechanism implemented.
When working on emails we use mjml.io live editor to create the static html and then paste it into our templates.
For testing we then added test endpoints locally to view and send the emails (to PO, UI/UX, view it in a real mail client)
...
As you see a pretty horrible dev experience. So I was pretty excited finding this maling solution <3
For us it would be great to have a standalone version, so we could migrate our maling into a microservice with a small node backend and this package.

[mrlubos]

Have you seen https://github.com/psugihara/mailing-serverless-api?

[psugihara]

@tobdru there's also this ticket. We're excited about a standalone mode too but still trying to figure out the most useful way to ship it. LMK if something like the solution described at the top would be useful or you'd rather deploy to a serverless environment. #58

[tobdru]

Not so far, thanks. This in combination with the preview server (I personally love the preview server for the dev experience) would be kind of what our solution could look like.
I personally would rather continue to use the framework and integrate it the way i need it. How the email is sent, is then up to the user. e.g. In another project we trigger email sending via queue.

[nandorojo]

I'm building a changelog newsletter powered by a CMS, and I want our emails to match the design:

Do you guys have any suggestions on the best mail client? Something like mailchimp with good custom template support, which could possibly integrate well with our CMS?