Posts

Part of the MediaBridge series. Why Not a Normal HTTP Search S3 has no search API. To find a file, you have to list folders. A bucket with a deep directory tree could require hundreds of ListObjectsV2 calls to walk completely, each taking 100-500ms. A synchronous HTTP endpoint would either time out or make the user wait minutes for a response. The alternative is to stream results as they arrive. Start the traversal, send each matching file to the browser the moment it is found, let the user see results accumulating in real time. WebSocket is the natural transport: a single persistent connection that the server writes to continuously. ...

Part of the MediaBridge series. Why Cache S3 at All S3 ListObjectsV2 is not free. Each call costs money, takes time, and returns at most 1,000 objects per page. A bucket with 10,000 files in a single prefix requires 10 paginated S3 calls just to render one folder. Do that on every page load and you burn money, slow the UI, and hit S3 rate limits under concurrent users. Presigned URL generation is also not free. It is CPU work on the server. A folder with 50 files requires 50 presigned PUT or GET URL generations per load if nothing is cached. ...

Part of the MediaBridge series. The Problem with Silent Token Refresh A 5-minute access token is short enough to be practical for security but creates a UX problem. When a page loads and fires several API calls simultaneously, the token might expire in the middle of that burst. Suddenly all five requests get a 401 TOKEN_EXPIRED at roughly the same time. The naive fix is to retry each 401 by refreshing the token. But if five requests all hit 401 and all try to refresh, you get five simultaneous calls to /auth/refresh. Refresh tokens are single-use. The first call succeeds and rotates the token. The next four present the now-used refresh token and get REFRESH_TOKEN_USED. Those requests fail and the user gets logged out, not because their session was invalid but because the client raced itself. ...

Part of the MediaBridge series. The Design Premise Most access control systems respond to violations with a 403. You tried to access something you should not have - here is a polite rejection. Come back when you have the right permissions. MediaBridge takes a different position. Certain violation types are not mistakes. A user navigating to a URL they are not supposed to reach is an accident. A user constructing a request with a path outside their assigned root prefix is not. The system treats the latter as an active intrusion attempt and terminates the session immediately, rather than returning a 403 and letting the session continue. ...

Part of the MediaBridge series. The Upload Problem The obvious way to handle file uploads in a web app is to pipe them through the backend: browser sends the file to your server, server writes it to S3. This works. It also means every upload byte travels twice - once from the browser to your server, and again from your server to S3. Your server becomes a bottleneck, your bandwidth bill doubles, and large files tie up server connections. ...