Zitat von appelgrenfan (Beitrag 3792171)

In der Theorie ist das extrem simpel, das stimmt. In der Praxis habe ich aber zu viele Probleme erlebt, um mir das zu wünschen, wenn es nicht unbedingt sein muss.

Wenn du nur die beiden Fälle hättest: (1) Daten kommen "sofort" oder (2) Fehlermeldung kommt "sofort", dann ist es wirklich einfach. Aber du hast meist alle denkbaren (und noch ein paar auf die man erst kommt, wenn man's sieht) Zwischenstufen. Nur ein Beispiel: Die Verbindung zw. Datenquelle und MyTT lahmt. Der Cache ist per Timeout so programmiert, dass er nach 20 Sekunden übernimmt. Die Daten kämen aber nach 21 Sekunden an, trotzdem zeigt MyTT die gecachten Daten an. Je nach Monitoring und Reaktionszeit kann das schon mal das ganze Wochenende so laufen und du hast Montag morgens noch die Daten vom Freitag.

Du hast schon recht, auch das ist alles lösbar. Mir fehlt nur beim Blick auf die Zuverlässigkeit der bisherigen Lösung das Vertrauen, dass zusätzliche Komplexität das Ganze wirklich besser machen würde.

Aber ohne die tatsächliche Architektur und Vereinbarungen zu kennen, ist das alles nur wilde Spekulation.

Zitat von chokdee (Beitrag 3792186)

Daten per Javascript von anderen Servern abzuholen ist durch die
Same-Origin-Policy der Browser verboten. D.h. du darfst nur Daten von der gleichen Domain abholen. Also müsstest du das vom Server aus machen. So ähnlich mache ich das auch mit meiner App.

Zitat von mithardemb (Beitrag 3792191)

Wenn der eigentlich angefragte Sender das explizit erlaubt (Stichwort CORS Header) ist das ohne Probleme möglich. Das kommt auch sehr häufig, z.B. bei der eingeblendeten Werbung, zum Einsatz.

Zitat von chokdee (Beitrag 3792198)

Du hast Recht. Würde das tendenziell aber trotzdem eher auf dem Server machen. Liegt vielleicht auch daran, dass ich bisschen mehr Möglichkeiten hätte beim Parsen.

Zitat von appelgrenfan (Beitrag 3792171)

Nur ein Beispiel: Die Verbindung zw. Datenquelle und MyTT lahmt. Der Cache ist per Timeout so programmiert, dass er nach 20 Sekunden übernimmt. Die Daten kämen aber nach 21 Sekunden an, trotzdem zeigt MyTT die gecachten Daten an. Je nach Monitoring und Reaktionszeit kann das schon mal das ganze Wochenende so laufen und du hast Montag morgens noch die Daten vom Freitag.

Zitat von mithardemb (Beitrag 3792201)

Selbstverständlich ist es sinnvoller das serverseitig zu machen und damit eben nicht per EMCA zu machen. Ich hatte Trillians Ansatz aber so verstanden, dass das clientseitig im Browser passieren sollte, weil nach seiner Aussage "die Click-tt-Seite stabil ist".

Das wiederum würde implizieren, dass das Problem nicht aufgrund einer Überlastung von click-tt verursacht wird. Unter dieser würde auch der Client leiden.

Zitat von chokdee (Beitrag 3792211)

Wenn ich das jetzt so sehe, dann frage ich mich wirklich warum die Seiten von click-tt funktionieren, aber die REST Aufrufe angeblich nicht gehen sollen. Selbst wenn es Last wäre, so kann mir doch keiner erzählen, dass man das nach Jahren nicht hinbekommt. Entweder Unfähigkeit, oder Sparsamkeit bzgl. Server muss es sein.

Zitat von mithardemb (Beitrag 3792213)

Ich denke ohne hinter die Kulissen schauen zu können, ist es schwierig das Problem zu benennen.

- liegt es an fehlerhafter Software
- liegt es an Durchsatzproblemen bei mytischtennis oder bei click-tt
- gibt es bei click-tt evtl. replizierte Server und der Zugriff von mytischtennis ist an einen gebunden.
- hat man vertraglich nur ein gewisses Transfervolumen erworben für einen Zeitabschnitt erworben und dann wird in diesem Zeitabschnitt nichts mehr geliefert oder es kommt Throttling zum Einsatz.
....

Der Phantasie sind da wenig Grenzen gesetzt, aber von außen kann man eben nur mutmaßen.