Das Webframework IHP liegt in Version 1.5.0 vor. Es handelt sich um das bisher größte Release des Open-Source-Projekts mit 1.051 Commits. Die Entwickler haben die gesamte Datenbankschicht neu geschrieben, die Performance an vielen Stellen verbessert und die Architektur modularisiert.

IHP (Integrated Haskell Platform) ist ein Webframework, das viele für Webanwendungen typische Funktionen bereits ab Werk mitbringt. Es kombiniert die funktionale Programmiersprache Haskell mit dem Paketmanager Nix. Nix sorgt dabei für reproduzierbare Entwicklungsumgebungen. Das Framework richtet sich an Entwickler und Teams, die Webanwendungen mit hoher Typsicherheit und möglichst wenigen Laufzeitfehlern bauen wollen. IHP liefert dafür alle nötigen Werkzeuge mit – vom Prototyping bis zur Produktion.

Neue Datenbankschicht halbiert Latenzen

Die größte Änderung in Version 1.5.0 betrifft den Datenbankzugriff. IHP wechselt vom älteren Treiber postgresql-simple auf hasql. Dieser aktuellere Treiber nutzt das binäre Protokoll von PostgreSQL und arbeitet mit vorbereiteten Anweisungen (Prepared Statements). In Produktionsumgebungen sinkt die Latenz bei Datenbankabfragen dadurch um bis zu 50 Prozent. Die bestehende Query-Builder-API bleibt unverändert – vorhandener Code funktioniert ohne Anpassungen weiter. Nur wer bisher direkt auf postgresql-simple zugegriffen hat, muss migrieren.

Darüber hinaus haben die IHP-Entwickler auch andere Teile des Frameworks beschleunigt. Laut Release Notes belegt der integrierte Entwicklungsserver – er basiert auf GHCi, der interaktiven Umgebung des Haskell-Compilers – jetzt nur noch 500 bis 800 MByte Arbeitsspeicher statt zuvor 4 GByte. Ferner soll die Session-Middleware bei Routen, die nicht auf die Session zugreifen, dreimal schneller arbeiten. Die URL-Generierung soll nach dem Update fünfmal schneller und die Render-Pipeline doppelt so schnell wie in der Vorgängerversion sein.

Das neue Paket ihp-typed-sql führt einen sogenannten Quasiquoter ein – ein Haskell-Mechanismus, der SQL-Syntax direkt im Code erlaubt. Das Besondere: Der Compiler verbindet sich während des Übersetzungsvorgangs mit der Entwicklungsdatenbank und prüft, ob Tabellen, Spalten und Datentypen korrekt sind. Er erkennt auch, welche Spalten durch LEFT JOIN Null-Werte annehmen können. Fehlerhafte SQL-Abfragen fallen so bereits beim Build auf, nicht erst zur Laufzeit.

Pipeline-Modus bündelt Datenbankabfragen

Mit der neuen Funktion fetchPipelined können Entwickler mehrere unabhängige Datenbankabfragen in einem einzigen Netzwerk-Roundtrip an PostgreSQL senden. Statt jede Abfrage einzeln abzuschicken und auf die Antwort zu warten, schickt IHP alle Abfragen direkt hintereinander. Die Datenbank verarbeitet sie und liefert die Ergebnisse gebündelt zurück. Das reduziert die Netzwerklatenz spürbar.

IHP ist mit dieser Version weniger monolithisch aufgebaut. Die Entwickler haben über 15 Module – darunter ihp-mail, ihp-datasync und ihp-schema-compiler – als eigenständige Pakete auf Hackage veröffentlicht, dem zentralen Paket-Repository für Haskell (vergleichbar mit npm für JavaScript oder PyPI für Python). Andere Haskell-Projekte können diese Bibliotheken damit nutzen, ohne das gesamte Framework einzubinden. Bestehende IHP-Projekte sind nicht betroffen: Die Module werden weiterhin aus dem Hauptpaket re-exportiert.

