v1.1.0: Architecture Rewrite — Simpler, Stronger, Future-Proof #140
Pinned
Alberto-Codes
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
We Rewrote the Architecture (and Deleted 85% of the Code)
When we launched v1.0.0,
EncryptedSessionServicereimplemented ADK's entire database layer from scratch — ~800 lines of raw SQL, custom schema, manual state merging. It worked, but it was fragile. Every ADK update was a potential breaking change. We were maintaining a parallel database engine just to add encryption.v1.1.0 fixes that. We rewrote
EncryptedSessionServiceas a thin wrapper around ADK's ownDatabaseSessionService. Encryption now happens transparently at the SQLAlchemy column level via anEncryptedJSONTypeDecorator. No custom SQL. No schema ownership. No reimplemented state logic.What Changed
EncryptedSessionServicenow subclassesDatabaseSessionServiceinstead ofBaseSessionService. ~800 lines of raw aiosqlite → ~130 lines of wrapper code.EncryptedJSONTypeDecorator — encrypts/decrypts at the ORM column level. ADK reads and writes normally; data hits disk encrypted.DatabaseSessionServicebehavior exactly.examples/basic_usage.pyruns a real multi-turn ADK agent with Ollama and proves encryption at rest by inspecting the raw database.What Didn't Change
create_session,get_session,list_sessions,delete_session,append_event— all the same.Why It Matters
Less code = fewer bugs. Delegating storage to ADK = resilience to upstream changes. We own only the encryption layer now — which is what this project should be.
Migration
The constructor API changed from
(db_path, backend, backend_id)to(db_url, backend). Existing v1.0.x databases are incompatible — create a fresh database when upgrading. See the migration note in the README.Try It
What's Next
Links
All reactions