search

beam-community / stripity-stripe

An Elixir Library for Stripe
Other
965 stars 344 forks source link

fix: operation name #843

Closed yordis closed 1 week ago

yordis commented 2 months ago

I tried my best to figure out how to fix the breaking changes based on the assumptions made around the x-stripeOperations extension. https://github.com/beam-community/stripity-stripe/pull/829.

However, I firmly believe we should leverage the operationId since it was created for this reason. Inventing the wheel here creates more problems. Such a unique extension from Stripe helps less than they believe it does.

It is even less valuable in a language like Elixir, where the most significant information is the function, not the module. Modules are merely a grouping of functions. Repeating information in the function name is probably a much better practice than relying on the module to give so much context (granted, a balance is a given).

yordis commented 2 months ago

@beam-community/team @maartenvanvliet I need your strong pushback here. Otherwise, I will be responsible for breaking the change and adequately documenting the migration.

In practice, it should be a "search" and replaced with the appropriate function, which will be clearer.

doomspork commented 1 month ago

@yordis sorry but I'm not sure I follow this PR, the one referenced, and the change being made here. Can you help me and the others on @beam-community/team better understand the why? Should there be test coverage here if this is fixing something?

yordis commented 1 month ago

@doomspork have you read https://github.com/beam-community/stripity-stripe/pull/829

The generator as of today, mades assumptions about the operations that weren't inline with how Stripe generate their SDKs (which I somewhat disagree with stripe on that one since they created proprietary extensions).

The existing SDK can not longer generate the endpoints based on the latest version because it creates duplicate function definitions.

This PR is just to agree on breaking change, and unblock being able to generate latest SDK version. Relying less on whatever internal stripe extensions idea they have. Which btw, I reached out multiple times to then and dropped me in the water, I was seeking understanding in terms of how they were generating their official SDKs so I can mirror it, but I got no support.

Reasons why I rather concentrate on OpenAPI SDK (which I am familiar and hopefully as a community we figure out how to offer an extremely well maintained one).

Check the PR I linked, I just decided to backtrack out of it, chasing the internal proprietary Stripe extension is heavy on me, I am trying to make a decision that empower us, and persoanlly, unblock me. I gave enough time to the topic and I am a bit burned out by it.

If you have any Stripe connection or insights that could help me here, I much appreciate it.

yordis commented 1 week ago

I decided I am not gonna break change, I will add an indirection to map existing operation id to a function name; this will kick down the road breaking changes