| Looks like a great side project, congrats on launching. My basic feedback is that you should set expectations on the project page by answering the following questions: - Why would someone use this instead of Airflow/Cadence/Temporal/Databuilderframework? - What does this look like when it's used? Most frameworks provide some kind of example project, you should too. - Related, but more specifically, what does the `IDataStore` interface contract mean? Beyond the two functions that I have to implement, are there any considerations related to the overall performance/scalability/durability of the system? Would it make sense to use a disk-backed store, or Redis, or Postgres? - How do I observe the system? Which workflows are running, which have failed, what the current state is, etc. Are there metrics? Logs? All of this is based on the assumption you want people to adopt this framework. If it's just a cool side project, that's fine too, but you should probably try to set that expectation in the README. |
I've noted all of these and I'll modify the README to include them. Thank you for taking the time to go through in such detail :)
Given that the current state of a workflow:
- is inherently invisible
- all we can really check in the DB is if, for a workflow, the available data contains the target data;
how would I address observability concerns?
This is a function of a lack of workflow states due to the lower levels of abstraction it operates on. User defined workflow states would do the trick, but I suppose that would take writing some more code after integrating the framework.