Der Tip von Daniel mit der Limit-Variable ist gut. Wir selbst legen uns auch immer so eine Limit Flow-Variable an, mit der wir das steuern können und beim Flow entwickeln ist diese immer so klein wie möglich.
Am Ende des Tages ist die Grundregel: Je weniger Daten, desto schneller.
Auch die Idee von Daniel mit Debug/Edit Mode ist gut. Wir hatten auch intern schon grob solche Überlegungen. Problem war aber oft, wenn man viel mit SpreadsheetFiltern arbeitet: Da kann es dann zu dem Fall kommen, dass durch das kleine Limit bestimmte Datensätze gar nicht erst kommen, die man aber gern zum Test seines Filters braucht.
Wir hatten intern mal die Idee, dass man sich für so einen Edit-Mode irgendwie ein festes Set an Testdaten anlegen kann. Wir hatten intern immer von "freeze" gesprochen. D.h. man kann an irgendeiner Stelle die Test-Daten "einfrieren" indem man sagt: "das sind die Daten mit denen ich jetzt testen und den Flow bauen will". Und diese Daten werden dann in einen Cache gepackt und sind immer schnell verfügbar. Aktuell werden die Daten quasi immer live geholt und das dauert natürlich, je nach API-Call und Datenmenge.
Ein anderes Thema sind Flows die (zu) viele Dinge auf einmal machen. Also quasi mehrere Use-Cases in einem Flow abhandeln. Da wird es schwieriger. Unsere Denke ist immer, dass ein Flow genau eine Sache machen sollte. D.h. im Zweifel eine Quelle, ein Ziel und dazwischen passieren Dinge - fertig.
Baut man nun größere Flows, wo mehrere Quellen und mehrere Ziele verwendet werden kommt man zu dem Problem von Herrn Podolsky, dass bei Mappern am Ende des Flows Steps davor ausgeführt werden, die nicht unbedingt notwendig sind.
Die Frage wäre, ob man auch diese Problem mit dem obigen "Test Daten-Freeze" lösen könnte...
Es wäre schön, wenn wir dieses Problem hier gern noch etwas weiter brainstormen könnten. Vielleicht kommen wir ja so zu einem besseren Konzept.