Weitere Neuerungen und nötige Anpassungen

Darüber hinaus bringt Version 1.5.0 unter anderem Custom Routes für individuelle URLs neben dem automatischen Routing, Unterstützung für zusammengesetzte Primärschlüssel (Composite Primary Keys) und einen Integrationstestmodus mit automatisch erzeugter temporärer PostgreSQL-Datenbank. Als Standard-Compiler dient nun GHC 9.10, experimentell unterstützt IHP auch GHC 9.12.

Da der Wechsel der Datenbankschicht und die Modularisierung einige inkompatible Änderungen (Breaking Changes) mit sich bringen, stellt das Entwicklerteam einen Upgrade-Guide mit Schritt-für-Schritt-Anleitung bereit. Alle Informationen finden sich in den Release Notes auf GitHub.

(fo)

Apple gibt Entwicklern, die ihre Apps über den App Store vertreiben, ab sofort mehr Zahlen an die Hand. Der iPhone-Hersteller löst damit ein Versprechen der letztjährigen Entwicklerkonferenz WWDC ein. Es ist das größte Update des Analytics-Bereichs seit dem Start des Entwicklerportals App Store Connect. Und es zielt vor allem auf Entwickler ab, die In-App-Käufe und Abonnements über Apples Zahlungssystem anbieten.

Daten zu Conversion, Marketing und Revenue ließen sich nirgendwo sonst datenschutzkonform zusammenführen, lobt Andy Weekes, Entwickler der App Night Sky. Für ihn seien die Analytics-Daten eine Art Gesundheitscheck für sein Unternehmen. Er brauche verlässliche Daten, um zu verstehen, wie es um seine Einnahmen stehe.

Über 100 neue Metriken

Die über 100 neuen Metriken erlauben unter anderem eine sogenannte Kohorten-Analyse. Damit lassen sich Gruppen von Nutzern, die zum Beispiel in einem bestimmten Monat eine App heruntergeladen haben, miteinander vergleichen. Entwickler können damit etwa untersuchen, nach wie vielen Tagen die jeweiligen Nutzergruppen ein Abo abgeschlossen haben. Auf diese Weise lässt sich der Erfolg von Aktionen oder Veränderungen in der App messen.

Entwickler können sich auch neue Peer-Benchmarks anzeigen lassen. Diese zeigen ihnen, wie ihre App im Vergleich zu ähnlichen Apps abschneidet – ohne dass dabei sensible Daten anderer Entwickler offengelegt werden. Damit lässt sich auswerten, wie viele Nutzer, die eine App herunterladen, zu zahlenden Kunden werden (Download-to-Paid-Conversion) und wie viel Umsatz eine App im Schnitt pro Download erzielt (Proceeds per Download).

Für Entwickler ohne Aufpreis

Das klingt für den Laien alles recht kompliziert. Doch Apple habe das Ganze so aufbereitet, dass es auch jemand ohne betriebswirtschaftlichen Hintergrund verstehe, sagt Frederik Riedel, Entwickler der App One Sec aus Berlin, der in der Vergangenheit am App Store Foundation Program teilnahm. Auch Bastien Cazenave, Mitherausgeber des Spiels Sorcery School, der wie die anderen beiden Entwickler die neuen Analytics vorher kurz ausprobieren konnte, zeigt sich erfreut: Es sei eine ganz neue Detailebene, die sich Entwicklern da erschließe. Und obendrein seien die Analysedaten noch kostenlos.

So ganz uneigennützig dürfte Apples Engagement freilich nicht sein. Regulatoren in verschiedenen Ländern drängen Apple seit Jahren dazu, sein geschlossenes System auch für externe Anbieter zu öffnen, die Zahlungen und Abos abwickeln. Neben dem Datenschutzversprechen für die Nutzer kommt jetzt durch die erweiterten Analytics ein zusätzlicher Mehrwert für die Entwickler dazu, mit denen Apple seinen Plattform-Vorteil weiter ausbaut. Einige Entwickler dürften bislang auf externe kostenpflichtige Anbieter zurückgegriffen haben.

