Bei Auslieferung durch Api-Gateway funktioniert das direkte Aufrufen von Deep-Links nicht mehr

[rowe42]

Wenn man mit polymer serve die Anwendung laufen lässt, kann man http://localhost:8081/animals-view aufrufen und refreshen (F5 drücken) und die Seite wird korrekt neu aufgebaut.
Wenn man die Anwendung im Api-Gateway deployed und durch diesen ausliefern lässt, führt dies zu einem Fehler. Offenbar versucht das Api-Gateway, eine entsprechende HTML-Seite in diesem Pfad zu finden, die aber nicht existiert...

[xdoo]

Das ist jetzt zwar für dieses Repo etwas off topic, aber es passt zum Issue, da die Lösung hierfür definitiv im Gateway liegt. Ich denke wir sollten hier auf Spring Cloud Gateway in der Version 2.0 umsteigen (ist aktuell noch ein Milestone Release). Das ist extrem schön konfigurierbar. Ich könnte mir vorstellen, dass

http://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.0.0.M5/single/spring-cloud-gateway.html#_redirectto_gatewayfilter_factory

oder

http://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.0.0.M5/single/spring-cloud-gateway.html#_rewritepath_gatewayfilter_factory

schon die Lösung bringen.

[rowe42]

Ich habe das analysiert und zwei mögliche Lösungen gefunden:

Option 1: Zuul mit Hash-Links
Das Problem wird hier diskutiert: https://stackoverflow.com/questions/39608956/polymer-error-on-reloading
Die vorgeschlagene Lösung ist, Hashes in die Pfade einzuführen, damit diese nicht mehr vom Webserver aufgelöst werden, sondern als Anker angesehen und deshalb an Polymer weitergegeben werden.
Folgende Änderungen (neu: use-hash-as-path):

<app-location route="{{route}}" url-space-regex="^[[rootPath]]" use-hash-as-path>
</app-location>

... (neu: das #)

<a name="keepers-view" href="#[[rootPath]]keepers-view">Keepers</a>

Nachgestellt in Branch _#80 in lhm_animad_admin_html5 und lhm_animad_admin_api_gateway.

Option 2: Spring Cloud Gateway mit RewritePath-Rule
Wie von @xdoo vorgeschlagen switchen wir den API-Gateway zu Spring Cloud, wo wir mehr Regeln haben. Wir verwenden dann diese Regel:

spring:
  cloud:
    gateway:
      routes:
      # =====================================
      - id: security_route
        uri: http://localhost:8083/index.html
        predicates:
        - Path=/{segment}-view/**
        filters:
        - RewritePath=/(?<segment>.*)-view, /

Dabei wird der Pfad /enclosures-view/... umgeschrieben auf / und dann an index.html weitergeleitet. Warum es trotzdem funktioniert, dass man direkt in der enclosures-view landet, ist mir nicht 100% klar (eigentlich müsste ja der Pfad nach der Rewrite-Logik verloren gehen).

Nachteile

• dass man das "-view" als Erkennungszeichen braucht. Hätte man das nicht, würde man eine Endlosschleife produzieren.
• Auch ist mir derzeit noch nicht klar, wie man es anstellt, im Attribut uri nicht Host und Port hartcoden zu müssen.
• Es funktionert nur mit dem embedded App-Server netty (der hier standardmäßig beim starter mitkommt). Wenn man den durch Tomcat austauscht, ist das Problem zurück. Trotzdem braucht man aber eine Regel wie die o.g. - der netty allein reicht nicht.

Beim Recherchieren, welche Gateway denn "besser" ist, bin ich auf diesen Artikel gestoßen: https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369
Zumindest in Punkto Performance scheint Zuul da besser zu sein (auch wenn der Artikel beim Spring Cloud Gateway noch eine Vorversion verwendet).

Nachgestellt in Branch _#80_Alternative in lhm_animad_admin_api_gateway (hier keine Änderungen am Frontend nötig).

Mein Vorschlag wäre, bei Zuul und dem o.g. Workaround mit den Hashes zu bleiben. Den kann man zumindest nachvollziehen und man ist nicht darauf festgelegt, vom embedded Tomcat abzuweichen.

Was ist eure Meinung? @xdoo @dragonfly28 @ejcsid @Baumfrosch

[xdoo]

Die Optionen sehe ich nicht so. Aus meiner Sicht gibt es folgende Optionen:

Option 1: Lösen wir das auf Frontendseite mit # ?
Option 2: Lösen wir das auf Backendseite mit Spring Cloud Gateway?

Bei Option 1 ist völlig irrelevant, wo die Anwendung deployed ist, bei Option 2 eben nicht.

Einen Nachteil sehe ich schon bei Option 1: Man hat immer den # in der URL.

[rowe42]

Es ist richtig, dass es bei der Lösung mit # egal ist, welches Gateway wir benutzen. D.h. meine Option 1 sollte heißen "Hash-Links" (unabhängig vom Gateway). Ansonsten sind das aber genau meine Optionen.

Was sind denn die Konsequenzen mit # in der URL, außer das es optisch nicht so schön ist?
Und wie seht ihr den Unterschied der Gateways? Zuul gibt es schon länger und wurde von Netflix wohl auch auf Stabilität getestet (mache ich jeden Abend ebenfalls mit ;-)). Das Spring Produkt ist noch relativ jung, aber offenbar etwas mächtiger als Zuul.

Bedenken habe ich mit der Nutzung von embedded Netty, was ja eher für die Entwicklungsphase genutzt wird. Wenn wir aber die Hash-Lösung nehmen, könnten wir im Backend - wenn wir das unbedingt wollen - Spring Gateway nutzen und darin trotzdem Tomcat einsetzen.

[rowe42]

Wir haben im letzten AG Meeting entschieden, dass wir die Lösung mit den # verwenden und im Backend erstmal bei Zuul bleiben.

Den Frontend-Part habe ich jetzt mal in Pull Request #141 (Branch _#78) eingecheckt, bitte von dort mit übernehmen (nicht aus dem Branch _#80).

[rowe42]

Wurde nach master gemerged und funktioniert jetzt wie beschrieben mit der #-Lösung. Schließe das Issue.