Wenn ich lese, dass zu einer Veranstaltung das Mitbringen von Fingerfood erwünscht ist, denke ich immer zuerst an Fischstäbchen. Vielleicht, weil sie auf Englisch Fish Fingers heißen. Die Vorstellung, dass man am Ende mit einer Pfanne Fischstäbchen im Rucksack ankommt, finde ich allerdings ziemlich absurd. ✌🏻

Side-Project-Tagebuch: recex (2)
Facettensuche mit RediSearch

Ihr kennt das. Man sucht beim Onlinehändler seines Vertrauens nach Schuhen, gibt einen Suchbegriff ein und neben den Suchergebnissen erscheinen weitere Filteroptionen, mit denen man das Ergebnis weiter einschränken kann. Damit man direkt bescheid weiß, steht auch direkt daneben, wie viele Suchergebnisse es für diesen Filter noch gibt.

Diesen Quatsch nennt man gemeinhin Facettensuche und an und für sich ist das eigentlich ganz praktisch. Leider ist es nicht mal eben durch den Aufruf von zwei PHP-Funktionen implementiert, daher habe ich bisher immer davon abgesehen, so etwas bei einem einer Side-Projects einzubauen. Also klar, es ist auch nur in wenigen Fällen sinnvoll, aber zum Beispiel fin, meine Finanzverwaltung, könnte sowas sicher gebrauchen.

Nun beschäftige ich mich seit gestern ja mit meinem neuen Projekt recex und natürlich soll man da auch nach Rezepten suchen können. Von Anfang an war mir da klar, das ich auch direkt nach Zutaten suchen will und nicht nur wildes Matching von Wörtern im Rezepttitel haben möchte.

Glücklicherweise basiert das Backend von recex auf Blogchain — ich kann also mit Fug und Recht behaupten, meine Rezepte in einer Blogchain zu speichern — und das bedeutet, RediSearch ist bereits angebunden, wie schwer kann es also sein, die Suche entsprechend umzustricken?

Index anlegen

Als erstes musste ich einen neuen Index anlegen. Neben Titel und Text (in dem Fall die Zubereitungsschritte des Rezepts) möchte ich auch Tags (“hellofresh“, “wegtuppern“) und Zutaten (“Zwiebel“, “Kartoffel“) indizieren. Leider unterstützt ethanhann/redisearch-php das Tag-Feld noch nicht, also erstelle ich den Index manuell per redis-cli:

FT.CREATE recipes SCHEMA title TEXT text TEXT ingredients TAG SORTABLE tags TAG SORTABLE

Das Indizieren der Rezepte ist wieder easy gemacht, denn dabei sind die TAG-Felder nur Komma-separierte Strings. Das funktioniert also über die PHP-Library

Query

Die Query-Syntax ist leider etwas kompliziert. Das RediSearch-Feature, mit dem wir unsere Facetten bauen heißt Aggregations und ist ziemlich mächtig.

Die Query sieht am Ende etwa so aus:

FT.AGGREGATE recipes "*" APPLY split(@tags) AS tag GROUPBY 1 @tag REDUCE count_distinct 1 @tag AS count SORTBY 1 @count DESC

Die Dokumentation ist zwar eigentlich gut, ich brauchte aber trotzdem einen Moment, bis ich hier auf die richtige Kombination von Wörtern kam. Also:

Etwas verwirrend: Man muss vielen Befehlen (GROUPBY, REDUCE, etc) sagen wie viele Argumente folgen. Daher die ganzen 1-er. Fand ich am Anfang etwas verwirrend, ist aber wohl eine Limitierung des Redis-Command-Syntax.

Leider kann die PHP-Library auch diese Aggregations noch nicht, daher musste ich die Query auch händisch in meinen Code aufnehmen, was ganz fürchterlich aussieht, weil rawCommand jedes Wort einzeln erwartet, warum auch immer:


$result $redis->rawCommand('FT.AGGREGATE''recipes'$query,
    
'apply''split(@tags)''as''tag',
    
'groupby''1''@tag',
    
'reduce''count_distinct''1''@tag''as''count',
    
'SORTBY''1''@count''desc'
);

