I'd like to use dagster to run user triggered jobs via our API. What would be a recommended pattern for this? I was imagining that our API would trigger a job via the dagster GraphQL API. That job would take input parameters via the

run_config

. Those parameters would include things like the user account the job is for and basic inputs. I'd like to store the result of those jobs in files in cloud bucket storage (same as we do with our assets). I'm wondering if the jobs themselves should be yielding AssetMaterializations with dynamic asset keys, or if we should not use assets and handle the I/O directly. It would also be nice to use the input parameters such as requesting user account id against concurrency limits. I think this can be done by adding tags at runtime, does that sound right?

Hi Alec. I can answer part of your question--yep, I would recommend launching user-triggered jobs through the GraphQL API. With regards to yielding asset materializations for a dynamic asset key, I would recommend doing that within an

@op

and yielding an

AssetMaterialization

object.

@asset

objects are meant to deterministically output a materialization for the given asset, so using the `@op`/`AssetMaterialization` approach is likely much more straightforward. If you wanted to dynamically specify an asset key to materialize with an

@asset

, you'd have to dynamically generate an

@asset

and provide a name for the asset upon job run.

Thanks for the feedback! Would it be more appropriate to skip the notion of asset materialization? I'd like to take advantage of our io manager, storing the artifacts in

run_id

which I believe is somehow default behavior with `@op`s?

That seems reasonable too! It depends on if you want to have asset materializations--i.e. your runs are generating persistent artifacts that you want to track by asset