Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Faktory.Pool #102

Merged
merged 4 commits into from
Jun 7, 2024
Merged

Add Faktory.Pool #102

merged 4 commits into from
Jun 7, 2024

Conversation

pbrisbin
Copy link
Member

@pbrisbin pbrisbin commented Jun 7, 2024

This implements connection pooling by adding HasFaktoryPool which can
be used to acquire a Producer, which is just a Client, which is just
a Connection.

I chose the name FaktoryPool (instead of FaktoryProducerPool) for
two reasons, one conceptual and one practical:

  • Conceptual: I think the Producer wrapper over Client is
    unnecessary. It adds nothing and a Producer could just as easily be
    used for any communication with Faktory, to produce, consume, batch,
    track, etc. So I consider this a "pool for Faktory" and no
    specifically "for Faktory producers". (Same reason we call it
    SqlPool and not SqlInserterPool or SqlQuerierPool.)
  • Practical: we have a FaktoryProducerPool in freckle-app, that this
    is a generalization and upstreaming of. Changing the name along the
    way makes the errors clearer and more easy to deal with when
    converting downstream applications.

I have branch migrating backend from freckle-app to this and it's quite nice. There
are a few differences from freckle-app in my implementation here that led to that:

  • Providing 1-for-1 pool versions of perform and buildJob make conversion simpler
  • My version of takeProducer made the necessary-evil of using the pool in ConduitT much nicer

pbrisbin added 2 commits June 7, 2024 09:26
This implements connection pooling by adding `HasFaktoryPool` which can
be used to acquire a `Producer`, which is just a `Client`, which is just
a `Connection`.

I chose the name `FaktoryPool` (instead of `FaktoryProducerPool`) for
two reasons, one conceptual and one practical:

- Conceptual: I think the `Producer` wrapper over `Client` is
  unnecessary. It adds nothing and a `Producer` could just as easily be
  used for any communication with Faktory, to produce, consume, batch,
  track, etc. So I consider this a "pool for Faktory" and no
  specifically "for Faktory _producers_". (Same reason we call it
  `SqlPool` and not `SqlInserterPool` or `SqlQuerierPool`.)
- Practical: we have a `FaktoryProducerPool` in `freckle-app`, that this
  is a generalization and upstreaming of. Changing the name along the
  way makes the errors clearer and more easy to deal with when
  converting downstream applications.
@pbrisbin pbrisbin changed the title pb/pool Add Faktory.Pool Jun 7, 2024
@pbrisbin pbrisbin marked this pull request as ready for review June 7, 2024 13:42
@pbrisbin pbrisbin requested a review from z0isch June 7, 2024 13:42
library/Faktory/Pool.hs Show resolved Hide resolved
@pbrisbin pbrisbin merged commit 480da9d into main Jun 7, 2024
9 checks passed
@pbrisbin pbrisbin deleted the pb/pool branch June 7, 2024 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants