Hi everyone! Hopefully this isn't a duplicate at all, I've been out of the loop for a while. I'm working on a service that does some reading and writing of metadata to/from a database (currently Redis). I'm thinking about the data layer architecture for the service and I'm inspired by the popular data layer arch for Android apps (shown in some scant detail below) since it's what I'm primarily familiar with.
Ill find out pretty quickly if this sort of architecture is too complex for a service data layer, but before I even get started I'm just wondering if anyone has any other suggestions, knows of other popular choices, or has some reading on the matter that they recommend so they don't have to explain it here 😆
not kotlin but kotlin colored 1
10/27/2023, 7:57 PM
Why would you say is complex?
I would add a CachePolicy in each repo in your diagram and also a UseCase block.
Also this is a classic architecture to solve a very common problem in mobile which is fetching data from the network/local-storage but it won't solve all your problems when making an App.
You need to get creative most of the time.
10/28/2023, 5:05 PM
I think I can forgo the use case, since there's not really a user behind it so much as other services, but I might rethink that 🤔
As for the CachePolicy, I actually think that the LocalDataSource will end up being backed by cache (probably Redis), while the RemoteDataSource, depending on the function, will vary e.g. a Redis HASH store, another service's API, etc
10/28/2023, 6:12 PM
Nothing wrong with depending directly on the repo as soon as this is abstract and you can swap implementation between the actuals implementations and the fakes in unit tests.
Now, in regards to cache, I still believe you can save some network bandwidth by using local persistence rather than Redis. Redis won't save you from a slow network. Local device cache is often used for better UI performance and avoiding showing loaders across the App.
10/28/2023, 6:17 PM
Good points, thank you! The cache in question here is for the service itself, so it will be up to clients to do any caching client-side that they need to save network requests etc.
On the server-side, however, my thought process is that functions that require data from other services to do their work will want to have some sort of caching policy in place to avoid excessive network requests out to those other services, right?
This is how I've ended up with the initial design for the server data layer looking a lot like an client application's data layer 😄