concepten - kokjp1/TechTrack GitHub Wiki
Verschillende concept ideeën
[!NOTE]
Mijn definitieve concept kan je vinden op de 🧠 Concept Pagina ↗
Ik heb verschillende concepten bedacht voor de datavisualisatie/API. Uiteindelijk waren de beste kandidaten; Steam, Spotify en AniList. De uiteindelijke winnaar is toch de Spotify API geworden. Ik ben qua onderzoek voor alle onderwerpen begonnen met de bijbehorende API documentatie te lezen. Ik haalde uit alle API's een lijstje aan informatie die ik kon opvragen en daarmee zou ik dan kijken waar ik een datavisualisatie over kon maken.
Steam
Steam is een all-in-one platform voor games. Je kan er games kopen, spelen, chatten met mensen, nieuws volgen etc.
De steam API vond ik leuk omdat ik zelf heel erg van gamen hou en uitgebreid gebruik maak van Steam. Wat ik echter moeilijk vond aan Steam was dat veel data niet bepaald interpreteerbaar was voor de algemene gebruiker (zoals ik). Veel games hebben hun API gegevens geen leesbare namen gegeven (in plaats van een achievement "Bereik level 100" noemen, staat er "ACH024"). Daarnaast vond ik het moeilijk een echte "visualisatie" te bedenken die niet neer kwam op wat grafieken en lijstjes. Dat neemt niet weg dat de Steam API wel heel leuk kan zijn voor een soort steam "wrapped" zoals spotify dat doet.
AniList
AniList is een website om gekeken Anime bij te houden en beoordelen. De website heeft een belachelijk grote dataset van anime en informatie van elke anime.
Ik kijk zelf ook anime, dus kwam al gauw uit op deze API. Deze API heeft net zoals steam zijn voordelen en nadelen. Het grootste nadeel van de API is dat het echt "harde statistieken" zijn, en dat het hierbij net zoals steam moeilijk is om een unieke visualisatie te bedenken die hierbij past. Ratings van bepaalde series en dat soort gegevens leiden al gauw tot "saaie" grafieken en tabellen. Daarnaast heeft AniList zelf ook al een soort "Wrapped" voor je profiel zoals spotify. AniList heeft echter één heel interessant onderdeel; het is volledig via GraphQL. Het lijkt mij heel interessant met GraphQL te werken, omdat het een nieuwe manier is om data op te vragen / te verwerken. Daarnaast word het ook in de professionele wereld heel veel gebruikt.
Spotify
Spotify is het grootste muziekplatform ter wereld.
Ik luister graag en veel muziek. Dat brengt je al gauw naar de spotify API. Ik dacht eerlijk gezegd dat de Spotify API heel veel data aanbood, maar in verhouding valt dat redelijk mee. Ik had wel al gauw een idee van wat ik kon maken bij de Spotify API, omdat het muziek is en ook wel te maken kan hebben met iets "sfeer" gerelateerds.
Het voordeel aan de Spotify API is dat de data vrijwel 100% betrouwbaar is. Je kan de data testen/verifieeren door gewoon je spotify client te bekijken, en het zal altijd up-to-date zijn. Daarnaast is de API Zelf ook makkelijk bruikbaar met toegankelijke API endpoints zoals /me/currently-playing
Het nadeel van de API is echter ook groot. Spotify is namelijk recentelijk (sinds een jaar +/-) bezig met hun API veiligheidsmaatregelen drastisch op te schroeven. Hierdoor is de interessantste API endpoint gewoon niet meer beschikbaar. Helaas was ik bijna klaar met mijn hele concept uitschrijven en finaliseren toen ik hier achter kwam.
Een ander heel groot nadeel is dat de Spotify API Authorization nu veel ingewikkelder is geworden. Vroeger kon je gewoon met een "implicit grant" (links) toestemming geven/inloggen. Nu moet het via een "PKCE Authorization Flow" (rechts)
Tot slot heeft spotify nu ook ervoor gezorgd dat je "app" permanent in developer modus zit, tenzij je een groot bedrijf bent en aantoonbaar >= 250.000 gebruikers gaat krijgen. Dit houdt in dat je mensen die je app willen gebruiken/testen moet whitelisten via het developer portal. Voor dit project opzich geen probleem (eenmalig docenten/testers toevoegen in de whitelist, alleen email nodig).