I’m Shruthi (GitHub: Shruthii7 (Alige Shruthi)). I’ve been exploring the GSoC 2026 ideas list and would like to discuss the project “Extend the mail service with template API.”
I’ve gone through the project description and references, and I understand that:
The mail rendering service is written in Rust.
It uses MJML for proper email rendering.
It uses MessageFormat 1 for internationalization.
Currently, templates must reside inside the mail service repository.
Adding or modifying templates requires updating and redeploying the service.
I believe the main goal of this project would be to:
Allow templates to be loaded dynamically via an API.
Enable projects like MusicBrainz and ListenBrainz to maintain templates in their own repositories.
Avoid redeploying the mail service when templates are added or updated.
Improve translation resource sharing.
Before drafting a detailed proposal, I would like to clarify a few points:
Should the API support fetching templates from external repositories directly (e.g., Git-based), or would it be better to introduce an intermediate storage/cache layer?
Are there preferred constraints regarding authentication and template validation?
Should template loading be runtime-dynamic (hot reload) or version-controlled through explicit updates?
Are there existing architectural decisions from last summer’s project that I should align with?
Before i begin, I am thinking of:
Studying the current mail service architecture.
Understanding how MJML rendering and MessageFormat are integrated.
Designing a minimal template-loading API.
Implementing a validation mechanism before rendering.
Adding tests for template loading and rendering correctness.
If time permits, I’d also be interested in:
Supporting template versioning.
Improving cron-based mail workflows.
Exploring caching strategies to optimize performance.
I would really appreciate feedback on whether this direction goes with your expectations and if there are specific/starter tasks I should begin with.
Hi @Shruthii7, thank you for showing interest in this proposal.
Should the API support fetching templates from external repositories directly (e.g., Git-based), or would it be better to introduce an intermediate storage/cache layer?
I don’t think that’s necessary. The templates can be posted/registered as part of the MB/LB deployment scripts. The mail service can cache them locally (e.g., in a Docker volume) so that they’re readily available if the container is restarted.
Are there preferred constraints regarding authentication and template validation?
The mail service isn’t accessible from outside our private network, and I think it’s a good idea to keep it that way. Project admins can just use the API via SSH tunnel.
What constraints did you have in mind re: template validation?
Should template loading be runtime-dynamic (hot reload) or version-controlled through explicit updates?
The latter is what I had in mind (but it should probably be possible to forcefully update an existing version in case a hotfix is needed). Can you explain what you had in mind with “runtime-dynamic (hot reload)”?
Are there existing architectural decisions from last summer’s project that I should align with?
Not sure how to best answer this one, because I wouldn’t expect the architecture to change significantly, but @JadedBlueEyes might have a better answer.
Thank you for the detailed clarifications, which help a lot.
Regarding template validation, what I had in mind was performing checks before accepting and storing a template to avoid runtime rendering issues. For example:
Validating the MJML syntax to ensure the template can be rendered correctly.
Verifying that the MessageFormat placeholders are syntactically correct.
Optionally checking that the required variables expected by the template are properly defined.
The idea would be to prevent malformed templates from being stored in the service and causing failures during email rendering. I would also like to explore whether there are already validation steps in the current mail service that could be reused or extended.
Regarding runtime-dynamic, what I meant was a mechanism where an uploaded template could immediately replace the currently active template without explicit version management. However, I agree that a version-controlled approach is safer and more predictable in production environments. Supporting explicit template updates with versioning (and possibly allowing a forced overwrite) seems like a cleaner design.
Based on your feedback, I’ll focus on designing a system that registers templates via the API during project deployments and caches them locally by the mail service (e.g., in a Docker volume), so they remain available even after container restarts.
I’ll start exploring the current mail service implementation to better understand how templates are currently handled and where a template registration API could integrate with the existing architecture.
Please let me know if there are specific parts of the codebase you’d recommend reviewing first.