Durchlauferhitzer PHP

Im kleinen Häuschen, in welchem mein Vater lebte, war im letzten Herbst der Boiler ausgestiegen. Grundsätzlich bin ich ein Fan von kaltem Wasser beim Duschen – aber meinem 74jährigen Vater wollte ich das nicht zumuten.

Somit war klar: ein neuer Boiler musste her. Oder doch ein Durchlauferhitzer?

Während ich im Baumarkt vor den Regalen mit den entsprechenden Geräten stand, kam mir plötzlich PHP und meine «Philosophie für WebApplikationen» in den Sinn.

Warum? Das erzähle ich Ihnen gern!

Wie eine WebApplikation grundsätzlich funktioniert

Die Client-Applikation ist jenes Ding, dass der User im Browser öffnet. Zum Beispiel eine Sammlung von vielen Buttons (HTML) in diversen Farben (CSS), welche auf Anklicken mit der Maus reagieren (JavaScript).

Will diese Client-Applikation irgendwelche Daten erhalten, fragt sie das API (= Applikation Programming Interface) mit Hilfe eines Requests an. Das API liest dann die Daten aus der Datenbank und liefert sie mittels eines Response zurück.

Im Badezimmer meines Vaters wäre die Client-Applikation der Wasserhahn. Er ermöglicht es mir, zu wählen, ob ich warmes oder kaltes Wasser haben möchte.

In einem Boiler würde (auf Vorrat) warmes Wasser produziert und – wie die Daten in einer Datenbank – gespeichert. Bei Bedarf – sozusagen als Response – kann das warme Wasser dann geliefert werden.

Will die Client-Applikation Daten in die Datenbank schreiben, läuft es ähnlich ab: Sie sendet die Daten an das API, welches die Daten dann in die Datenbank schreibt und als Response ein freundliches «OK, hat geklappt!» oder ein «Leider nein!» an die Client-Applikation zurückschickt.

Diese Richtung in Badezimmern nachzustellen hat sich als eher weniger geeignet herausgestellt. Glauben Sie mir!

Diese stark vereinfachte Darstellung der Grund-Arbeitsweise einer Web-Applikation reicht aus, um die folgenden drei Überlegungen zu erläutern und daraus drei Konzepte für Web-Applikationen abzuleiten.

Ein Paradebeispiel

Bevor wir uns aber um die Überlegungen im Speziellen kümmern, zuerst das Set-Up: Unsere Web-Applikation soll nichts anderes machen, als eine Liste von bereits in der Datenbank erfassten Schachfiguren anzeigen. Der Benutzer soll diese dann nach Farbe (weiss oder schwarz) filtern können. That’s it…

Überlegung 1: Was ist die Aufgabe der Client-Applikation?

Wie beim Wasserhahn im Badezimmer bietet die Client-Applikation das Interface für den Benutzer. Der Wasserhahn fragt: «Hätten Sie gern warmes oder kaltes Wasser?». Die Applikation fragt: «Hätten Sie gern die schwarzen oder die weissen Figuren angezeigt?»

Würde man in einem Badezimmer – nicht dass ich das jemals gemacht hätte! – den Wasserhahn abschrauben, ohne vorher die Hauptwasserleitung abzustellen, würde man feststellen, dass das warme und das kalte Wasser eigentlich bereits «da» sind, also schon im Wasserhahn drin sind. Die Leitung steht ja. Klar, manchmal kühlt es sich (in der Leitung) ab und es dauert ein wenig, bis neues nachgeflossen ist, aber es ist (grundsätzlich) schon da.

Für eine Web-Applikation beispielsweise könnte man daraus die Überlegung ableiten, auch die (wahrscheinlich) benötigten Daten schon mal auf Vorrat zu liefern und das Filtern dem Client zu überlassen.

Also statt …

1. Client will die weissen Figuren sehen
2. weisse Figuren beim API anfragen
3. auf Antwort warten
4. weisse Figuren anzeigen
5. Client will die schwarzen Figuren sehen
6. schwarze Figuren beim API anfragen
7. auf Antwort warten
8. schwarze Figuren anzeigen
9. etc.
10. etc.

lieber …

