Generic connection pool - merge projects?

[j8r]

I was looking for a generic pool for HTTP::Client connections, that are actually created for each call to my project’s endpoints.

I have first looked to https://github.com/ysbaddaden/pool. It looks good, but they are missing features like a pool size that can grow to max size to meet the demand.

Then @Blacksmoke16 point me to https://github.com/crystal-lang/crystal-db/blob/master/src/db/pool.cr, which is mostly what I was seeking. The implementation looks great by being generic. One issue though: this generic pool is inside the https://github.com/crystal-lang/crystal-db shard, which is [a] “Common db api for crystal”; obviously not what I am doing, I don’t want to have a whole set of modules to just use the Pool object.

Several suggestions:

• Could this pool be extracted from the crystal-db shard, in order to use it for non-db related cases?
• An option to do so, why not adding the additional features that are lacking to https://github.com/ysbaddaden/pool to it?
• Finally, https://github.com/ysbaddaden/pool could be used by https://github.com/crystal-lang/crystal-db - the loop is closed.

What the authors think? (@bcardiff and @ysbaddaden )

[bcardiff]

@j8r

Could this pool be extracted from the crystal-db shard, in order to use it for non-db related cases?

See Extract ConnectionPool to its own shard? · Issue #122 · crystal-lang/crystal-db · GitHub

@j8r

Finally, GitHub - ysbaddaden/pool: Generic (connection) pools for Crystal could be used by GitHub - crystal-lang/crystal-db: Common db api for crystal - the loop is closed.

We have the policy to try to avoid external Crystal dependencies that are not within crystal-lang organization. If the crystal-db pool evolves enough to be extracted that will be a different story.

crystal-db pool is implemented with db use case in mind. I didn’t want to resolve the generic pool first.

[j8r]

Thanks @bcardiff, I didn’t see this issue.