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: 👉 https://docs.serverpod.dev/concepts/scheduling#configuration

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?