Fair point - I built Topaz, so yes, there's a conflict of interest. The argument about mock-vs-inject stands independently though: any proxy that sits between the SDK and a real endpoint would do the same thing. Topaz happens to be what I built to solve this for Azure locally.
Hey, my name's Kamil and I'm the author. I started working on Topaz, local Azure emulator, over a year ago as a prototype. After validating it in a few commercial projects I was working on, I kept developing it. It's built on a principle of going deep-first - emulating not only typical CRUD operations but also intricacies of data planes (like ACR OCI protocol emulation, soft-deleting, simulating network errors, Entra ID authentication flows and similar low-level issues).
The main idea behind starting the project was providing a single tool for Azure developers with a unified DevEx - DNS, SSL, IaC support.
Would love to hear more about what gaps you see when trying to emulate Azure services and what scenarios you'd like to cover with such a tool.
Yes it is but it's still another emulator which needs to be run separately, configured separately and managed separately. But let's keep that for another comparison :)
Thanks! I believe that the main issue was encoding/decoding behaviour for URL between Go and .NET, not the documentation itself, but it's great to hear that such feedback is still valuable to you!
Hey Edgy, thank you for your input! This is an emulator, not a real storage-like system which is more like a LocalStack for Azure, not "MiniIO for Azure" :) So while some things / patterns may look fishy or hacky, there's a tradeoff between what's considered a performance issue and what is "just doing the work". The codebase is not vibecoded, the project is created by myself for the last 1 year with some AI based assistance. But I will definitely look into some of the red flags you mentioned!