[FEAT]: Add the `plan` property in list subscriptions endpoint results

[Thibault2ss]

Is your feature request related to a problem? Please describe.
The Subscription entity returned from the "List Subscription" endpoint doesn't include the plan property (defining the plan overrides, if any is defined for this subscription). The only way to get that is to call the "Get Subscription" endpoint, which result does include this plan property.

As a developer, when listing all the subscriptions of a customer, that forces me to do a "List" followed by one or many "Get" (as many as there are subscriptions) in order to get the subscription details along with the potential plan overrides.

The goal is to display the actual price(s) of the subscription(s) that a given customer has (which is potentially custom and "overridden")

Not urgent, but just better dev XP

Describe the solution you'd like
Include the plan property in the results of "List Subscriptions" endpoint, as currently done in "Get Subscription".

Describe alternatives you've considered
As an alternative, we can call "List Subscriptions" followed by multiple "Get Subscription" requests, for each individual subscription.

Additional context

• 🔗 related Canny feedback

[vincent-pochet]

Hello @Thibault2ss
Thank you for this issue.
The problem here is that since a plan can have a lot of attached resources (charges, taxes, filters, minimum_commitment...) exposing the it for each subscription might have some performance implication.
That is why we are generally not exposing sub-resources in List end-points, especially for "core" resources like subscriptions.

As a work-around for your use-case, maybe we could add plan_amount_cents and plan_amount_curency attributes in the subscription object. Would it address your use case?

[Thibault2ss]

Yes I guess it would solve my use case.

Although I'm wondering if it's the ideal approach from a design perspective ? Because at some point someone may need another info from the plan in this endpoint. And at this point, this would just be flattening every plan attributes in plan_xxx attributes, and the Subscription object would start to differ from the one returned in the "Get Subscription" endpoint, which is probably less clean ?

What you mean by performance issues, it that it's gonna add additional joins to the Postgres query, or are you thinking of something else ? For the query, if the right indexes are in place, I'm not sure adding those additional joins would be too much of a hit on the query perf ? (would need to be tested though, I've only briefly looked at the DB schema)

If you're thinking about adding only those plan_amount_cents and plan_amount_curency, I assume you're planning to add a first additional join on the plans table ? If so, maybe a more consistent design would be to "progressively" add the same plan attribute shape to the subscription object. Meaning, the same plan attribute than in the "Get Subscription" endpoint, but for now only with attributes "one level deep" (not adding deeper objects like charges taxes etc... those could be added later, when implementing deeper joins). That way the consistency of shape is kept between both endpoints, and deeper-level attributes could be added progressively ?

I could be totally missing the mark here, I'm not familiar with the stack yet :)