Module best practice Onprem vs Saas

[quick flame]

Looking for opinions on this. Long story short, I have a module that has been kicking for some time. It currently supports a software that has an OnPrem version and a Saas version. In the beginning there was parity between the two in functionality, outputs, and versioning. It seems after a few iterations, the Saas product has somewhat deviated from the onprem side.

• Most of the functionality is the same, but there are commands that only work in saas and some that only work on onprem
• The versioning in the Saas side no longer matches Onprem side
• The potential of the Saas side to deviate more is definitely there

The question:

• should I split my module into two different sets, one for OnPrem and one for Saas even though currently its roughly 80% the same?
• would end users prefer one encompassing module that has everything verse downloading what they need?
• keep what I have and run with the current model: if(env == Saas){command wont work} or vice versa?

thoughts? opinions?

[eternal loom]

In my opinion:

I would consider having a common library module, assuming there is common code they can share. Then two children. One for on-prem and one for saas.

I'm personally not a fan of on-demand command (like Azure things do) loading, or conditional command availability, or anything saying "can't do that" at runtime. It makes discovering what's possible that much harder as a consumer.

It feels like a hard split would be a lot easier to maintain going forward too.

[quick flame]

im feeling this way as well...especially with the potential of it splitting even further, i never liked putting things like "sorry doesnt work in this env" lol

but to complicate things even further, even in the saas world theres different tenant types. So i do not know how granular to get. but I do like the common library because most of the endpoints are still the same