So, I’ve figured out where I want to take this next, and the answer is “simplifying the entry requirements for using the API”.
What this means, is I’m going to extend my API fork to include basically every API call you can do, to include relationships of relationships of API data.
Working on it earlier today has lead me to conclude that there’s no properly decent tutorials out there on how to do some of this stuff, and rather than just tell you how to do something I’m going to show you how to do it with a tool that can do it and then provide you that tool.
I’ve already finished the condition checks for how this works when basing off a user and it can grab just about every reasonable thing you could want that the API docs say exist. There’s also a “just give me the basics” flag which returns fields not exposed by the existing PHP package and also, by default, includes the campaign of a membership and the tiers that member is entitled to. There’s also an override for when you just want to throw your own request string to save on runtime. With that figured out, it’s just a matter of figuring out the other API starting points and either copying and adjusting logic or incorporating them into the existing function.
Beyond that, I’m going to build a parser function that will take the API return and turn it into something more easily workable, meaning even if you request every scope for a user and that user has 100 creators they support, it can be returned in a fairly neatly organized way that cuts down the headache of figuring out who supports which creator at what amounts for how long and how often they payed and anything else I feel like tossing on the pile. It’s a bit of making an API for an API but it should significantly flatten and simplify the API returns before returning them to the application.
Oh, and it’ll still be backwards/hot-swap compatible with the existing package. I’m only adding functionality here.