code-corps / code-corps/code-corps-api
Suggestion: Refactor and consolidate event handlers
- Lenguaje dominante
- Elixir
- Estrellas
- 234
- Forks
- 82
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
# Problem
Right now, our connect event handlers are being called with `Stripe.Event` as their first argument, but most of the other factors in how their being called are kind of all around the place.
Some require `user_id` (a `Stripe.Account` `id`) as the second argument, some inferr it, some get is as part of the object that's being handled, etc.
The thing is, we store the `Stripe.Event` as a local record, `StripeEvent`, every time before it gets handled. The local `StripeEvent` has the following info which ought to be enough for us to handle any event:
* `object_id` - id of the object stored in the event. For platform events, this is enough to retrieve the object from the stripe API.
* `user_id` - id of the connect account associated with the event object, with `object_id`, enough to retrieve the object from stripe API in the case of a connect event
* `type` - the type of the event. enough to figure out which handler should handle it
* `endpoint` - `"platform"` or `"connect"` - enough to figure out which handler module ought to be used to handle the event.
This means that, instead of passing in the `Stripe.Event` into our handlers, we ought to be able to pass in `CodeCorps.StripeEvent` instead and not deal with the problematic code in `EventHandler.call_handler`.
We can use the opportunity to consolidate our handler modules.
* Move all handlers of platform events under `StripeService.PlatformEvents.`
* Move all handlers of connect events under `StripeService.ConnectEvents.`
* For platform events, each handler should call their respective service module with just an `id_from_stripe` for that object. Everything else can be inferred after retrieving the object from the Stripe API
* For connect events, handler should call their respective service with `id_from_stripe` and `user_id`, which should then be enough to retrieve the object from stripe and read the rest from there. This means that our event handlers will all have the identical interface within their endpoint group.
* I would also consider renaming our `XService.create` functions (those that simply fetch the record from stripe and insert it locally), to `create_from_stripe` or even `import_from_stripe`, since this is what they in fact do.
## Platform event handlers
* `customer.source.updated` - currently passes `Stripe.Event.data.object.id` into service`, which can be `StripeEvent.object_id`
* `customer.updated` - same as `customer.source.updated`
## Connect event handlers
* `account.updated` - currently passes `Stripe.Event.data.object.id` into service`, which can be `StripeEvent.object_id`. For the sake of connect events having the same interface, we should consider passing in `StripeEvent.user_id` as a second argument (the connect account id), even though it has the same value as `object_id` in this case.
* `charge.succeeded` - currently passes `Stripe.Event.data.object.id` into service`, which can be `StripeEvent.object_id`. Also passes in `user_id`, which we've explicitly merged into the stripe object. If we switch to `StripeEvent`, we can just simply pass in `StripeEvent.user_id`
* `customer.subscription.deleted` - currently passes `Stripe.Event.data.object.id` into service`, which can be `StripeEvent.object_id`. Also passes in `customer`, so we can infer the account and then fetch the record. If we pass in `StripeEvent.user_id` instead, we would not have to do all that.
* `customer.subscription.updated` - same as `customer.subscription.deleted`
* `invoice.payment.succeeded`- same as `customer.subscription.deleted`
Guía de contribución
Evaluación
Este issue todavía no se ha evaluado.