search

ORFAP / FAPBackend

0 stars 0 forks source link

Endpunkt zum abrufen der benötigten Daten per Setting #10

Closed FabianWilms closed 8 years ago

FabianWilms commented 8 years ago

Es wird ein Endpunkt benötigt, der ein Settings-Objekt als Parameter übergibt und anhand der Parameter die verlangten Daten zurückliefert. Vom Backend muss der angegebene Zeitraum und alle angegebenen Filter beachtet werden. Außerdem müssen Timesteps und die Axenbeschriftung beachtet werden. Wenn keine Filter angegeben werden, müssen dementsprechend die Summen der gesammelten Daten berechnet werden.

peter-mueller commented 8 years ago

So müsste eine Response vom Backend ausschauen.

{
    "type": "line",
    " xLabel": "...",
    " yLabel": "...",
    "data": {
        "labels": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"],
        "datasets": [
            {
                "label": "Lufthansa",
                "data": [28, 48, 40, 19, 86, 27, 90]
            },
            {
                "label": "Ryan Air",
                "data": [65, 59, 80, 81, 56, 55, 40]      
            }
        ]
    }
}

Der type ist optional, das wäre der typ des Graphen (line / bar)

darenegade commented 8 years ago

So wird es definitiv nicht aussehen XD

peter-mueller commented 8 years ago

Dann muss aber möglichst früh feststehen wie es aus schaut, weil alles was davon abweicht eine Anpassung in der GUI bedeutet

darenegade commented 8 years ago

Wie gesagt, mache ich das heute fertig.

FabianWilms commented 8 years ago

Habe den Issuetext nochmal angepasst, da die Axenbeschriftung fur die Daten mitgeliefert werden muss.

darenegade commented 8 years ago

Um GUI Elemente sollte sich die GUI kümmern. Axenbeschriftungen sollten meiner Meinung nach nicht vom Backend kommen.

darenegade commented 8 years ago

Ich merk schon, dass ihr es euch gerne einfach machen wollt XD

darenegade commented 8 years ago

Am besten kommen vom Backend gleich die HTML Komponente fertig konvertiert und wer weiß was noch

darenegade commented 8 years ago

Ich wollte euch Routen zurück liefern, die durch den übergebenen Filter gefiltert wurden und nach dem Wert für x sortiert sind. Und solange der Filter nicht geändert wird, kann der y Wert und der TimeStep angepasst werden, ohne neue Daten holen zu müssen. Und man könnte auch mehrere Werte für y gemeinsam anzeigen. So war es bisher von mir gedacht.

darenegade commented 8 years ago

Shitstorm.start()

peter-mueller commented 8 years ago

OK, meine Meinung ist wenn man schon die ganzen Einstellungen hat kann man auch alles direkt vorbereiten. Dann wäre es für uns in der GUI ziemlich klar getrennt (ändern sich die momentanen settings ist ein request nötig).

So Dinge wie Farben und Positionen werden natürlich von der GUI übernommen :)

Findest du dass denn eher ein Aufwand- oder Design Problem das so zu machen?

darenegade commented 8 years ago

Hauptsächlich Design Problem. Man merkt schon daran, dass Labels vom Backend geliefert werden sollen, dass sich hier das Backend komplett und speziell nach dieser GUI ausrichtet. Und das ist aus meiner Sicht kein gutes Design. Ich weiß, dass wir nur eine GUI haben, aber deshalb sollte man eine gewisse Form waren. Sonst hätten wir uns diese ganze Mikroservice Geschichte sparen können.

darenegade commented 8 years ago

@FabianHoltkoetter @peter-mueller Seit ihr noch in der Uni? Wir können auch gerne persönlich diskutieren, damit es schneller geht. Ich bin noch in R1.012

peter-mueller commented 8 years ago

Ne sry bin schon daheim. Wenn du nur filtern möchtest ist ja nicht nur die Response umstritten sondern auch der Endpunkt, weil dann ja nicht ein volles settings Objekt benötigt wird.

Vllt klären wir das einfach morgen nach EC?

darenegade commented 8 years ago

Dass der Endpunkt das Setting Objekt erwartet, war ja auch eine GUI Idee und ich bin euch da ja entgegengekommen. 😄

FabianWilms commented 8 years ago