1. Gesamte Liste beim API anfragen
2. auf Antwort warten
3. Liste anzeigen und
4. gemäss Filter-Wünschen einzelne Zeilen ein-/ausblenden

Als Konzept könnte man also festhalten:

Was immer die Client-Applikation erledigen kann, soll die Client-Applikation erledigen.

State-of-the-Art Frameworks wie Angular sind hierfür prädestiniert und erledigen solche Aufgaben beinahe von selbst. In Angular-Kursen gibt es jeweils ein (erstes) erstauntes «Ohhh…!» aus dem Munde der Teilnehmenden, wenn ich das Out-Of-The-Box-Filtern von Listen zeige.

Überlegung 2: Was ist die Aufgabe der Datenbank?

Als ich ca. 1998 meine erste Web-Applikation geschrieben habe, war ich froh, dass es überhaupt möglich war, Daten in einer Datenbank zu speichern.

Heute weiss ich, dass Datenbanksysteme wie z.B. MariaDB weit mehr als nur ein Datenspeicher sind. Mittlerweile weiss ich, wie man in einem Datenbanksystem beinahe besser und effizienter programmieren kann, als mit mancher Nicht-Datenbank-Programmiersprache.

Um Ihnen einen kleinen Geschmack zu geben, hier meine drei Highlights in MariaDB:

• Sichten: Schreiben Sie in eine Tabelle alle Ihre Kunden und in eine andere alle Bestellungen dieser Kunden inkl. der Kundennummer des Bestellers. Mit Hilfe einer View können Sie die beiden Tabellen zu einer Sicht (=View) zusammenführen, die sich nach aussen «anfühlt», als ob es eine eigenständige Tabelle wäre.
• Gespeicherte Prozeduren: Möchten Sie jedem Ihrer Kunden einen speziell berechneten Rabatt gewähren? Ist die Berechnung dieses Rabattes etwas aufwändiger? Für eine Stored Procedure – die «Funktionen» der Datenbanksysteme – kein Problem!
• Generierte Spalten: Haben Sie die Vornamen Ihrer Kunden erfasst? Und auch die Nachnamen? Wie wäre es, wenn sie automatisch eine zusätzliche Spalte generieren lassen könnten, in der Nachname und Vorname automatisch zusammen, schön mit einem Komma und einem Abstand getrennt, abrufbar sind? Für «Generated Columns» ein Klax.

Dieses drei Beispiele geben Ihnen vielleicht schon eine Idee davon, was ich hier als Konzept formuliere:

Was immer die Datenbank erledigen kann, soll die Datenbank erledigen.

Überlegung 3: OK… und wozu dann noch PHP?

Als kleine Zusammenfassung:

• Sie brauchen in serverseitigen Programmiersprachen wie PHP eigentlich…
• … keine Filterungen durchzuführen, da dies locker von Client-Side-Systemen wie Angular übernommen werden kann;
• … keine Daten aus unterschiedlichen Tabellen zusammenzuführen, da eine View das viel effizienter erledigt;
• … keine Berechnungen mit Daten anzustellen, da dies gern auch von einer Stored Procedure übernommen werden kann;
• … keine Werte zusammenzufügen, da eine generierte Spalte das schon auf Datenbank-Ebene tun kann.

Als Konzept zusammengefasst:

PHP soll so wenig wie möglich und so viel wie nötig erledigen.

Wenn Sie sich jetzt fragen: «Wozu dann noch PHP, wenn ich alles in Angular oder MariaDB erledigen kann?» dann gilt es daran zu denken, dass Sie eben doch nicht alles auf Ebene Client-Applikation oder Datenbank erledigen können!

Um den Rahmen dieses Artikels nicht zu sprengen, erwähne ich hier lediglich Stichworte wie «Authentifizierung/Authorisierung», «SQL-Injection» oder das «Concurrency-Problem», welche ich gern mal in anderen Blogbeiträgen näher erläutere.

Bis dahin schon mal viel Erfolg bei der Umsetzung der oben erwähnten Konzepte!

P.S: Allen die sich jetzt denken: «Eins hat er vergessen! Die Daten muss ich immer noch mittels PHP in JSON umwandeln, damit sie von Angular elegant konsumiert werden können!» empfehle ich einen Blick hierauf zu werfen. 😉