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: https://github.com/Nick-Abbott/Mosaic Maven Central: org.buildmosaic:mosaic-core:0.2.0
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.
Does anyone know of a similar package in rust? My kotlin is a bit lacking to understand everything here.
From the docs, it looks like it's building a graph to retrieve data, though the comparison it gives contrasts it to doing many small individual queries and passing them to other methods to get evaluated.
I find in the apps I'm working on, either services will build complex queries themselves, or they need to make multiple queries due to data needing transformations between queries that aren't simple to facilitate in the database itself (these services also tend to avoid code in the database, which I'm mixed on).
In the "Deep Composition" section it has a comment in the code `// These three tiles run in parallel`. Does that mean that the way of composition is through pulling in multiple different pieces of data then joining at the application layer?
I'm coming from a very much sql mindset and trying to understand the intended mechanism for data retrieval here. It kind of reminds me of how ad-hoc LINQ queries use Expression trees to resolve sql queries, but not exactly the same.
Or is the thought more that this would be used when you have many disparate data stores (micro services, databases, caches, etc) and doesn't make sense for a monolithic single-database application)?
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.
ImPleadThe5th•4mo ago
Can anyone remind me. There's some .Net library that works similarly right?