...
The first solution is to add a mapper just to the frontend to obtain the types of cards accepted for payment and directly obtain these values that will be displayed. Changing accepted cards is very infrequently, we would not have problems with changes in these fields.
✅ Pros:
Quick implementation
Cons:
Changes to information require engineering time
Solution #2 - Get accepted cards in the launch-darkly
In this solution we would have the flexibility of a more dynamic change, but we would be linking the feature to the feature flag and adding another flag to the system.
✅ Pros:
Quick implementation
Ease of changing card type values
Cons:
The number of feature flags (eg: dev plk es, dev plk pt, dev bk es, dev bk pt and etc) created for each region/environment is high due to the way the frontend FD is created.
Solution #3 - Get accepted cards in the backend with launch-darkly
...
Expand | ||
---|---|---|
| ||
|
✅ Pros:
Ease of changing card type values
Cons:
More robust implementation
Creating new endpoints
Solution #3.2 - Frontend integrate endpoint directly to graphql/fulfillment
...
Expand | ||
---|---|---|
| ||
|
✅ Pros:
Ease of changing card type values
Cons:
More robust implementation
Creating new endpoints
Solution #3.3 - Frontend integrate endpoint directly to userAccounts endpoint
...
Expand | ||
---|---|---|
| ||
|
✅ Pros:
Ease of changing card type values
Endpoint already implemented
Cons:
Added another request to userAccounts to obtain feature flag data
✅ Proposed Solution
Solution #2 - Get accepted cards in the launch-darkly
...