Should we move the prices subcollection into the original product document?

[ToddKerpelman]

Feature request

• Extension name: firestore-stripe-subscriptions

Hi, Stripe Engineers! So I noticed that when we create a new subscription product with a set of pricing options in Stripe, those pricing options get added to a "prices" subcollection for the individual product. While that seems logical, it means that when you want to get a list of products and their prices, you have to query both the products collection, and then go back and query every individual prices subcollection for every product. This leads to longer load times, more complex code, and more reads charged to the developer.

So I'm wondering if it would make sense to take all of those pricing documents and simply merge them into the original product document, probably as a map field. It might look something like this:

prod_abcdefg:
   active: true
   description: "Foo"
   images: ["http://..."]
   name: "Bar"
   prices: {
    price_123: {active: true, currency: "usd", description: "...", interval: "month", // etc.}
    price_456: {active: true, currency: "usd", description: "...", interval: "week", // etc.}
    price_789: {active: true, currency: "usd", description: "...", interval: "year", // etc.}
   }
   role: "Premium"

This would mean that as a developer, you can much more easily query for a list of products and all of their prices with a single database call.

The potential drawbacks to this approach are that a) There would be no server-side filtering of prices. (That is, a client would retrieve all pricing options, and if there were inactive ones or other pricing options you wanted to keep hidden from the client, that wouldn't be possible), b) You would always retrieve all pricing options even if you didn't need or want them. (Maybe there are situations where you only want to display products and not show pricing information, so we'd be downloading some unnecessary info), c) If you had a lot of pricing options, you could run up against the 1mb / document limit (but that would be pretty unusual), and d) It's a non-backwards-compatible change.

Since I don't have enough familiarly with the Stripe user base or their typical workflows, I don't know if any of these drawbacks are legitimate concerns, but I just thought I should bring this idea up in case you hadn't considered it.

[thorsten-stripe]

Thanks, @ToddKerpelman, my thinking was that having the prices in a subcollection would make it easier to keep them in sync and allow filtering and sorting along the lines of:

db.collection('products')
    .where('active', '==', true)
    .get()
    .then(function (querySnapshot) {
      querySnapshot.forEach(async function (doc) {
        const priceSnap = await doc.ref
          .collection('prices')
          .where('active', '==', true)
          .orderBy('unit_amount')
          .get();
...

which I thought was quite neat to be able to push that to the DB rather than doing it on the client.

Also, this way we can store a reference to the price doc on the customers subscription (see https://github.com/stripe/stripe-firebase-extensions/blob/next/firestore-stripe-subscriptions/functions/src/index.ts#L287-L292). In the suggested inline price data approach, would you recommend storing the whole price data map on each subscription doc rather than a reference?

I do see benefits in both approaches, and therefore am wondering if we should just do both? That way the developer can decide which approach fits them best, and we can ensure backwards compatibility. Wdyt?

[ToddKerpelman]

Yeah, that's a good point. I think this one of those situations where the right thing to do depends a lot on what a typical user's setup is going to be like. If you think developers are more often going to have multiple products and not want to do a lot of server-side filtering, then I would go for the "embedded in the document" approach. On the other hand, if you think developers are going to have one or two products, but have lots of pricing options that will need to be filtered (like lots of currencies, perhaps), than putting them in a subcollection is probably the way to go. You know your customers better than I do, so I'll let you make the call.

Personally, I'm not sure I'd recommend doing both. That feels like it could get messy in the long run.

[thorsten-stripe]

Personally, I'm not sure I'd recommend doing both. That feels like it could get messy in the long run.

Yes, that's probably true, thanks :)

From my experience, most SaaS offerings have less than five tiers (products) and rather want to be able to filter & sort prices, so I think the current sub-collection setup serves them well 👍

I'm going to leave this issue open so users can vote / jump in with their preference.

[thorsten-stripe]

Closing this out as it looks like folks are fine with the current subcollection approach 👍