Why Craft A Message Publishing Service

As a developer, experimenting with new tools and looking to set up small projects after hours, I often find myself in need of a quick, efficient way to send notifications.
Whether it’s for testing an alerting feature, getting notifications from a backend only process or adding a contact us or subscribe feature to a website, having an easy-to-use notification service is very useful.
That’s why I set up a Message Publishing process, triggered by an AWS API gateway endpoint.
leveraging AWS echo system and free tier, I crafted a powerful, reusable component, capable of automating notifications across different projects and sources.

Infrastructure and Process Explained

Focused on AWS services stack, I wanted a simple, resilient, cost-effective setup for automating notifications across different projects and sources.

The process starts at an api gateway POST /sendMessage endpoint which serves as a universal notification sender.
This endpoint passes any incoming request to an SQS queue I very originally named `email_queue`.
From there, the message triggers an AWS Lambda function that parses the incoming payload and publishes the information to an SNS topic.
Currently, this topic is configured to send email alerts to my inbox, but it can be easily expanded to support multiple recipients (i.e. application subscribers) registered to the topic.

How It Works

Im not going to provide the steps to set up a lambda or create an api gateway endpoint, plenty of guides and a simple chat with AI could help you with that.
I will, however, provide some key info for each service, relevant to this process.

• AWS api gateway key points:
  • The endpoint processes JSON payloads with a simple structure (payload sample below), enabling me to integrate it quickly into various projects, without changing the endpoint.
  • The endpoint is secured with an API key, ensuring only authorized users can send messages and providing a way to disable or change an application key if I detect abuse.
  • Set the integration request to AWS SQS with a path override of: account_id/queue_name
  • Add a Mapping template of: Action=SendMessage&MessageBody=$util.urlEncode($input.body)
  • Sample json payload:

{
  "message": "Body of the message!",
  "messageAttributes": {
    "fromProcess": {
      "stringValue": "OriginDomain",
      "dataType": "String"
    },
    "to": {
      "stringValue": "toEmail@mail.com",
      "dataType": "String"
    }
  }
}
                        

This JSON format allows flexibility to pass different kinds of alerts or notifications with minimal code changes. Currently, any message sent to the SQS queue from the API gets parsed by Lambda and forwarded to SNS, which then emails the message to a subscriber.
It’s a robust chain that automates notifications without any manual intervention.

• Simple Queue Service:

  Not much to add, gets the message published from api-gw and triggers a lambda.

• Notifications Lambda:

  The function handles the message event, parses the payload and publishes to SNS.
  Its a one time setup, not going to need CI/CD or modifications, so I used python for this function.

  
  import boto3
  import json
  
  def lambda_handler(event, context):
      record = event['Records'][0]
      # Check if the body is a JSON-formatted string or plain text
      try:
          # Attempt to parse as JSON
          body_content = json.loads(record['body'])
          message = body_content.get("message", "")
          message_attributes = body_content.get("messageAttributes", {})
          from_process = message_attributes.get("fromProcess", {}).get("stringValue", "")
          to_address = message_attributes.get("to", {}).get("stringValue", "")
      except json.JSONDecodeError:
          # If it's plain text, directly assign it
          message = "message: " + record['body']
          from_process = record['messageAttributes']['fromProcess']['stringValue']
          to_address = record['messageAttributes']['to']['stringValue']
      # Map to variables
      result = {
          "message_body": message,
          "from_process": from_process,
          "to_address": to_address,
      }
      client = boto3.client('sns')
      snsArn = 'SNS-ARN-HERE'
      try:
          response = client.publish(
              TopicArn=snsArn,
              Message=message,
              Subject=from_process
          )
      except Exception as e:
          print("An error occurred:", e)
  
                            

• Simple Notification Service (SNS):

  Set up a topic and add your email as a subscriber.

Use Cases and Benefits

From alerting on background job completions to sending status updates for long-running tasks, to using it as a `contact us` or subscription list publisher,
this API endpoint has proven valuable for POCs needing quick feedback.
The setup bypasses the need for a traditional backend, saving time and resources.

• CORS-Enabled:

  Like my other API projects, this endpoint is configured for secure access, only allowing requests from specific domain names.

• Flexible and Expandable:

  While it’s currently limited to a single email subscriber, expanding this API for SMS, app notifications, or additional email recipients would be straightforward. Adding further AWS services or SNS topics makes it adaptable for evolving project needs.

Final Thoughts

The Message Publishing API is a powerful, reusable component in my toolkit, capable of automating notifications across different projects.
It’s fast, easy to set up, and ideal for lightweight applications that need dynamic notifications or alerts without the need for a full backend system.
Using SQS and Lambda as connectors, this setup highlights the flexibility of AWS services to streamline workflows and automate notifications — whether for small projects, testing, or POCs.

In the end, these tools support my workflow as a developer, allowing me to stay focused on core project goals while simplifying backend automation.