Closed nilanbais closed 1 year ago
API voor weersgegevens
Er moet een API worden gekozen die wordt gebruikt om weersgegevens op te halen. Het is daarvoor belangrijk om in kaart te hebben welke data kritisch is voor het genereren van een advies.
Gekeken naar eerder gemaakte keuzes, wordt duidelijk dat de gevoelstemperatuur leidend is in het geven van een advies. Dit is een datapunt die vaak verkregen kan worden van de APIs. Echter wordt hier niet vermeld hoe deze API aan deze waarde komt, waardoor er gevoelsmatig toch enige afbreuk wordt gedaan aan de garantie dat dit datapunt kwalitatief ook goed is (klopt het getal wel). Met dat perspectief kan gezegd worden dat het dus beter is om zelf de gevoelstemperatuur te berekenen op basis van de formule die in README.md gedocumenteerd staat.
Uit bovenstaande wordt afgeleid dat de volgende datapunten verkregen moeten worden via de API call:
side note
Van beide kan ook een min, max en avg opgehaald worden om een drievoud van scenario's te geven:
- normale advies
- worst case advies
- best case advies
Pricing m.b.t. de API (betalen voor gebruik of niet) is het volgens aspect waar naar wordt gekeken in het kiezen van een API. Ideale situatie zou zijn; een gratis te gebruiken API met een requist limit dat hoog genoeg is om te voldoen aan de (ingeschatte) behoeft voor in ieder geval de eerste aantal sprints (sprints vermeld in comment bij #3). Zodoende vallen de API met een request limit van 15/maand en alles wat in de range zit, af.
De keuze is voor nu gevallen op de volgende optie. | API | Forcast mogelijkheid | Prijs | Request limit | Doc link |
---|---|---|---|---|---|
WeatherAPI | ja, tot 3 dagen. Bij uitbreiding subscription kan het tot 5 dagen | gratis | miljoen/dag | link |
De mogelijkheid om de weersverwachting van de komende dagen op te halen is een wens die is uitgesproken voor een mogelijke uitbreiding van de functionaliteit van de web app. Om de kosten tot een minimum te houden, wordt dit aspect voor nu buiten beschouwing gelaten. Het is daarentegen wel een vastgelegd doel om de objecten zo te bouwen dat een plug-and-play achtige opbouw verkregen en behouden wordt, waardoor het wisselen van specifieke invulling van functionaliteit relatief gemakkelijk te realiseren moet zijn.
APIAccess component ontwerp
Voor het ontwerp van het component wordt een eerder gebruikt ontwerp toegepast voor het bevragen van APIs. Het ontwerp dat als voorbeeld wordt gebruikt is de python implementatie van dit project. voor code, ga naar framework/api.
Dit ontwerp scheidt de authenticatie van de API call en houdt de keys etc. die geheim moeten blijven, uit de code. Dit authenticatie object is daarbij gemakkelijk uit te breiden met nieuwe authenticatie mogelijkheden. Nadeel van dit ontwerp is dat het gebruikt maakt van meer environmental variables dan misschien nodig zou zijn, maar de afscheiding is in mijn beleving meer waard dan een .env bestand meer of minder.
edit- bovenstaande wordt eigenlijk pas interessant wanneer 2 of meer API's gebruikt worden in de software. Hier wordt er echter gebruik gemaakt van 1 API. De manier van implementatie zal dus enigszins afwijken van he eerder genoemde ontwerp.
Geïmplementeerde api: https://www.weatherapi.com/docs/
Sprint benoemd in #3
Het doel is het kunnen presenteren van het weerbericht op de homepage. De focus ligt hier bij de componenten die de functionaliteit realiseren. De vormgeving van de homepage wordt in deze sprint buiten beschouwing gelaten.
Comments in deze issue moeten onder andere de vooruitgang bijhouden.