Mailer sender microservice
Tags: mail, microservices, rust
Published: 2020-10-26 15:51:06

---
title: Mailer sender microservice
published: true
description: The mail sender microservice done right.
tags: mail, microservice, rust
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/z8ggqf29p60wl10s3cmq.jpg
---

I've been working for many companies until now, banks, service companies, small startups or big startups, and sending emails was always a challenge.

## Why?

First there is the problem of output. It's pretty hard to have a mail that renders on mobile as well as in Outlook.

Then comes the implementation where the language that is used is not always the same, the architecture is different between projects or the developers don't have time to spend on the mailing feature.

It's quite easy to create a fully featured implementation in a big monolith, but the email service doesn't usually need to be scaled as much as the rest. So separating it as a microservice seems to be the right way to do it.

## What are the solutions?

As well as one doesn't reimplement a database (or more an ORM) each time it's needed, using a microservice to build, interpolate and send emails seems like the smart move.

Of course, you could go for a SaaS, pay some money to get access to lots of features that you probably don't need and be tied to their solution.

Or you could go for a fully open source solution, providing everything you need, it's probably not worth the time to reimplement everything. And that's where [Catapulte](https://github.com/jdrouet/catapulte) comes into play.

## What is Catapulte?

[Catapulte](https://github.com/jdrouet/catapulte) is a micro-service, implemented in Rust, and built on top of [MRML](https://github.com/jdrouet/mrml), the Rust implementation of the nice [MJML](https://mjml.io/) library.

It comes with the possibility of declaring templates, using variables and interpolating them before sending the email.

## Why should you use Catapulte?

Mainly because it makes it easier to build an email template, bundle it and push it to production. And if it's not easy enough, it's possible to couple it with [Jolimail](https://github.com/jdrouet/jolimail) to allow anyone to edit your email templates from their browser and have a dynamic preview.

The Second advantage is that it doesn't use much RAM (3Mo on the [demo instance](https://jolimail.io)) and is really low in CPU consumption. It's mainly distributed through a lightweight [docker image](https://hub.docker.com/r/jdrouet/catapulte) that allows you to run it almost everywhere (a laptop, an old computer, a server, a Raspberry PI, in the cloud, ...). And because it's a layer of abstraction in front of the SMTP server, it offers the possibility to start multiple instances with different SMTP server and load balance between them.

To finish up, it's open source, you don't have to maintain it (although [you're welcome to contribute](https://github.com/jdrouet/catapulte)), so it costs almost nothing.

## How can you use Catapulte?

If you want to try it, there is an [demo instance of the Jolimail suite](https://jolimail.io/demo) available.

In order to use it locally, it's also pretty straightforward, your will need to have Docker installed.

```bash
docker run -d \
  --name catapulte \
  -e SMTP_HOSTNAME=localhost \
  -e SMTP_PORT=25 \
  -e SMTP_USERNAME=optional \
  -e SMTP_PASSWORD=optional \
  -e TEMPLATE_PROVIDER=local \
  -e TEMPLATE_ROOT=/templates \
  -p 3000:3000 \
  -v /path/to/your/templates:/templates:ro \
  jdrouet/catapulte:canary
```

And voila, it's ready to send emails using curl.

```bash
curl -X POST -v \
  -H "Content-Type: application/json" \
  --data '{"from":"alice@example.com","to":"bob@example.com","params":{"some":"data"}}' \
  http://localhost:3000/templates/the-name-of-your-template
```

## Conclusion

Sending emails properly is more time consuming than complicated to implement. It's now your choice if you want to reinvent the wheel or to use an open source solution that comes with many advantages. Spending time on your business features is probably more important.