Storing and retrieving prompts in DynamoDB
Introduction
During a recent family vacation, I decided to dive a bit into Go. To get hands-on experience, I chose to create a simple Lambda function for storing and retrieving prompt versions using DynamoDB. This post illustrates how to integrate several AWS services and Go packages to build a serverless API. The service allows users to create and retrieve prompts with versioning support and low latency.
In addition a simple Python package will be build to use the prompt API in other applications.
All code in available following the links above.
Architecture
The architecture consists of a AWS lambda method that is responsible to store and retrieve prompts from an AWS DynamoDB Table. The lambda is linked to an API gateway proxy resource, i.e a placeholder for a resource to be specified when the request is submitted.
The Routing between storing and retrieving prompts in handled in the Lambda method, facilitated by the aws-lambda-go-api-proxy/gin package.
Prompt Creation
The CreatePrompt function creates a new prompt (POST). Before creating is will check if the namespace/name combination already exists or not and if it would exist it will check if the version is higher than the existing version (if not, the prompt will not be saved)
Prompt Retrieval
The GetPrompt function retrieves the latest version, or if specified, a specific version of a prompt (GET).
Data model
package prompt
// Prompt represents the structure of our prompt
type Prompt struct {
Namespace string `json:"namespace,omitempty" validate:"required" binding:"required"`
Team string `json:"team,omitempty" validate:"required" binding:"required"`
Name string `json:"name" validate:"required" binding:"required"`
PromptText string `json:"text" validate:"required" binding:"required"`
InterpolationValues []string `json:"interpolation_values,omitempty"`
Description string `json:"description"`
Tags []string `json:"tags,omitempty"`
Meta struct {
Authors []string `json:"authors,omitempty" validate:"required" binding:"required"`
} `json:"meta,omitempty"`
Version string `json:"version" validate:"required" binding:"required" example:"1.0.0"`
}
Our prompt model is thoughtfully designed to capture essential details that facilitate effective organization and easy retrieval of data. This section delves into the rationale behind some of the key choices made in the model, presented in a reader-friendly manner.
Categorisation: The model is built around fields such as Namespace and Name. They are central to how prompts are organised and accessed. By requiring these fields, we ensure that every prompt can be uniquely identified and traced back to its origin, be it a specific team or a broader organizational context. This is particularly useful in environments where collaboration crosses team boundaries, and prompts are shared or modified across different groups.
Dynamic Content Handling: With the InterpolationValues, the model is flexible, allowing for dynamic content that can be customised or adjusted without altering the core prompt structure. This flexibility is ideal for applications needing context-specific adjustments. e.g. like injecting user-specific context or preferences for hyper-personalisation.
Version Control: Finally, the Version field is not merely administrative but a critical component of prompt management. It signifies the evolution of a prompt, accommodating improvements or corrections while preserving the integrity of previous versions. This approach is fundamental in environments where historical data fidelity must be maintained alongside progressive updates.
Descriptive Elements, Authorship and Accountability: Fields like Description ,Tags and Meta (e.g. Authors) help in contextualising the prompt and can enhance search and sorting within large datasets. It’s about adding layers of meaning and accessibility to the data without cluttering it. Keeping track of the authors, but e.g., also where the prompts are used, why they were created etc… help in the governance of your generative AI applications.
By building our prompt model with these considerations, we aim not only to meet the immediate functional requirements but also to ensure scalability, traceability, and flexibility in how information is managed and utilised.
DynamoDB
In our application’s DynamoDB setup, each item is uniquely identified using a primary key composed of a partition key (PK) and a sort key (SK). This structure is designed to facilitate efficient data organisation and retrieval.
Version Management
Our approach to managing item-level versions in DynamoDB is outlined as follows:
Version Formatting: Each version of an item is stored with a sort key that includes zero-padded numbers to represent its version, such as 0002.0003.0004 for version 2.3.4. This method ensures that versions are stored in a manner that maintains correct lexical order.
Latest Version: In addition to version-specific entries, each item has a sort key designated as LATEST, which points to the most current version of the item. This setup allows for quick retrieval of the newest data without scanning through all versions.
Usage
I’ve created a minimal Python client, prompto, to promptly get prompts from our API.
Wrapping up
I wanted to get some hands-on experience with Go by making a simple prompt storage and retrieval API. I’m sure I butchered the Go part of this project, but I’m quite happy with the result. Creating all of this from scratch took only one to two hours.
With all the technology involved with generative AI, I’m rather hesitant to buy solutions for prompt management, testing, version control, governance, etc. This project taught me that a lot of the value of such tools can be achieved relatively fast and cheaply. It’s very tempting to start implementing features like A/B testing, monitoring, and multi-armed bandit strategies.
Anyway this was fun.
