Skip to content
C.W.K.
Stream
Lesson 04 of 04 · published

Live Provider, Thin Client

~11 min · provider, runtime, configuration, clients

Level 0Cold Vessel
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

Live Provider, Thin Client

When pipelines are rows, an application needs a way to see current rows without becoming a second persistence owner. Reading the database directly from every CLI and UI duplicates validation, archival rules, and version semantics. Loading a static copy at startup avoids duplication but makes edits lie until the process restarts.

A provider boundary solves both problems. One component owns row validation and storage, then exposes current pipeline data through a narrow query interface. Clients ask for list, get, or resolve. They do not know table layout, and they do not cache longer than the contract permits.

Live does not mean unversioned. Every returned row carries its version and archival state, so a brief can stamp what it materialized. The provider may refresh on each request or use an explicit invalidation strategy; either way, clients can distinguish current catalog state from the frozen version attached to historical work.

A thin client still owns presentation and intent. The CLI chooses human-readable errors and command grammar. The UI chooses sorting, forms, and confirmation. Thin means it delegates persistence semantics, not that it becomes a pass-through with no product judgment.

Test Without Restart

Create a row, query it through the client, edit the row, and query again in the same process. The second result must show the new version while an older materialized brief retains its stamped version. That paired assertion proves liveness and history instead of testing only one side.

A thin client may project state, but it may not invent it. Read claims, stages, and verdicts from the live provider, then adapt them for the local surface. If the client keeps a shadow queue or guesses a transition, temporary convenience has created a forked workshop.

Code

A provider returns current rows while briefs keep snapshots·python
class Provider:
    def __init__(self):
        self.row = {"name": "oneoff", "version": 1, "review": False}
    def get(self):
        return dict(self.row)
    def edit(self, **changes):
        self.row.update(changes)
        self.row["version"] += 1

provider = Provider()
brief = provider.get()
provider.edit(review=True)
assert provider.get()["version"] == 2
assert brief == {"name": "oneoff", "version": 1, "review": False}

External links

Exercise

Write a two-assertion integration test for a live row provider: one assertion for same-process refresh and one for historical snapshot stability.
Hint
Use two objects with different lifetimes rather than trying to make one object both live and frozen.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.