The cloud-native orchestrator for the whole development lifecycle, with integrated lineage and observability.

dagster

when would i use @graph to chain ops versus @job? it seems like they accomplish the same thing?

a graph is one step lower than a job -- you can think of as a graph as a "super-op", while a job is a sort of "instantiated graph". For example, we have several graphs that take in some configuration and do an ETL process. Each table is created via a job that instantiates this one graph under different settings

so the graph might be able to take parameters while the job wouldn't?

job can still take some config, but a graph isn't invokable -- it is _just_ a definition

here's an example
```@op(config_schema={"website": str})
def make_request(context):
    response = requests.get(context.op_config["website"]
    return response.json()

@op
def print_result(response_json):
    print(json.dumps(response_json)

@graph
def my_cool_graph():
    response = make_request()
    print_result(response)

instantiated = my_cool_graph.to_job(name="my_cool_job", config={"ops": {"make_request": {"config": {"website": "<http://www.google.com|www.google.com>"}}}})```

i like using graphs because then you can basically just loop through a list of settings and generate a set of jobs or assets dynamically from, .e.g. a YAML file with config

no, but if you define a job, you will also get a graph under the hood

Yep—Stephen provided a good use case. Another reason is that you want to switch resources depending on environment, in which case you'd create a graph and then bind the graph to resources depending on the executing environment.