Put a running DynamoDB table on your own page

What it costs your page

A reader who scrolls past downloads about five kilobytes of compressed HTML. Those are the model’s own rows, resolved when this site was built, so they are on screen before any script runs and they survive with JavaScript switched off.

Hydrating the console adds roughly 160 KB of compressed JavaScript and CSS, which the browser caches and every embed on the page shares.

The engine is about 1.5 MB of WebAssembly, and it is not fetched until a reader asks for it. Hovering the run button starts the download, so the click that follows feels immediate. loading="lazy" on its own would defer it only until the frame neared the viewport, which on a long post is most readers.

The snippet

<script src="https://accesspatterns.dev/v1/embed.js"
        data-pattern="url-shortener"></script>

The script sizes its frame to the console as it grows and shrinks. If your platform allows frames but not third-party scripts, which a few managed documentation hosts do, paste the frame directly instead and give it a height:

<iframe src="https://accesspatterns.dev/embed/url-shortener"
        title="Live DynamoDB console: url-shortener"
        loading="lazy"
        style="width:100%;height:620px;border:0"></iframe>

Live preview

The snippet above, running here. It has not fetched the engine yet.

Options

data-patternrequired

The model to embed, by its library id. Every id is on the library index.

data-op

Which example the console opens on. Takes the example’s name or the DynamoDB operation. An unrecognised value opens the first example rather than failing.

data-index

Open on the example that reads a named secondary index, such asGSI1.

data-height

The height the frame reserves before the console reports its own, in pixels. Defaults to 620. Worth setting if you know roughly how tall the model runs.

data-title

The frame’s accessible title. Defaults to the model’s id.

Pin the version

The snippet above uses /v1/embed.js, which is pinned. The pin is a promise about how it behaves: the attributes it reads and what it does with them will not change under your page. Fixes still reach you, and a breaking change ships as a new version and leaves this one serving. There is also a floating /embed.js that always points at the latest loader, breaking changes included; take that one only if you would rather track the newest version than hold still.

Where it works

The console runs inside a frame served from accesspatterns.dev, so it brings its own Content-Security-Policy with it. That matters because WebAssembly needs 'wasm-unsafe-eval' in script-src, and a managed blog or documentation platform will not usually give you that. Running in our origin rather than yours is what lets the embed work on a host that would otherwise block it. The one thing that can still stop it is a host policy that restricts frame-src, which is your platform’s decision rather than ours.

The frame is sandboxed and cannot navigate your page or submit forms. It loads no analytics, and nothing a reader does in the console leaves their browser.

The engine is a DynamoDB-compatible implementation, not DynamoDB. Where it does not implement an operation it refuses it rather than approximating a result, and its conformance results are published per run.