Comment by agreeahmed
4 days ago
That’s a devilish engineering question. If you are truly framework agnostic you limit how much work you can do for your users, because a lot of the work happens inside of the framework. We decided we’d commit to doing the work so our customers didn’t have to.
E.g. most web apps have some endpoint that the client calls to initiate a checkout session by calling their payment processor’s server SDK.
How many times has the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?
Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.
Yeah, I've run into this many times.
If you can assume the framework someone is using, you can deliver a powerful, comprehensive integration.
If you instead try to build a generic one that anyone can use, then it's both hard for you to build it, and hard for everyone to integrate with it because it's generalized.
Exactly. If you’re too committed to framework agnosticism you end up leaving your users a bunch of last mile work that they have to do with every integration, and maintain through every pricing model change.