Api bad design

Retired Boards Appdev Subscriptions
1

I started playing with subscription related apis provided by Shopify and i see critical bad design. SellingPlanGroup schema is unclear and badly documented that ends up with situation where different apps are store data in inconsistent way.

Assume you are building the app that takes product, reads all connected sellingPlans and popups this product with list of all available subscriptions. Of course you want to have mechanism that is conssitent with all apps, so if app renders ‘Subscribe and save’ as a title, and ‘Delivery every’ as frequency selector, your popup should you the same. Where to look for those labels? Well who knows… api is designed that way it is not documented and forced, so different apps uses different way.

Example :

a) data of sellingPlanGroup created by recharge

"node": { "appId": null, "name": "Ananas", "options": [ "15 Day(s),30 Day(s)" ], "sellingPlans": { "edges": [ { "node": { "name": "Delivery every 15 Days", "options": [ "15 Day(s)" ] } }, { "node": { "name": "Delivery every 30 Days", "options": [ "30 Day(s)" ] } } ] }

name is inherited from product, options is an array that contains one ! comma separated string. Title rendered by app (“Subscribe and save”) is not stored udner sellingPlanGroup document, probably comes from app itself. Hard to say.

b) created by Ongoing Subscription app

`{
“node”: {
“appId”: “repeat-kit-app-extension”,
“name”: “Ongoing subscription name”,
“options”: [

“Delivery every…”
],
“sellingPlans”: {
“edges”: [
{
“node”: {
“name”: “Ongoing subscription name”,
“options”: [
“Option 1: Delivery Every 1 Month(s) - Paid Every 1 Month(s)"”
]
}
}
]
}

}

}

`

Most common way, used by 90% of apps I tested option contains only one element ( why it is an array) that is frequency selector label. Name is the selling plan name that is then displayed on store front. I know it is up to app to render widget on store front but cmon , provide some unification and standards.

Anyways i thought it is not end of the world, i thought I could write parser and parse data comming from different apps and make sure i have data formatted properly. I was sure that appId is really id. But it is not! It is not required, it is up to the api client to set the appId so there is no way to know who is the creator of sellingPlanGroup, many apps left it even blank. Look above appId in case of recharge is null.

2

Hello greg12,

The documentation for the SellingPlanGroup and SellingPlan Graphql objects provide some answers to your questions.

The appId is indeed optional on the SellingPlanGroup as indicated on the docs (using the Graphql notation), and up to the app developer to provide, if they want to make it available to Liquid.

You can see the options on the selling plan group a little like a label, and the one in the selling plan like the value (order should be kept).

The reason why it is not structured is because many app developers can choose to add whatever they want, and cadence may or may not be a part of the info they want to surface.

I will ask around if there are improvements that can be done in our docs for the options on the selling plans, thanks for the suggestion.

I hope that helps.

3

I dont mean to be rude, but i didnt say appId works not as was documented. I said it is bad api design, anti pattern. I described in details why.

4

Hi greg12,

In my previous response I gave you a bit of context on both your questions:

  • the way options work in selling plan and selling plan groups

  • the reason why the AppId is behaving the way it does.

I understand the way the API is currently designed may not suit your use case.

There is no plan currently to change how the AppId field is behaving.

Thanks!

5

I just shared with other developers what is going on here, one could think it behaves structured way. It doesnt.

Even if I would ask ‘why appId behaves like this’ what you provided is not an answer to this question. You suggested that i have some special case that cant be covered, and it is by design. I have pretty common case, where i want to use available data. It could be simply avoided by making appId require and unique per app. But it doesn’t. This freedom a) gives nothing, b) produces problems in some cases, as i described.

Thank you for making us sure Shopify is not going to repair this.

best,

G.

6

I appreciate your frustration at how this is designed. Our team was intentional in giving the selling plan author flexibility for how to use this optional field. I appreciate it does not aid you in the app you would like to build.

An app may want use a variety of values in appId to tie across selling plan groupings on the product display page.