How to handle dynamic schema?

I’m building a sports app that has different leagues with different settings. I want to display team names for a given league. For this, I’ll call the /league method from a 3rd-party API that returns a list of all the teams for the specified league.

The challenge: this method returns responses with slightly different schemas depending on the type of league being requested (see below screenshots). The hierarchy is the same, and team name is always a property returned regardless of the type of league, but the schema for one league may have more attributes than the schema for a another league.

As such, I’ve found that my app doesn’t work if I try to load in a league that has a different schema than the one that I initially specified with the data configurator. This is the case even if I’m leveraging a common property that is present in both leagues’ schemas (i.e. team name).

Does anyone know if there’s a way to handle these “dynamic” schemas? For example, could I just manually edit the schema to include every possible property across all league types, or will that fail as well because then some responses will return with missing properties?

Hopefully this makes sense. Here are screenshots of example schemas from the same method for two different leagues. “Name” is the property I would expect to be able to use as it’s always returned, though you can see that other properties are common to both schemas as well (“division”, “id”, “waiverSortOrder”).

Schema returned by the /league method for League 1:

Schema returned by the /league method for League 2:

Thanks for any help.

You could consider creating a separate API configuration (even though it will be the same API) for each League. That would allow you to call each League’s API and have an accurate schema.

That approach will have some dependencies on how your user interface is setup. My approach assumes some level of separation of the different types of Leagues in the User Interface.

Just a thought…it has some flaws, but might get you there :slight_smile:

Yeah appreciate the out-of-the-box thinking but unfortunately there are hundreds of possible combinations of rules across the different leagues so there’s no way to separate the API for each league. It also wouldn’t be feasible to build different UIs based on different combinations of rules.

I feel like there must be a way around this; in my day job where I work with mobile devs, they say that we can add whatever we want to the response as long as we don’t change a part of the response that they’ve already coded against. I’m curious why AppGyver is more restrictive, but that may just be a necessity to do it without custom development…

It might be worth trying to manually define your Schema for the API. Have just one Schema Property that is of the “Any type” (bottom of the list in the drop down for the “Value type” field.

In theory, that should allow any returned JSON to be stored and you can use the List and Object functions to retrieve specific keys from the JSON? I haven’t tried this yet to know, but thought I would share.

This would assume that you know which JSON keys and it might start to make for hard to manage Functions but not knowing the details I am going to assume a positive attitude and assume this will work :slight_smile:

So interestingly, after playing around with this more, it seems to potentially be completely unrelated to the schema!

It seems that when testing I need to hard refresh the Previewer after changing from League 1 to League 2, rather than relying on the auto-refresh that occurs in the Previewer after you hit the save button in Composer Pro.

Interestingly, changing from League 2 to League 1 does auto-refresh and pull in the data into the Previewer just fine, which was giving me a false sense of security, while going from League 1 to League 2 in my case requires a hard refresh, otherwise the data will blank out. So in that sense, there’s still a mystery, but one that can go unsolved for now.

Thanks for the encouragement to keep at it!

1 Like