GraphQL Schema for T1R and ODMP
GraphQL Schema for T1R and ODMP¶
Summary¶
The goal is to arrive at a Firefly data-model that can flexibly support RECOMMENDATIONS for different music-pages by introducing the concepts of parent-child relationships. This was achieved by adding - the parentContainer field and hierarchical playParams.
The parentContainer holds the details of the parent entity, like the station information for a station-track relationship and playlist information for the playlist-track relationship.
The outer playParams on the root allow directly playing the parent, like playing a station directly.
The inner playParams are used for playing the individual recommendedContent separately. (Already present in the data model)
The parent-child pattern using parentContainer and hierarchical playParams provides a standardized, flexible way to model different recommendation scenarios across TopOneRecommender and FMPM’s ODMP.
.. gql:schema:: :optype Query query: Recommendations { recommender(id: “recommender-id”) { edges { node { _type id name itemType tags playParams { id #stationInstanceId or entityPlayableId selections #’PLAY’,’SHUFFLE’,’STATION’ } parentContainer { #The parent entity’s details … on Station { id url name playParams { id #stationKey selections } } … on Playlist { id url name playParams { id selections } } … } recommendedContent { edgeCount edges { node { … on Album { id title tracks { id } playParams { id selections } } … on Track { id title contributingArtists { edges { node { id name } } } playParams { id selections } } … on Artist { id name playParams { id selections } } … on Playlist { id title playParams { id selections } } … on PodcastShow { id title playParams { id selections } } … on PodcastEpisode { id title playParams { id selections } } } } pageInfo { hasNextPage token } } } } edgeCount pageInfo { hasNextPage token } } }
## Top One Recommender (T1R)
T1R is present in HomePage and MusicPage. It supports Album, Artist, Playlist, Station, PodcastShow, PodcastEpisode, etc as recommendations. The stations has Tracks within it and it also has 2 playableIds - stationKey and stationInstanceId.
* parentContainer added to hold station details.
* Outer playParams include stationInstanceId.
* Inner playParams have stationKey MRN.
* recommendedContent will be tracks with playParams included for each Track.
This structure allows lean-back playback of stations while still associating the tracks to their parent station correctly.
### Callout/Issue
* Cthulhu has [stationInstanceId in its response-stationMetaData](https://code.amazon.com/packages/CthulhuServiceModel/blobs/4e6af3dd48008ad83098ce7fb110606a4b4c06c0/--/model/metadataTypes.xml#L106), but its not returning stationInstanceId in its response.
## On Demand Marquee Playlist (ODMP) Multiple Play
In the below ODMP widget example, recommendations are playable Tracks. But all these tracks are associated with a ***topLevelRecommendation******.*** In this case it's a Playlist. But this parent-child association is not present. [Cthulhu Multi-item Response-Reference](https://quip-amazon.com/YTcnA9RPH98j#temp:C:UUV13b4980aa220495382774630c).
With the parentContainer and outer playParams introduced,
* parentContainer used for playlist details like title, image.
* Added outer playParams on playlist for direct playback, if required.
* Playable Track details go into the recommendedContent.
By relating tracks to playlist via parent-child pattern, supports use case of displaying and playing multiple tracks in the context of their parent playlist.
### Callout/Issue
* The FMPM team mentioned that they don’t see all the tracks presented by the backend service. Will check and fix this during data association.
## Quip Document reference
* <https://quip-amazon.com/YTcnA9RPH98j/Recommendations-Data-Model>