Yep! It’s perfect for microservices, orchestration APIs, BFF APIs, etc. It’s designed as a way to augment your favorite ORMs and HTTP clients rather than replace the whole stack.
I think the disconnect we’re having here is what you’re looking for in a framework. Mosaic doesn’t help you accept incoming traffic or make your upstream requests, it just helps manage your business logic in between.
For an application with just one upstream data source, you’re right it probably doesn’t make sense to use this framework. My background is in fintech where we deal with dozens of data sources at the same time in large orchestration APIs and that’s where this system shines. It allows you to run all of these upstream requests in parallel without writing any coroutine boilerplate and access their results anywhere in your logic without needing to pass around the various responses.
As for how it works, it really isn’t doing anything too surprising. There is no actual graph being created, the behavior just acts like one exists. Mosaic inserts stubs into short-lived caches which causes tiles to wait on eachother at runtime. Once the tile is completed, the stub receives the result and all the waiting tiles get it too. It eagerly runs every piece of logic you give it while guaranteeing that it will never run twice for a request.
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.