Have to add a database layer to my app and I'm goi...
# squarelibrariesc
Colton Idle
07/28/2023, 2:09 PMHave 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
d
Derek Ellis
07/28/2023, 2:16 PMIt 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
c
Colton Idle
07/28/2023, 2:17 PMYeah, 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.
Colton Idle
07/28/2023, 2:20 PMhaving 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.
h
hfhbd
07/28/2023, 4:45 PMIt 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.
l
leonhardt
07/28/2023, 5:34 PMI'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. 🍻