I've had this idea for a while of creating an smtp proxy service where you just configure your preferred email service (ses,resend,mailgun etc) and then just hit a common api with a provider id and BAM: you got mail!
Since I needed to make something radically different than what I'm doing at work, I decided to explore this a bit more and start making some "product" decisions as to what I want to make with this; here's what I'm thinking of building/have started building.
Communal parts
I know that I want Facteur to have two separate services - facteur relay and facteur form - but those two sections will definitely need to share some features and some underlying parts of the stack.
One thing I want for certain is for email delivery to be reliable (and hopefully fault-tolerant), and for this I need at the least a queue system; emails need to be queued and processed FIFO style, retried if they fail and there needs to a trail of all this so users can know if when and why their emails are not going out. For forms I'm not sure I want a queue system but I'm still inclined to say yes, even if just to reduce the load on the server(s).
Facteur Relay
Relay is the base around which I want to build the rest of Facteur: an api that allows users to create "senders" (basically credentials for different services/smtp servers) and pass some info onto them to send an email. But now comes the question; what's an email?
What makes an email?
What I mean by this question is: what fields are required when sending an email ? Obviously a sender and receiver, an object, optional attachments (a whole separate story), copies etc. But what about the content? It can be raw text, html, can have inlined attachments references (think an image, for example) and more! And that's the big thing that will take me some time to do properly, especially since I want to do some sanitization and security check before actually sending anything.
Facteur Form
This is actually the first thing I thought of when imagining Facteur; I wanted a way for devs to just plug a link as a form action and be able to get an email (think contact forms). This part should be the easiest to implement since it's a passthrough and uses the Relay underneath to actually send email. Going back to the queue stuff, here's the deal; I don't want users submitting a form to have to wait for a queue to process their request. I could probably just check the validity of the request, check whether the selected provider exists and can login correctly then queue the actual email sending and redirect the user back, which could work (I have to still test this).
Anyway, all this to say I'll have something to share on Facteur Relay soon™ :)