apollographql / spotify-showcase Goto Github PK

Because this is an full running app that we expect people to try running themselves, it would do us well to ensure PRs don't completely break the app. We should add some basic CI that runs when a PR is opened to ensure some basic requirements are met:

• The CLA has been accepted
• ESLint rules pass
• Tests pass

If you used the React + Apollo Spotify Showcase and have two minutes then we'd really appreciate it if you filled out this survey - it really helps us improve!

To show off mutations, we should add the ability to like and unlike tracks. This is done in the Spotify app using the ❤️ icon. The UI should also show which tracks are liked by the user throughout the application.

If a user opens up more than one window of the client app, we make N number of observables. Ideally we are storing these observables based on the unique Spotify id and that would dedupe subscriptions requests for the same user.

Many pages show a list of paginated content, but currently nothing else has the ability to load more of it. Let's make it possible to load more content for the various pages (playlists, saved tracks, etc)

On the web, the empty search page displays a colorful grid of genres. Would be a nice improvement over the current (simple) empty state!

To really make the demo pop, it would be nice to show the currently playing track or podcast episode. This would include the play/pause button, shuffle, repeat, prev/next, and the progress bar.

We have 2 ways we can accomplish getting the playback state:

1. Use the web playback SDK

This is Spotify's official SDK for handling real-time playback state. This also registers a device that can be targeted by any Spotify player to play through the app itself. This would make for a nicer UX, but forgoes the change for us to show off the possibility of using Apollo Client for real-time UX using subscriptions.

2. Build our own subscription that targets the Spotify API to get playback state.

Using our own API would be a great way to show off how to use a websocket connection and subscriptions with Apollo Client, with the expense of the nice UX built into the web playback SDK. This might also not allow us to register the app as a playback target. The API however has all we need to control playback, so this could be a great mechanism to demonstrate subscriptions.

https://open.spotify.com/queue

Add the ability to view the user's queue.

Limitations:

Unfortunately the Spotify API makes it impossible to determine when a user has added an item to the queue via the "add to queue" button. In Spotify's UI, this shows up in its own "Next in queue" section since tracks added in this manner "interrupt" the current flow of songs (such as playing an album). We will only be able to show the "currently playing" and next set of tracks.

In spotify subgraph, the Developer type is actually for a specific demo purpose and doesn't interact with the Spotify API. It might make sense to change that to it's own subgraph.

It would be beneficial to see if we can run the app in CodeSandbox. This would be a great way to share the app with developers as a means to be able to play around with the app without needing to clone it first.

The home page currently shows a list of 10 recommended playlists, but thats it. Let's spruce it up some more and add more content closer to what the actual Spotify home page looks like.

In the Spotify web app, the search results page has several sections:

We don't necessarily need to incorporate all of them, but adding Albums, Playlists and Songs would be a nice improvement.

We might consider adding @defer to all four fragments (including artists).

Note: the "top result" doesn't appear to be available via the public API https://developer.spotify.com/documentation/web-api/reference/search

https://open.spotify.com/search

Spotify only allows Premium users to control playback via their Spotify Connect API. The app is only built to handle premium users as of right now, so we need to determine how best to handle this.

Some ideas:

• Remove the playbar entirely
• Disable all playback controls (we can still get playback state, even if it can't be controlled)

https://open.spotify.com/user/1228247189

We currently use x-graphos-id and x- is typically not used anymore. https://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions

We should migrate to something like graphos-mock-id. This will also require a PR to modify the value we use in our Studio UI.

The error pages have little to no styling. We should spruce these up a bit to look a nicer.

Vite seems easier to work with than Webpack, which requires a lot of configuration. It looks fairly easy to integrate SSR with this tool as well

When viewing an album page, a dropdown menu is presented to the user next to the heart icon with relevant actions. Add the dropdown menu and hook up the actions. Actions that can be performed with the available APIs:

• Add to queue
• Add to Your Library
• Add to playlist
• Share -> Copy Album link

https://open.spotify.com/collection/playlists

While the app allows the user to use a context menu to perform actions on a track, a dropdown menu should also be available to perform relevant actions. Tracks in different context (albums, playlists, etc) should be presented with relevant options for that context. Actions that should be added given the available APIs include:

Tracks in an album

• Add to queue
• Go to artist
• Go to album
• Save / Remove from your Liked Songs
• Add to playlist
• Share -> Copy song link
• Open in desktop app

Tracks in an artist's top tracks

• Add to queue
• Go to album
• Save / Remove from your Liked Songs
• Add to playlist
• Share -> Copy song link
• Open in desktop app

Tracks in a playlist

• Add to queue
• Go to artist
• Go to album
• Save / remove from your Liked Songs
• Add to playlist
• Remove from this playlist (when the user own's the playlist)
• Share -> Copy song link
• Open in desktop app

We have a primary_color field included as part of the Playlist, PlaylistSimplified and PlaylistTrack types but I can't find it anywhere in the Spotify Web API.

The existing app uses the Create React App default with "React app" and the React logo. Let's update this to be a bit more official.

Currently, the script to recreate the graph in GraphOS (scripts/demo.ts) doesn't output anything. I was left wondering if the script worked or not.

Ideally, we should have:

• logs for each step the script is running, so we can track where it might fail
• if successful, log a message with a link to the graph in Studio for easy access

Also implement OpenTelemetry in subgraphs

In a haste to get this demo up and running, I've ignored testing many aspects of this app.

Testing is a huge part of development on any app with Apollo Client. We want to be able to effectively demonstrate useful testing with Apollo Client. We should therefore be good citizens and provide some tests to demonstrate how we think about it.

Having some tests will also be useful when we are ready to execute on apollographql/apollo-client#9738 as we'll be able to see if our new approach feels right.

The app is currently split up between front/back ends running on different ports. To properly demo SSR and the new React 18 features, we need to ensure the app is running SSR.

I started this application using CSS modules which provided a great starting point. Over time I decided to pull in Tailwind CSS which is now the de facto way to style everything in the app.

Because of this, styles are now fragmented between the two approaches. I'd really like to remove all the initial CSS module code and replace it with tailwind styles to ensure the CSS solution is consistent everywhere.

To accomplish this, simply search for all files with a .module.scss extension. These CSS files should match the .tsx filename they are imported in, so find the areas in which these styles are imported and replace with the tailwind equivalents.

One of the aspects of the demo is the ability to add synthetic timeouts and errors for any field in the schema when querying the GraphQL server. To add a timeout or error, this requires opening up the GraphiQL page and running a mutation. We should make this easier to configure by adding a page in the app to easily define these synthetic timeouts and errors.

Much of the artist page is implemented, however there is still some missing functionality

Some actions (like liking/unliking a track) will show a notification in the UI to confirm the action was successful. Let's implement something similar and use it as an opportunity to demonstrate the use of reactive vars/client state.

The Spotify player allows you to switch the device that is currently playing audio. Let's add the same.

https://open.spotify.com/collection/episodes

When an error is thrown on a particular page, the error bubbles up to the root error boundary, which removes all the app chrome.

For a better experience, errors thrown on page renders should only bubble up to the page's nearest <Outlet />. This should allow the app to continue displaying the app's chrome while showing the error message. This will allow the user to navigate to other parts of the app without being completely blocked.

The Spotify demo can be a great resource for learning various aspects of Apollo client and how it can be used for a complex application. Adding a first-class resource in the demo to discuss how the code is constructed and giving tips on how to play around with the code will be super helpful.