| 6 |
Frontend |
- Abfrage der Livedaten von der London Travelers API und anzeige für jeden BikePoint |
+ Abfrage der Livedaten von der London Travelers API und Anzeige für jeden BikePoint |
0,5 |
Tim Herbst |
52 |
@@ -117,15 +117,16 @@ Folgender zeitlicher Rahmen ergab sich nun rückblickend für unser Projekt:
Dokumentation |
Projektdokumentation und Präsentation |
3 (1,5 + 1,5) |
- Marcel Schwarz, Tim Herbst |
+ Tim Herbst, Marcel Schwarz |
3 |
-// TODO: Abweichung vom Projektplan farblich Kennzeichnen
+// TODO: Abweichung vom Projektplan durch druchstreichen Kennzeichnen -> sonst todo löschen
+// Neue Spalte mit abweichung oder nicht
-Generell haben wir akkurat und präzise die Personentage geschätzt und haben bei keinem geplanten Arbeitspaket die dafür vorgesehene Zeit überschritten.
-Durch die enorme Performancesteigerung im Backend mussten wir mehr Zeit im Frontend für die dynamische Interaktion zwischen Tabelle und Mini-Map (Im Dashboard) einplanen. Dadurch hat sich aber der Zeitplan des gesamten Projektes nicht verändert.
+Generell haben wir akkurat und präzise die Personentage geschätzt und bei keinem geplanten Arbeitspaket die dafür vorgesehene Zeit überschritten.
+Durch die enorme Performancesteigerung im Backend mussten wir mehr Zeit im Frontend für die dynamische Interaktion zwischen Tabelle und Mini-Map (im Dashboard) einplanen. Dadurch hat sich aber der Zeitplan des gesamten Projektes nicht verändert.
# Backend
## Architektur
@@ -137,7 +138,7 @@ graph LR
NGINX -->|Static Files| FS[Dateisystem]
NGINX -->|/api| BACK[Python Backend]
BACK -->|Dashboard, Historische Daten| DB[(Unsere Datenbank)]
- BACK -->|Bikepoints| LONDON[London API]
+ BACK -->|Bikepoints, Verfügbarkeit| LONDON[London API]
LONDON --> LON_DB[(Live Datenbank)]
end
@@ -147,11 +148,11 @@ graph LR
TRANSFORMER --> DB
end
```
-Die Architektur sieht vor, dass alle Requests über unser eigenes Backend abgewickelt werden. Dadurch müssen keine Drittanbieterimplementierungen in das Frontend und auch alle URLs zeigen auf einen Server. Weiter müssen die API Tokens für die London API nicht im Client-Code auftauchen, was weitere Sicherheit bietet.
+Die Architektur sieht vor, dass alle Requests über unser eigenes Backend abgewickelt werden. Dadurch müssen keine Drittanbieterimplementierungen in das Frontend und auch alle URLs zeigen auf einen Server. Weiter müssen die API Tokens für die London API nicht im Client-Code auftauchen, was zusätzliche Sicherheit bietet.
-Zuletzt können Filterungen der London-API-Daten bereits im Backend erledigt werden, was weitere Rechen- und Netzwerklast vom Benutzer nimmt.
+Zuletzt können Filterungen der London-API-Daten bereits im Backend erledigt werden, was ebenfalls Rechen- und Netzwerklast vom Benutzer nimmt.
-Das Backend bietet alle Endpoints über eine Swagger UI als Dokumentation an. Dort können alle Datenbeschreibungen abgerufen werden und Anfragen können vorab getestet werden. Die Spezifikation kann auch ganz einfach als openapi.json abgerufen werden, mehr dazu aber in einem späteren Kapitel.
+Das Backend bietet alle Endpoints über eine Swagger UI als Dokumentation an. Dort können alle Datenbeschreibungen abgerufen und Anfragen können vorab getestet werden. Die Spezifikation kann auch ganz einfach als openapi.json heruntergeladen werden, mehr dazu aber in einem späteren Kapitel.
## Datenaufbereitung (Theorie)
Zunächst war es wichtig, welche Daten wir für unsere Diagramme überhaupt auswerten müssen. Der [OpenData Export](https://cycling.data.tfl.gov.uk/) bietet zwei Arten von großen Datensätzen an.
@@ -174,9 +175,9 @@ Bis auf die Bike Id haben wir alle Spalten in unsere eigene Datenhaltung überno
Zusätzlich dazu wurden noch die Accidents und die Bikepoints aus der Live API gecached, dazu aber mehr in der Implementierung.
**Anmerkung:** Der Datensatz der "Usage Stats" war sehr unsauber exportiert, weshalb ein einfaches Parsing nicht möglich war. Folgende Probleme sind mehrfach beim Import aufgetreten:
-* Eine Datei wurde mehrfach mit anderen Namen hochgeladen. Daraus folgt, dass die unique Constraint der "Rental Id" Spalte fehlschlägt.
+* Eine Datei wurde mehrfach mit anderem Namen hochgeladen. Daraus folgt, dass die unique Constraint der "Rental Id" Spalte fehlschlägt.
* Spalten waren in den CSV-Dateien nicht immer gleich benannt, oder sogar gar nicht vorhanden. Sollte dies vorkommen wurden die Spalten beim Parsing umbenannt, oder die ganze Datei wurde weggelassen.
-* Weiter wurden nachträglich Bikepoint Id geändert, was es nötig gemacht hat, dass die aktuellen Bikepoint Ids über den Namen angepasst werden mussten.
+* Weiter wurden nachträglich Bikepoint Ids geändert, was es nötig gemacht hat, dass die aktuellen Bikepoint Ids über den Namen angeglichen werden mussten.
**Anmerkung:** Der Datensatz der Accidents war ebenfalls fehlerhaft. Dort wurde jeder Unfall doppelt zurückgegeben.
@@ -197,23 +198,23 @@ app = FastAPI()
def root():
return {"message": "Hello World"}
```
-Der Output ist dann `{"message": "Hello World"}`
+Der Output ist dann: `{"message": "Hello World"}`
Die API kann dann über den eingebauten Gunicorn Server gestartet werden. Dieser wird dann später über einen Nginx Reverse-Proxy nach außen geöffnet.
-Ein anderer Grund für die Nutzung von Python war jedoch auch die Interoperabilität mit SQLite, userer gewählten Datenbank-Engine. Python nutzt hierzu die C-Implementierung (lib-sqlite) von SQLite, was bestmögliche Performance bietet.
+Ein anderer Grund für die Nutzung von Python war jedoch auch die Interoperabilität mit SQLite, userer gewählten Datenbank-Technologie. Python nutzt hierzu die C-Implementierung (lib-sqlite) von SQLite, was bestmögliche Performance bietet.
## Endpunkterklärung
Da unser Backend nur Daten bereitstellt, sind auch nur GET-Endpoints implementiert worden. Auch Authentifizierung gibt es nicht. Die Endpunkte sind in zwei Gruppen unterteilt, "Local" und "Upstream". Die "Local" Endpoints greifen auf die Lokale Datenbank zu, wohingegen die "Upstream" Gruppe nur eine interne Weiterleitung ist. Dies ist wichtig, sollte etwas nicht funktionieren. Denn wenn ein mit "Upstream" markierter Endpunkt nicht funktioniert, muss es nicht zwingend an unserer Implementation liegen.
-Die Upstream Endpoints sind:
+Die upstream Endpoints sind:
1. **/api/latest/bikepoints**
Liefert alle Bikepoints in einer Liste zurück
2. **/api/latest/bikepoints/:id**
Liefert einen spezifischen Bikepoint zurück (reduziert Bandbreite und Ladezeit)
-Die Lokalen Endpoints sind:
+Die lokalen Endpoints sind:
1. **/api/latest/accidents**
Liefert alle Accidents zurück
2. **/api/latest/accidents/:year**
@@ -249,10 +250,10 @@ Programmatisch sieht das wie folgt aus (AppComponent.html):
| id |
- eindeutiger Identifier vom Typ string |
+ eindeutiger Identifier vom Typ string |
| commonName |
- sprechender Name der Station vom Typ string |
+ Der Name der Station vom Typ string |
| lat |
- Breitengrad vom Typ number |
+ Breitengrad vom Typ number |
| lon |
- Längengrad vom Typ number |
+ Längengrad vom Typ number |
| status |
- verschachteltes Objekt vom Typ BikePointStatus |
+ verschachteltes Objekt vom Typ BikePointStatus |
-Das verschachtelte Objekt status vom Typ BikePointStatus hat wiederum folgende Felder:
+Das Subobjekt `status` vom Typ `BikePointStatus` hat wiederum folgende Felder:
| id |
- eindeutigen Identifier vom Typ string |
+ eindeutigen Identifier vom Typ string |
| color |
- Farbe für das Icon auf der Mini-Map vom Typ string |
+ Farbe für das Icon auf der Mini-Map vom Typ string |
| commonName |
- sprechender Name der Station vom Typ string |
+ sprechender Name der Station vom Typ string |
| lat |
- Breitengrad vom Typ number |
+ Breitengrad vom Typ number |
| lon |
- Längengrad vom Typ number |
+ Längengrad vom Typ number |
| maxEndDate |
- spätest-mögliche Datum in der eine Ausleihe enden kann, vom Typ string |
+ spätest-mögliche Datum in der eine Ausleihe enden kann, vom Typ string |
| maxStartDate |
- frühest-mögliche Datum in der eine Ausleihe starten kann, vom Typ string |
+ frühest-mögliche Datum in der eine Ausleihe starten kann, vom Typ string |
-Programmatisch ähnelt dieses Domänenobjekt dem Map-Bike-Point.
+Programmatisch ähnelt dieses Domänenobjekt dem `MapBikePoint`.
### Methoden, welche mit dem Backend kommunizieren
#### Allgemeiner Aufbau
@@ -382,7 +383,7 @@ export const environment = {
apiUrl: 'https://it-schwarz.net/api/'
};
```
-Somit ergibt sich dann bei einem Aufruf mit einem HTTP-GET folgende Architektur der URL:
+Somit ergibt sich dann bei einem GET-Aufruf folgende Zusammensetzung der URL:
```typescript
public exampleMethod(param: string): Promise