Es war sicher nicht die Idee uns die Arbeit zu erleichtern. Wenn dir das zu viel ist hätte ich den Endpunkt auch implementieren können und fänd es auch immer noch sinnvoll. Hier meine Gründe warum ich die Generierung der Graph-Daten im Backend sinnvoll fand:

  1. Es ist eine Geschäftslogik, und die gehört nicht ins Frontend, weil man auf die Berechnung der Daten auch für eventuelle weitere Anwendung zurückgreifen können möchte und diese nicht erneut implementieren will.
  2. Das "heavy lifting" sollte nicht beim Client geschehen. Wenn im Zeitraum der letzten Zehn Jahre die Daten von mehreren Fluggesellschaften zusammen gerechnet werden müssen ist das ein nicht zu unterschätzender Rechenaufwand der auf dem Server performanter läuft.
  3. caching. Wie gesagt gibt es viel Rechenaufwand. Wenn man nun einen Endpunkt im Backend hat können anfragen mit den gleichen settings gecached werden. Auf dem Client wurde alles immer wieder neu berechnet werden. Gerade da settings geteilt werden ist dies sinnvoll.

X- und ylabels haben natürlich im Backend nichts verloren, da gebe ich dir recht. Aber das aufarbeiten der Daten finde ich insgesamt sinnvoll. Wie gesagt, muss von mir aus nicht sein dass du es machst wenn es dir zu viel ist, aber ansonsten würde ich das dann gerne im nächsten spring an gehen.

darenegade commented 8 years ago

Wie oben bereits gesagt, habe ich kein Problem mit dem Aufwand. Auch noch mal Allgemein zu eurem Aufwand. Ich finde es sehr schade, dass ihr nun schon zum zweiten Mal etwas in der GUI implementiert und eine gewisse Schnittstelle im Backend voraussetzt ohne mich mit einzubeziehen. So sollte Kommunikation in einem Team definitiv nicht laufen. Schnittstellen müssen immer vorher festgelegt werden. Dann müssten wir diese Diskussion nicht schon wieder kurz vorher führen. Und an deiner Argumentation merke ich, dass ihr mich falsch versteht. Gegen das Aufbereiten der Daten im Backend habe ich nie etwas gesagt, nur nicht in der Form, wie es ob steht. Hier mal ein etwas angepasster Vorschlag:

{
 "key1": [ data1, data2, ..., dataN],
 "key2": [ data1, data2, ..., dataN]
}

Die Keys entsprechen allen möglichen Werten je nach ausgewähltem qualitativem Wert und die Daten entsprechen dem quantitativen Werten im entsprechend gewähltem Zeitraum und TimeStep sowie um den Filter reduziert.

1. Beispiele:

Qualitativ: Airline

Quantitativ PassangerCount

From: Jan 2015

To: Mar 2015

TimeStep: Month

{
 "Lufthansa": [ 50, 100, 75],
 "AirBerlin": [ 25, 80, 200]
}

2. Beispiele:

Qualitativ: Time

Quantitativ Delay

From: 01 Jan 2015

To: 03 Jan 2015

TimeStep: Day

{
 "01-01-2015": [ 25 ],
 "02-01-2015": [ 30 ],
 "03-01-2015": [ 5 ]
}
FabianWilms commented 8 years ago

Find ich cool den Vorschlag :+1: muss Peter nur noch bestätigen, der ist der graph-mensch

peter-mueller commented 8 years ago

Das ist ja quasi mein Vorschlag, nur die datasets minified.

Die Labels müssen aber mM nach trotzdem mit dabei sein ( oben monday, tuesday... hier jetzt Jan 2015, Feb 2015)

Auch die axis Beschriftung sollte dabei sein, ist ja nur ein copy aus dem request.

darenegade commented 8 years ago

Der Vorschlag war ja eine Adaption deiner Version, gekürzt um alles was das Backend nichts angeht.

peter-mueller commented 8 years ago

labels

Hier noch eine Grafik :smile: warum mir die labels wichtig sind. Ich finde man schickt von backend Seite aus logisch eine Tabelle, und die sollte nicht nur Äpfel und Birnen beinhalten.

@FabianHoltkoetter Wie siehst du das?

Die einzelnen Daten aber reichen ja schon gut aus um viel am Donnerstag zu zeigen. Bis wann wird das ca. gehen (also zumindest mit einem Beispielsettings request)?

darenegade commented 8 years ago

Implementiert ist es schon. Muss es noch testen und eventuell Fehler beheben. Wann genau kann ich nicht sagen, da es ja an den Fehlern hängt. XD Heute im laufe des Tages sollte es stehen.

Zur Argumentation: Deine Grafik unterstützt nicht unbedingt deine Argumentation. Wenn ich eine Freunde Verwaltung mit Spring Data baue und einen Get auf die Freunde von einem User mache, dann schicke ich auch nicht den User nochmal zurück. Man bekommt die Antwort auf den Request den man gemacht hat und was für ein Request das war, weiß hoffentlich der Client noch und muss nicht vom Backend daran erinnert werden.

darenegade commented 8 years ago

Oder noch besser ich mache eine Anfrage über eine findBy Methode. Dann kommen auch nicht die Parameter der FindBy Methode zurück.