Update: Die Library kann doch schon Aggregations, ich war nur zu Blöd es zu finden 😇

Das Ergebnis ist auf jeden Fall ein Array, mit allem, was wir wissen wollen. So einfach! Ist es nicht schön?

Zusammen mit einem kleinen Query-Parser kann man sich sowas bauen, und fröhlich nach Rezepten suchen:


RediSearch ❤️

IMG_0513.jpg

Bisschen übertrieben dieser “Morning“-Filter von Snapseed, aber auch ganz schön.

Side-Project-Tagebuch: recex (1)

Also, der Name ist natürlich noch Work-In-Progress. Ich fand es witzig, weil es wie “regex” klingt. Aber natürlich hat der Recipe Explorer erstmal nichts mit Regulären Ausdrücken zu tun.

Folgendes Problem: Seit mehr als einem Jahr ernähren wir uns eigentlich fast nur noch von Gerichten, die über eine der mittlerweile über einhundert HelloFresh-Rezeptkarten gekocht wurden. Das ist an und für sich ziemlich gut, denn, wenn es ans Einkaufen geht, geht man halt zum Stapel, zieht ein paar Karten und sucht sich aus, was man essen will — im Grunde fast so, wie die wöchentliche Wahl der drei Gerichte auf der HelloFresh-Webseite (ja, für neue Inspirationen, und aus Faulheit, kommt da immer noch fast jede Woche ein Paket).

Umso mehr Karten es werden, wird es natürlich immer anstrengender. Die Stapel werden groß und schwer und man hat keine Lust mehr sie zu transportieren. Außerdem ist es nervig, die Zutatenliste immer von Hand abzuschreiben und bei vielen Rezepten haben wir mittlerweile Sachen verbessert, die natürlich einfach mit Kuli auf den Zettel notiert wurden.


Als ich Blogchain baute, kam ich schon mal kurz vom Pfad ab und schrieb zumindest ein paar Templates um auch Rezepte anzeigen zu können. Des Weiteren baute ich ganz viel Quatsch, z.B. etwas, das alle Vorkommnisse von Texten wie “für 10-15 Minuten in den Backofen” automatisch durch einen “Timer starten” Button ersetzt. Spielerei!


Ein großer Roadblock war für mich bisher, das ich keine Lust hatte 100 Rezepte abzutippen. Heute fiel mir ein, manchmal braucht sowas bei mir echt lange, dass die HelloFresh-Webseite ja eine (mittelmäßig gut funktionierende) Single-Page-App ist und damit sicher eine REST-API hat, über die man sicher alle Rezepte strukturiert ziehen kann. Denn auf der Webseite sind sie ja auch sichtbar!

Es dauerte keine 30 Minuten und ich hatte alle Rezepte aus der API gepult und lokal zur weiteren Verarbeitung gespeichert. Ein Hoch auf JSON-APIs! Falls ihr ähnliches vorhabt, viel Spaß, die eine Zeile file_get_contents-PHP-Code muss ich wohl nicht auf Github stellen 🤓


Natürlich ist das nur die halbe Miete. Die Datenbasis musste etwas aufgehübscht werden (z.B. gibt es ca. 25 verschiedene Zutaten namens “Salz”), und natürlich brauchte ich ein Interface, das die ganzen Rezepte jetzt anzeigt, ein “Zeig mir zufällig sechs Stück, damit ich drei auswählen kann”-Feature und, das allerwichtigste: Einen Einkaufslisten-Generator, der automatisch alles zusammenfasst und mit einem Button-Klick alles in die “Supermarkt”-Liste in Todist schickt.

Tja, und wie das alles aussieht, zeige ich euch beim nächsten Mal, denn statt den Todoist-OAuth zu implementieren, schrieb ich gerade diesen Post!

Tatsächlich hat happybrush einen sehr guten Supportprozess. Noch bevor man seine kaputte Bürste eingesendet hat, hat man einen Gutschein um sich eine neue bestellen zu können, die auch schnell ankommt. Ich bin gespannt, wie lang die nun hält – die Tatsache, dass der Prozess existiert und so schnell ist, deutet ja auch darauf hin, dass das Problem ziemlich häufig auftritt…