I'd like some opinions on module layout I have a `:fcm` module which hosts FcmService, which is a b...
u
I'd like some opinions on module layout I have a
:fcm
module which hosts FcmService, which is a basically a callback for receiving push messages. There I route the messages to my push handlers from
:push
I have 2 apps in a monorepo, both of which depend on the
:fcm
module, ie. their push handling was identital However, a new requirment came, for which I need to proxy push messages to a analytics library just for app A (app B fcm usage remains the same) So I created a FcmServiceDelegate interface, and implement it differently in each app as needed. (or rather include a different delegate module) My question is how to modularize this would you either have root level
:internal-fcm-delegate
,
:analytics-fcm-delegate
which depends on
:fcm
or, turn
:fcm
into a plain folder, and nest the two delegates + module for original code inside it, i.e.
:fcm:internal-delegate
,
:fcm:analytics-delegate
,
fcm:service
I do like nesting in general as it scales well, however I dont like that I have to create this "base" module under the folder, where the original impl will be moved to. Is there a way I could still have
:fcm
as a proper module, so it has the original FcmService class, and yet nest the
:internal-delegate, analytics-delegate
under it?
(Because let's say a new requirement comes which needs app C to be created and use huawei push .. and there is no need for delegates as there is only one impl, the module would be naturally called
:hcm
...and that's it..but thats not super symetrical with the fcm modules now..basically I'd want
:fcm
module here as well, and only add the delegate module which give app uses (semantically) something along the lines of
Copy code
-- appA
implementation :fcm
implementation :fcm:internal-delegate

-- appB
implementation :fcm
implementation :fcm:analytics-delegate

-- appC
implementation :hcm
what I'm not so keen on
Copy code
-- appA
implementation :fcm:service
implementation :fcm:internal-delegate

-- appB
implementation :fcm:service
implementation :fcm:analytics-delegate

-- appC
implementation :hcm
or maybe this? But it blows up root imo, i dont think its important to know theres multiple fcm impls when viewing root level
Copy code
-- appA
implementation :fcm
implementation :fcm-delegate-internal

-- appB
implementation :fcm
implementation :fcm-delegate-analytics

-- appC
implementation :hcm
Thoughts? What's idiomatic? I see retrofit is doing option 3 https://github.com/square/retrofit .. but it has just a few root folders, no a monorepo really
😶 2
z
This has nothing to do with kotlin
s
🤨 Common. And the 😶 reaction is not helpful or welcoming either?! @ursus From the channel description:
Copy code
This channel is for Kotlin specific Gradle questions. For general Gradle questions, join the Gradle Community Slack → <https://gradle.com/slack-invite>
Maybe you’ll get feedback https://gradle.com/slack-invite