(mki)

Das Unternehmen Databricks hat mit Lakewatch ein neues SIEM-System (Security Information and Event Management) vorgestellt, das neue Wege in der Sicherheitsüberwachung beschreiten soll. Lakewatch baut auf einer offenen Security-Lakehouse-Architektur auf und setzt sich damit laut Ankündigung von etablierten SIEM-Angeboten ab, die in der Regel Storage und Compute koppeln. KI-Agenten sollen dabei Bedrohungen automatisch erkennen, triagieren und Gegenmaßnahmen einleiten.

Wie Databricks in seinem Blog erläutert, können Unternehmen mit Lakewatch sämtliche Sicherheits-, IT- und Geschäftsdaten in einer einheitlichen Umgebung zusammenführen – einschließlich multimodaler Formate wie Video und Audio im Petabyte-Bereich. Databricks verspricht bis zu 80 Prozent niedrigere Gesamtbetriebskosten im Vergleich zu klassischen SIEM-Systemen. Diese verwerfen Databricks zufolge einen Großteil der eingehenden Telemetriedaten, um die Speicherkosten im Griff behalten zu können. Lakewatch hingegen entkoppele Storage und Compute und behalte alle Daten.

Als offenen Standard für die Datennormalisierung nutzt Lakewatch das Open Cybersecurity Schema Framework (OCSF). Security-Logs sowohl aus strukturierten als auch unstrukturierten Quellen werden damit automatisch in ein einheitliches Schema überführt. Die Datenaufnahme erfolgt über Lakeflow Connect, das Quellen wie AWS oder Okta anbindet. Governance- und Compliance-Anforderungen wie NIS2 oder DORA lassen sich über die feingranularen Zugriffskontrollen des Unity Catalog abdecken.

KI-Agenten statt manueller Workflows

Das Herzstück von Lakewatch bilden agentenbasierte Funktionen: Mit den im vergangenen Jahr vorgestellten Agent Bricks lassen sich benutzerdefinierte Sicherheitsagenten erstellen, die Telemetriedaten in einer Vielzahl von Formaten analysieren. Sie korrelieren Signale, reduzieren Fehlalarme und verkürzen die mittlere Erkennungs- und Reaktionszeit (MTTD/MTTR). Für natürlichsprachliche Abfragen und automatisierte Triage-Workflows integriert Databricks seinen KI-Agenten Genie. Detection-as-Code-Ansätze mit YAML, SQL und Python ermöglichen zudem automatisierte Tests über CI/CD-Pipelines.

Für das Reasoning der Agenten setzt Databricks auf Claude-Modelle von Anthropic. Die beiden Unternehmen haben im Zuge der Lakewatch-Vorstellung ihre Partnerschaft vertieft: Claude 3.7 Sonnet kommt bei der Signalkorrelation und Bedrohungsanalyse zum Einsatz. Anthropic nutzt im Gegenzug die Security-Lakehouse-Infrastruktur von Databricks. Der Ansatz, KI-Agenten als Teams zusammenarbeiten zu lassen, findet sich auch in Anthropics Multi-Agent-Systemen für Code Reviews wieder.

Offenes Ökosystem und Partnernetzwerk

Databricks positioniert Lakewatch bewusst als offenes Ökosystem. Zum Start sind unter anderem Palo Alto Networks, Zscaler, Wiz (Google Cloud), Okta, CrowdStrike-Konkurrent Arctic Wolf, Cribl und Deloitte als Partner an Bord. Hinter der Entwicklung stehen außerdem zwei Übernahmen: Antimatter (sichere Authentifizierung für KI-Agenten) und SiftD.ai, das vom Erfinder der Splunk-Abfragesprache SPL gegründet wurde. Adobe und Dropbox zählen zu den ersten ausgewählten Kunden, die das SIEM-System testen. Lakewatch ist laut Ankündigung ab sofort als Private Preview verfügbar.

(map)