peter-mueller commented 8 years ago

Da ist es ja auch URL encoded. Beim erstellen einer Entität kann es auch Sinn machen die gesamte erstellte Entität zurückzuliefern.

darenegade commented 8 years ago

Das zurückliefen der Entität beim Erstellen brauchst du ja wegen der OID. Obwohl auch hier Spring Data teilweise nur einen Response zurück liefert mit der location im Header.

FabianWilms commented 8 years ago

Ich verstehe das Problem aktuell nicht. (Oder nicht mehr :p) Mit Renés Lösung werden doch aktuell dann immer die passenden labels für die Daten als key mitgeliefert OÖ. Also time -> 2015-05-04 Airline -> Lufthansa Destination -> los Angeles etc

darenegade commented 8 years ago

Er will auch Labels für die einzelnen Daten in der Datenliste der einzelnen Keys und Axen Beschriftung.

FabianWilms commented 8 years ago

Der Timestep ist doch nur relevant wenn man auf der x-achse auch die Zeit betrachtet. Somit ist natürlich auch renes eines Beispiel mit qualitative: airline "falsch" weil da nur ein wert geliefert werden würde

darenegade commented 8 years ago

In dem Fall hätten wir für jeden Key immer nur einen Wert, egal was der qualitative Wert ist. Dann hätte ich das falsch verstanden. Ich dachte, dass die Quantitativen Werte anhand vom Timestep auch nochmal aufgeteilt werden sollen.

darenegade commented 8 years ago

Mach auch Sinn und würde das ganze schön vereinfachen. 😄 Aber ich bin mir mit der Anforderung da nicht sicher.

darenegade commented 8 years ago

Je mehr ich darüber nachdenke, desto besser finde ich das. Dann ist der Timestep nur interessant bei dem qualitativen Wert "Time". Und Peter hat auch keine Verwirrung mehr in der Liste, da eh nur ein Wert da steht XD

FabianWilms commented 8 years ago

Vielleicht war das mein problem warum ich euer Problem nicht gesehen habe?^^ Bei Timestep DAY, MONTH und YEAR aber beachten: Bei DAY soll dann Montag bis Freitag nur da stehen, bei MONTH Januar bis Dezember und nur bei Jahr soll dann wirklich das jeweilige Jahr da stehen. Also nicht bei DAY etwa alle Tage des angegebenen Zeitraums. Ich hoffe die Formulierung macht sinn xD

FabianWilms commented 8 years ago

Vielleicht ein Beispiel:

Time from: 01.01.2015 Time to: 01.03.2015 Qualitative: Time Quantitative: whatever Timestep: DAY

 Montag: 2
 Dienstag: 2,
 Mittwoch 5,
 Donnerstag: 2,
 Freitag: 9,
 Samstag: 6,
 Sonntag: 3
darenegade commented 8 years ago

Gut das du es sagst, da ich mir da noch unsicher war.

darenegade commented 8 years ago

Machen wir das jetzt so? Ist Peter damit auch einverstanden?

{
 "key1":  dataInteger,
 "key2":  dataInteger
}

1. Beispiele:

Qualitativ: Airline

Quantitativ PassangerCount

From: Jan 2015

To: Mar 2015

{
 "Lufthansa": 200,
 "AirBerlin":  25
}

2. Beispiele:

Qualitativ: Time

Quantitativ Delay

From: 01 Jan 2015

To: 03 Jan 2015

TimeStep: Day

{
 "Monday":  25 ,
 "Tuesday":  30 ,
 "Thursday":  5 
}

3. Beispiele:

Qualitativ: Time

Quantitativ FlightCount

From: 01 Jan 2014

To: 01 Jan 2016

TimeStep: Year

{
 "2014":  200 ,
 "2015":  500 ,
 "2016":  20 
}
peter-mueller commented 8 years ago

Ok ich hab es glaub anderst verstanden. Zwar nicht 100% aber ich dachte immer Time ist extra bzw bewirken die Selektoren immer einen multi-line graph z.B. beispiel 1:

labels: ["Jan 15", "Feb 15", "Mar 15"] \ (Timestep Month) { lufthansa: [1,2,3], ryanair: [0,1,0] }

darenegade commented 8 years ago

So hatte ich es auch erst verstanden. Tja, dass ist jetzt die Frage, wie wir es machen.

FabianWilms commented 8 years ago

Das liegt bei euch was euch leichter fällt für diesen sprint. "Falsch verstanden" funktioniert immer.

darenegade commented 8 years ago

Ich wäre für deine Version.

peter-mueller commented 8 years ago

Dann ist aber das mit Graph anzeigen recht billig in der GUI.

darenegade commented 8 years ago

Ist doch gut XD

darenegade commented 8 years ago

Done