That&#x27;s a nice abstraction, kudos. I wish I&#x27;d read this README before I started my backend project.Does anyone know of a similar package in rust? My kotlin is a bit lacking to understand everything here.

Any framework does add overhead, and this is no exception. But Mosaic does a pretty good job of keeping things flowing. All of your API requests are running on totally separate threads with no shared memory to get blocked. The overhead is limited to a native ConcurrentHashMap lookup per tile invocation and the map instance is unique per API request, even when multiple are being handled at the same time. Shouldn’t be a concern for 99% of use cases.As for the ease of learning, please, give it a try! I think it’s very straightforward but I’m obviously a bit biased. Would welcome good feedback to incorporate into a v1 release.

Interesting! This framework tackles complex APIs with contract-first design and real integration testing - no mocking! Sounds like a strong solution for API sprawl, and the Apache 2.0 license is great. Performance and ease of learning are the key questions I&#x27;d have. Worth a look.

Looks interesting!Can anyone remind me. There&#x27;s some .Net library that works similarly right?

Backend APIs often grow into large orchestration classes full of duplicated calls and manual concurrency.I’ve been working on Mosaic, a Kotlin framework that composes responses out of small, request-scoped “tiles.” Each tile runs once per request, dependencies resolve automatically, and independent tiles execute in parallel without boilerplate.It’s still early (v0.2.0), but working today for caching, concurrency, and testability. Curious to hear feedback on the approach.GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;Nick-Abbott&#x2F;Mosaic" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Nick-Abbott&#x2F;Mosaic</a>
Maven Central: org.buildmosaic:mosaic-core:0.2.0

Show HN: Mosaic – A Kotlin framework for cleaner back end code