dg and Dagster Components for Beginners?

[EndreSzakal]

Hi!

I am trying to learn Dagster so that I can create/manage unstructured data pipelines for my company's RAG/LLM application. I'm a beginner to Dagster and still trying to wrap my head around the documentation and concepts.

I would like to manage my project with uv, so I stumbled across dg and the Dagster Components part of the documentation. As a Dagster Beginner, should I focus on learning and creating my project with dg and Components since that seems where Dagster is heading? Or, should I just follow how most of the documentation tutorials/sample projects manage their Dagster projects?

My worry is that because I don't know Dagster well yet, I'll get confused by the differences in the established documentation and the newer Components documentation. Thanks!

[EndreSzakal]

Was answered in the Dagster Community Slack: Thread Link

"""
Zach
Friday at 3:15 PM

I would say you should probably try to adopt dg from the start, but don't necessarily get bogged down in components. They are two complementary but independent concepts / components. Components are also meant to be complimentary to the rest of Dagster's abstractions, just a way to put the creation of Dagster definitions behind a YAML interface that allows more standardized creation of well-defined / standardized assets / jobs.

The use case for components will become more clear as you become familiarized with the rest of Dagster's abstractions, particularly once you come across factory patterns (as described here).
dg will become the strong preference for how you set up and manage your projects very soon. It provides lots of guardrails and makes a lot of decisions for you about how to organize things that are meant to take cognitive load off the developer, so it makes sense to me to try to adopt it as early as possible. It will also set you up to be able to adopt components when you're ready to.
Just my opinion though
"""

[schrockn]

Also from this thread from me (@schrockn )

Some additional context here:

• When 1.11 is released at the end of June, dg and Components will be considered in release candidate status. The RC label (rather than GA) is mostly because of some gaps (we want additional integrations and more plus support, for example) rather than stability or commitment to API contracts.
• With that release, all the docs will be fully integrated into main docs site.
• The tutorial will use dg and the new project layout.
• Components will be recommended for use for MDS integrations (e.g. dbt) as well as anyone who wants to present their users with a YAML DSL.
• Any work you do will not be lost. Components is a layer on top of assets code, rather than a replacement. And reorganizing (which is opt-in) a small project should be very straightforward (a few file moves and a satisfying deletion of import statements).
  Thanks!