Library structure

Hi guys. I am currently trying to decide between two approaches to a library I am about to continue working on. It’s aim is to be a payment gateway with a common interface into multiple payment providers.

My choice is whether to have all payment provider’s implementations within the same library (repo) or to split them out so a user only has to pull in the libs they actually need instead of getting everything. I see the first option making development and releases eaiser being all in one place with the downside of anyone who uses the lib having to download and compile the whole thing, including providers they probably aren’t using. The second option solves that issue and makes it clearer what a project actually depends on as well as having less third party code. However keeping all of the provider implementations in sync will become difficult if the common interface regularly changes.

I am leaning towards splitting it all out but I wondered what other people’s thoughts are on this?

1 Like

Can you go with option one and split out if needed later?

I personally think all in one would be fine - if that makes life easier for you and means a better chance of you staying interested in it :slight_smile:

I am having to make the same decision for a project of mine. I chose to keep everything together in one repo. However it would still be possible to eventually make one repo the source of multiple hex packages.

1 Like

Keeping them together will at least make the initial development a whole lot easier.
There is nothing stopping you from splitting it at a later time, once you know exactly how the different parts communicate.

So I’d go with option one for now :slight_smile: .

1 Like

Those are some very good points and I will follow those suggestions with the aim to review once there are a few payment providers implemented. Now just to find some hours in the week and some contributers to get the things rolling faster :smile:

Thanks all for your input.

1 Like