Caching für eingeloggte User

In den letzten Monaten habe ich sehr viel an www.amilio.de gebastelt. Das hatte zwei Gründe. Ich finde die Idee super spannend, eine Community zu haben, in der Nutzer ihre Lieblingsprodukte vorstellen können und zum anderen mag ich es, ab und zu mal wieder etwas zu programmieren, um nicht aus der Routine zu kommen.

Wenn man ein solches Projekt startet, hofft man natürlich, dass möglichst viele Besucher die Webseite finden und die Community riesig wird. Wenn man also groß denkt, dann sollte man sich von Anfang an ein paar Gedanken darüber machen, wie die Architektur und die Caching-Strategie aussieht. Im Falle von amilio habe ich mich dazu entschieden alles zu cachen und mit Invalidierung zu arbeiten, auch wenn es sich bei dem Produkt um eine Community handelt.

Der erste Schritt ist einfach. Nicht eingeloggte Nutzer bekommen ihre Webseiten aus dem Varnish ausgeliefert. Das ist kein Hexenwerk. Wenn man aber einen Varnish davor hat und angemeldete Nutzer auf den gleichen Seiten surfen, dann muss man sich etwas überlegen.

Hier gibt es aber zum Glück schon ein paar erprobte Lösungsansätze:

• Edge Side Includes: Mit ESI kann man bestimmte Teile einer Webseite von Caching ausschließen und nur diese Nachladen. Das übernimmt dann dankenswerterweise der Varnish für einen. Nachteil hierbei ist, dass man bei vielen Snippets, die man laden will auch viele Requests gegen den Server feuert und diese auch „nur“ seriell abgearbeitet werden.
• AJAX – Das ganze kann man natürlich auch per JavaScript laden. Asynchron und für den User unsichtbar. Normalerweise ist ja AJAX und Co nicht der beste Freund von Suchmaschinen, aber der Part, den wir nachladen, hat meistens in den Suchmaschinen eh nichts zu suchen.

Wir haben uns aber für die dritte Lösung entschieden. Im Falle von amilio sind die user-spezifischen Bestandteile eher minimal. Wir haben den Usernamen oben links, die Liste der eigenen Produktkanäle daneben und wenn man auf eine Listenseite kommt, hat man als eingeloggter Nutzer ein paar mehr Optionen.

Wir haben uns entschieden das ganze über Cookies und „doppelten“ Content zu lösen. Wenn sich bei uns ein User anmeldet, schreiben wir einen Cookie mit allen Informationen über diesen User. Dies beinhaltet zum Beispiel den Usernamen, seine ID, die Liste der Listen. Alles die Punkte, die individuell pro User angezeigt werden müssen. Auf der Webseiten prüfen wir dann per JavaScript, ob der User angemeldet ist und ersetzen den Platzhalternamen oben rechts durch den echten.

Als kleine Spielerei haben wir unsere Skripte so gebaut, dass jedes Element mit der Klasse „username“ auch mit dem Usernamen gefüllt wird. Für die Entwickler ist das dann ganz nett, dass sie sich keine Gedanken drüber machen müssen, was jetzt wie ausgefüllt werden muss.

Was wir noch haben ist, dass wir Elemente auf der Webseite haben, die nur für angemeldete User sichtbar sind. Sowas wie „dieses Produkt teilen“. Da wir auch hier versuchen die Seite komplett aus dem Cache auszuliefern, rendern wir diesen Snippet einfach für alle raus und wenn der User angemeldet ist, blenden wir ihn ein und wenn nicht, dann nicht. Und natürlich machen wir das wieder über Html-Klassen. Wir haben „user“, „anonymous“ und „user-123“ eingeführt. Die dritte Klasse blendet alle Elemente ein, die nur für den User mit der ID 123 sichtbar sein sollen. So zum Beispiel der löschen Button an einem Produkt.

Das ganze haben wir übrigens auf Basis des fosUserBundles konzipiert und natürlich werde ich unsere Lösung auch wieder in einem der folgenden Artikel im Detail vorstellen.