Hi, I have an operation where I make an API call after some assets have been materialised. This operation has an input from an upstream asset (a parameter that is passed when making the API call). I'm not sure how to model this operation: is it an asset although nothing gets materialised? Is it a job or some graph? It's very convenient to use an asset but making an API call – although I keep metadata – does not fit my current understanding of what an asset is supposed to be. What are your thought? What's the idiomatic approach for a Dagster project?

If it makes you feel better, you can always materialise a record that you called the API.

Maybe an asset sensor that triggers a basic op-job? Is the parameter you need from the upstream asset the value of the asset itself? Honestly I wouldn't worry about modeling it as an asset either though, if there aren't any downstream dependencies then it doesn't really matter whether or not the asset stores something. There are usually more pressing problems

The value of the upstream value is a parameter I use to call the API:

@asset(
    ins={"max_value_in_a_dbt_table_asset": AssetIn(...)}
)
def api_asset(context, max_value_in_a_dbt_table_asset: int) -> None:
    response = <http://requests.post|requests.post>(f"my-service.svc.local?max_value={max_value_in_a_dbt_table_asset}")
    if response.ok:
        ...
    else:
        ...
        response.raise_for_status()

Thanks for your suggestions and thoughts. I think I'll just leave this as an asset then.