Plugging Along on MicroPie (v0.24 Release Notes)

MicroPie is one of those projects I never sit down and plan out in a linear way. It grows the same way most of my side projects grow: I run into something that annoys me, I fix it, and MicroPie quietly gets better. No sprints, no roadmap — just gradual sanding.

The latest release, v0.24, is one of those sanding passes. Nothing earth-shattering, but definitely important if you’re using sessions.

Quick PSA Before Anything Else

• The InMemorySessionBackend is only for development.
• You should never use it in production.
• Always implement your own backend or use the example Motor/MongoDB backend in the repo.
• It’s intentionally simple, tiny, and volatile. It stores everything in RAM and assumes you’ll replace it.

Alright — now the rest of the post.

The Problem: In-Memory Sessions Didn’t Really Expire

Before this release, the in-memory session backend acted like it had expiration... but didn’t. Something I didn't really care about since ALL the sessions in RAM are wiped each time the server restarts.

It checked timestamps and refused to return expired sessions, but the expired data itself stayed in memory forever. Over time, that meant:

• Sessions accumulated
• RAM usage could creep upward
• Clearing a session (request.session.clear()) didn’t actually delete it

The Fix: Actual Session Lifecycle

v0.24 makes session behavior correct and predictable, and reinforces the idea that you shouldn’t rely on the in-memory backend beyond local testing.

1. Expired sessions now delete themselves. There’s now a tiny cleanup step during loads and saves. If a session’s older than SESSION_TIMEOUT, it gets removed. Memory stays steady instead of climbing.

2. Clearing a session really clears it. A call like: request.session.clear() now actually deletes the session data in storage (even in the dev backend).

3. Middlewares can mutate sessions reliably. Session saving now happens after after_request middlewares run, which means middleware code like request.session["last_seen"] = time.time() finally persists.

This aligns MicroPie with the behavior you’d expect from Django, Flask, FastAPI, etc.

About Production Use

Let me repeat this because it matters:

• The built-in in-memory session backend is for development only.
• Do not use it in real deployments.
• Write your own session backend using redis or something.

MicroPie intentionally leaves session storage up to you — Redis, MongoDB, PostgreSQL, SQLite, whatever fits your stack. The framework’s job is to handle the lifecycle, not to choose your persistence layer.

Why This Release Matters

Even though this change looks small from the outside, it tightens up the core session behavior across:

• HTTP requests
• WebSocket connections
• Middleware layers

These fundamentals matter. MicroPie stays minimal, but correctness matters too — especially with features that quietly underpin authentication, user state, and long-running apps.

What’s Next?

Same as always: I use MicroPie every day for real projects, so when something feels wrong, I fix it. No roadmap, no “version 1.0 hype,” just continuous improvement.

If you’re using MicroPie and run into anything odd — or if you’re building your own session backend — let me know. Every real use case makes the framework better.

← Back to posts