Seite 150 - Mironsoft Blog

Eigene Magento 2 GraphQL Resolver verbinden Schema, Query-Logik und Service-Schicht. Entscheidend sind dabei klare Typen, saubere Resolver-Klassen und eine Architektur, die nicht direkt Business-Logik in den Resolver drückt.

Ein generisches Blue-Green-Deployment tauscht einfach zwei Container-Versionen aus. Bei Magento reicht das nicht, weil Indexer, Cache, Sessions und Datenbank-Migrationen den Farbwechsel verkomplizieren. Dieser Artikel zeigt, wie Blue-Green-Deployments für Magento in Containern so gebaut werden, dass der Traffic-Switch tatsächlich ohne Downtime und ohne inkonsistente Daten funktioniert.

Ein Major-Version-Upgrade einer Kernbibliothek ist selten ein einfacher composer update oder npm install. Claude kann Breaking Changes aus Changelogs extrahieren, betroffene Codestellen im eigenen Projekt identifizieren und einen schrittweisen Migrationsplan erstellen, ersetzt dabei aber keine sorgfältige Verifikation. Dieser Artikel zeigt den praktischen Ablauf und die Grenzen.

Relay erzwingt über einen eigenen Compiler strenge Namenskonventionen, Fragment-Colocation und eine feste Connection-Spezifikation für Pagination. Apollo Client verzichtet auf diesen Zwang und bleibt dadurch flexibler, aber auch weniger vorhersehbar bei wachsender Teamgröße. Dieser Artikel zeigt, wann sich Relays Lernkurve tatsächlich auszahlt.

docker system prune raeumt nur lokal auf, das Wachstum einer eigenen Docker Registry mit Tausenden gepushten Images bleibt davon unberuehrt. Registry-seitige Garbage Collection und durchdachte Retention-Policies sind der eigentliche Hebel gegen ausufernden Speicherverbrauch.

Bis PHP 8.0 musste jeder Default-Wert eine konstante Expression sein, eine neue Objektinstanz als Default war schlicht nicht erlaubt. Seit PHP 8.1 darf new direkt in Initializern stehen, in Parametern, Attribut-Argumenten und Property-Deklarationen, und macht damit einen ganzen Katalog von Umwegen überflüssig.

Klassische Tabellen speichern Daten zeilenweise: Jede Zeile liegt physisch zusammenhängend auf der Platte, was einzelne Datensatz-Zugriffe schnell macht. Analytische Abfragen lesen dagegen oft nur wenige Spalten, dafür aber über Millionen Zeilen hinweg, und müssen bei zeilenbasierter Speicherung trotzdem jede komplette Zeile von der Platte holen. Columnstore-Indizes drehen das Speichermodell um, legen Werte spaltenweise ab und erreichen dadurch bei Aggregationen über große Datenmengen einen Geschwindigkeitsgewinn, der mit klassischen B-Baum-Indizes kaum erreichbar ist.

Die Storage Manager API beantwortet zwei Fragen, die jede Offline-Anwendung früher oder später betreffen: wie viel Speicherplatz steht dem Origin überhaupt zur Verfügung, und wie verhindert man, dass der Browser diese Daten unter Speicherdruck einfach löscht. Wer Quota-Berechnung und Persistenz-Anfragen richtig einsetzt, baut Anwendungen, die Datenverlust proaktiv vermeiden statt ihn nachträglich zu erklären.

Der Kernel schreibt jede wichtige Meldung, von der Hardware-Erkennung beim Boot bis zum OOM-Killer im laufenden Betrieb, in einen internen Ringpuffer, den dmesg auslesbar macht. Wer die Kernel-Log-Analyse mit dmesg beherrscht, findet Treiberfehler, Speicherprobleme und Hardwaredefekte oft Minuten bevor sie sich in einem Anwendungsausfall zeigen, statt erst danach im Nachhinein zu suchen.

Wer versucht, alle Buckets eines hochkardinalitären Feldes über eine Terms Aggregation mit riesigem size-Wert zu exportieren, stößt unweigerlich an Speichergrenzen. Die Composite Aggregation löst dieses Problem mit einem after_key-Cursor, der Seite für Seite durch beliebig viele Buckets iteriert, ohne jemals mehr als eine Seite gleichzeitig im Speicher zu halten. Dieser Beitrag zeigt, wie sich vollständige Exporte, Reports und Data-Pipeline-Iterationen mit der Composite Aggregation robust und speicherschonend umsetzen lassen.