mailing render server API; production mode

Context

A few users have asked for a method of running mailing as a standalone process with an HTTP API. They’d like to use it from backends that don’t have access to react or can’t consume nodejs packages. The new API would have one endpoint that renders a template to HTML with input props.

Thanks to @sebasalvarado, @alan-francis, and @jdotjdot for describing the use-cases in #54.

Design

Currently the mailing preview server is intended only for development. That is, it’s built without any consideration for handling many requests and running for a long time unattended. Are there memory leaks? How many TPS can it serve? Are there spots we can switch to async IO? Let’s find out.

This design adds a “production mode” for the mailing server as well as the required API (which could also be useful for development mode features like editing props from the browser).

CLI change

With NODE_ENV=production set, mailing should start the server in production mode, running efficiently and indefinitely.

HTTP API change

GET /renders/TemplateName.json?props=JSON_PROPS

return values

200

{
  html?: string,
  errors?: object[] // prop type or template compilation errors
}

404

template not found

Tasks:

• cli change outlined above
• add API route above
• jest tests for API route
• manually test deploying this to fly.io
• add instructions to README for setting up and deploying a standalone mailing server

[jdotjdot]

somewhere serverless

@jdotjdot do you happen to have an example of a library that you think does this well? Examples I’ve seen of this (e.g. postgraphile 💙) usually build out an example repo on one platform rather than a portable feature built into the library.

My default for a serverless deployment of mailing would be shipping a next.js app to vercel and importing a render function from mailng-core in an API route kind of like we do in the demo video. Packaging as a next app might be useful because they’re ubiquitous and easy to deploy on any platform server-full or serverless. Would an example repo doing that be helpful?

Is this for an immediate use-case you have or more speculative? Just figuring out how to prioritize effort on this use-case.

Thanks!

Sorry for the delay on this one. This wasn’t for any immediate use case, just speculative. But it is a problem I’ve had many, many times. And it seems like you’ve already taken care of doing this in a serverless way! Really exciting!

It was smart to use Next.js here, it makes a ton of sense for this type of product. Serverless out of the box, and then you can just drop-in files to get them rendered as previews. I haven’t looked at the code yet but I assume there’s some way to get MJML in there as a renderer, since it’s just React under the hood.

[jdotjdot]

Another thought on how to deploy it: I’d be pretty fine with “production mode” for this actually being a small binary or some way to package it up as a lambda or similar, since I would imagine most production calls would take the form of “send props, get back HTML”, potentially also with a validation step of some sort. I don’t necessarily need an entire server for this, I’d be fine to have this somewhere serverless.