Manchmal sind es die kleinsten Ergänzungen, die die größten Verbesserungen freischalten.
Das Problem
Bis jetzt wurden FutureCalls in Serverpod sequenziell ausgeführt. Das funktionierte – aber es bedeutete auch: Wenn ein Job lange dauerte, mussten alle anderen warten.
Die Lösung
Ich habe gerade einen kleinen aber kraftvollen Change zum Serverpod-Paket beigetragen: Du kannst jetzt konfigurieren
✅ wie oft die Datenbank nach neuen Aufrufen gescannt wird ✅ wie viele Aufrufe parallel verarbeitet werden
Kurz: FutureCalls sind kein Engpass mehr. Du bekommst volle Kontrolle über das Planungsverhalten und die Serverlast.
Das Wie
Die Konfiguration ist einfach und flexibel – und offiziell dokumentiert: Serverpod-Dokumentation
Das Warum
Ich bin darauf selbst beim Bau einer feature-reichen App gestoßen. Statt den Engpass zu umgehen, habe ich beschlossen, ihn zu beheben – und zu teilen. Open Source, wie es gemeint ist.
Neugierig, wie du FutureCalls in deinen Projekten verwendest. Irgendwelche Patterns oder Use Cases, die es wert sind, geteilt zu werden?