I am building a service responsible for sending email/sms communications. The service receives a request that contains information necessary to build an email/sms template and the recipient information of where to send it.

Example CURL request:

    curl -X POST \
  http://service.local/api/finance/payment-reminder \
  -H 'Postman-Token: ec32d436-8eef-4660-8424-600bfca6a3fb' \
  -H 'X-API-KEY: secret' \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -F method=email \
  -F name=dave \
  -F email=dave@dave.com \
  -F amount=100 \
  -F due_date=now \
  -F phone_number=8957598696

Now from here I load the relevant class, send the template via the specified method to the recipient.

From here I need to persist the information I have sent to the customer in order to be able to show consumers of the system what communications have been sent to any given customer.

Thinking about it I have two options:

  1. I can store the request data and the class path used to generate the template and rebuild it if required.

The issue with this is the template may very well be changed in the future. If this happens then my representation of the communication sent is not accurate. Also at some time in the future a template could be moved/deleted and this would cause rebuilding to be impossible.

  1. Store the entire generated output of the template file (HTML for email, text for SMS)

This doesn't feel 'clean' for me as I don't necessarily like the idea of storing HTML in a database table.

Am I overthinking the storing of HTML and in this scenario it is fine to do. Obviously there will be no need to edit the information once the content has been persisted.

  • you have outlined the pros and cons of each option. What more is there to add? – Ewan Apr 18 at 10:24
  • Where does your discomfort with storing HTML in the database come from? – Bart van Ingen Schenau Apr 18 at 10:49
  • 2
    Use whatever fulfills the requirements and does not generate additional problems to solve. Your first option would force you to version templates and keep them in storage long after you switched to a new version. The second option is just a dumb archive which means that redundant data will be stored. Not a big problem unless we talk about billions of stored records. – Hans-Martin Mosner Apr 18 at 11:02
  • @Ewan I was wondering if anyone else had alternative suggestions – Daniel Benzie Apr 18 at 11:51
  • @BartvanIngenSchenau I'm not entirely sure. It feels dirty but maybe that's just my misunderstanding. – Daniel Benzie Apr 18 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.