Developer may forward events normalized by compensated to a downstream endpoint

zspencer commented 4 years ago

In Order to Use Compensated in Systems that are not written in Ruby As a Client Developer I would like to be able to use Compensated to forward the normalized events.

This Issue May Be Closed When

[x] There is a compensated-proxy ruby gem that can be installed
[x] The features/forwarding-proxy.feature file is created and fleshed out with the happy path (but not necessarily wired in)
[ ] The use case described has been tested by a Client Developer or a Maintainer

Scenarios


Scenario: Forwarding proxy forwards all events to Downstream Server
  Given there is a Downstream Listener running
  And I am running `compensated-proxy` with the following command line arguments:
  | argument | value |
  | --forward-to | {{ downstreamListener.compensatedEventHandlerURI }}|
  When each our Source Event Fixtures are delivered to the running compensated proxy
  Then the Downstream Listener receives each of our Standardized Event Fixtures

Context

Because compensated is currently only written in Ruby; and we are getting requests from folks who want to use it in python, node, and other languages we may want to provide a micro-service version of compensated that can listen for events from upstream payment processors; normalize their data; and forward the normalized data down.

Ideally, this would be done by executing a few simple commands; such as gem install compensated-proxy && compensated-proxy --forward-to=https://your-other-app.example.com/compensated_events or a Kubernetes/docker equivalent.

We'll probably want to rely on puma for the ruby webserver side of things; or it may be possible to package it up as a boring rack app. The Traveling Ruby package may give us what we need for packaging the full executable up. Or we can assume they can manage their own ruby and rely on executables in our gemspec.

ghost commented 4 years ago

Creating an abstraction interface and standard json spec for the interface as a first step

jalcine commented 4 years ago

It wouldn't have to be an explicitly JSON one. Something of a documented API would be enough. OpenAPI / Swagger is excellent for this (it can even reduce the amount of code needed to be written - but I have to check this)

jalcine commented 4 years ago

Eh, that actually proved to be more annoying to provide generated libraries - especially if they don't leverage language specific features. If we can produce a "spec" of the expected endpoints and responses though (still doable using something like Open API) then it'd be a living reference point.

zspencer commented 4 years ago

@jalcine - I'm curious if the Spec documented in docs/README.md meets your needs?

That is the rough sketch of what data comes out of Compensated, and while I would love for fancier automated tooling; automated tooling often comes with a steep learning curve and carry cost.

zspencer commented 4 years ago

@lanegrant - This ticket seems to be really big, so I've added the "epic" label so it doesn't feel like something that needs to be done all at once.

If you have requests for support, creating a Github Issue and tagging me with it is the best way for me to know what specific supports you would expect are missing.

I am trying to thread the needle on being supportive without inflicting help and making space for folks to take ownership without throwing them in the deep end, and I am better at that when people "pull" my attention instead of me pushing it on them (and smothering them).

One way to do that, if you are comfortable doing so, is to post the output of each work session as a pull request (or new issue or comment) so that we can "katamari damacy" towards the full implementation as a team.

zinc-collective / compensated