Have to add a database layer to my app and I'm goi...
# squarelibraries
Have to add a database layer to my app and I'm going to go with SQLDelight. I feel like it makes sense to add the database layer in its own gradle module. Does anyone have strong opinions as to whether thats a good/bad approach? Seems like it'll be good to keep all of the codegen isolated. This'll be the first time in years that ive had to have a database in my app so im not sure what the general community practice is at this point.
sqldelight 6
💯 1
It definitely wouldn't hurt to put it in a separate module. The benefits are most apparent if the rest of your project is also modularized, but either way I'd personally do it that way
👍 1
Yeah, right now its a pretty small app (3 modules) app design-system network so a database module makes sense to me. just wanted to sanity check the idea.
having the network isolated has been really fun honestly. i get a lot of pushback when i say it out loud. but i have some tests written in there that actually hit the network, get deserialized etc. but its the top test suite that catches real issues lol. arguably it should be like the backend teams job to make sure they dont break anything. but its always my test suite that saves the day for the ios and android app.
It is rather a general question unrelated to the database. I prefer multiple modules too, but enable friend paths to have better Kotlin smart cast support which does not work across Gradle modules.
I'll echo what others have said, I think putting a SQLDelight database layer in its own Gradle module is a great approach and maybe should even be a recommended general approach. We recently refactored a project to do this many times across multiple modules in the same codebase. Very happy we did it. No issues with the tooling using this approach. The biggest benefit for us is isolating the generated code from other parts of the codebase (since the visibility can't be configured). We find it also makes our codebase easier to navigate. 🍻