UI and API Contributions for Airflow 3.0

[Brent Bovenzi <br...@astronomer.io.INVALID>]

Hi all,

As part of AIPs 38, 79 and 84, Pierre and I have started a new API based on
FastAPI and a new UI based purely off of React. The current UI, rest API
and webserver endpoints will now be considered "legacy" and will be
completely removed by the time Airflow 3.0 is released. But there will be a
transition time while we get both new projects feature-complete.

This means that sometimes we will still have to accept changes to the
`airflow/www` javascript files, `airflow/www/views.py` webserver endpoints
and `airflow/api_connexion` rest API endpoints. But we want to limit
contributions to "legacy" code which will be deleted in a few short
months. Which
is specified here in the Airflow docs.
<https://github.com/apache/airflow/pull/41903>

1. Bug fixes to cherry pick for 2.10.x and 2.11
2. The minimum necessary to unblock other Airflow 3.0 feature work
3. Fixes to views and endpoints which we haven't migrated over yet, but can
still be ported over to the new UI

For example, we will not migrate the legacy UI to use the new REST API.
This means that, for a time, we will have duplicate code (ex: two different
grid_data endpoints). But this reduces the surface area that we must
maintain and allows us to redesign views and endpoints when necessary (ex:
making the grid_data more efficient and to better support DAG versioning).

We see three phases to migrating to the UI:
1. New UI has very few features. Show a dismissible banner to "Check out
the new UI"
2. New UI has most of the core features of Airflow. Make the new UI the
default, and link to the legacy UI as an escape hatch. What is sufficient
for "core features" is to be determined.
3. New UI is fully feature-complete, delete the entire legacy UI project.

Let me know what you all think. I am happy to discuss more on the dev call
tomorrow.

- Brent

Re: UI and API Contributions for Airflow 3.0

[Pierre Jeambrun <pi...@gmail.com>]

Impressive!

Thanks Jarek.

On Thu, Sep 5, 2024 at 3:26 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Created an issue in CI/CD project describing what would need to be done to
> have CI/CD automation in place for it:
> https://github.com/apache/airflow/issues/42031 - should be very easy.
>
> On Thu, Sep 5, 2024 at 2:46 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Labels are cool Indeed.
> >
> > Automated test is not too difficult either. Breeze selective check has
> all
> > that is needed to figure out the scope of the change in the PR ->
> >
> https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L183
> > and we can produce the right outputs so that they can be used directly in
> > the actions.
> >
> > It's about 15 lines of code to add :). Might be one of the good first
> > issues to tackle by the newly formed CI/CD team.
> >
> > J.
> >
> > On Thu, Sep 5, 2024 at 2:13 PM Pierre Jeambrun <pi...@gmail.com>
> > wrote:
> >
> >> Thanks Brent.
> >>
> >> Yes I like the idea of labels, I believe this will help reviewers know
> >> that
> >> they have to pay extra attention because specific rules apply to
> updating
> >> the legacy-ui/api during airflow 3 development.
> >>
> >> An automated test is even better but might be more effort to develop.
> >>
> >> On Wed, Sep 4, 2024 at 10:34 PM Buğra Öztürk <oz...@gmail.com>
> >> wrote:
> >>
> >> > Thanks for preparing! I think making this distinction between legacy
> and
> >> > new UI is beneficial for us. It will make it easy to break and change
> >> > things. The plan looks great!
> >> >
> >> > Great point Jarek. Even though it's not critical, I think it would be
> >> > beneficial for everyone to see the PR editing the legacy code pieces.
> >> > Maybe, we can include a set of labels (like legacy-ui, legacy-api or
> >> > some-label...) by using boring-cyborg powers to auto-label certain
> >> legacy
> >> > code pieces.
> >> >
> >> > On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >> >
> >> > > I like the plan in its entirety.
> >> > >
> >> > > Some technicalities - likely we do not want to automate what is / is
> >> not
> >> > > allowed - managing it might be difficult, but we could as well add
> >> some
> >> > > separate non-critical / failing test that will "fail" when the "old"
> >> area
> >> > > is touched in the PR (but it could be very clearly "just failing
> >> because
> >> > it
> >> > > might not be good to make this.change" - however we could either
> set a
> >> > > special label on such PRs (to avoid the error) or just merge it with
> >> > "red"
> >> > > status.
> >> > >
> >> > > Not critical though. It could also be based on reviews.
> >> > >
> >> > > J.
> >> > >
> >> > > On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi
> >> <brent@astronomer.io.invalid
> >> > >
> >> > > wrote:
> >> > >
> >> > > > Hi all,
> >> > > >
> >> > > > As part of AIPs 38, 79 and 84, Pierre and I have started a new API
> >> > based
> >> > > on
> >> > > > FastAPI and a new UI based purely off of React. The current UI,
> rest
> >> > API
> >> > > > and webserver endpoints will now be considered "legacy" and will
> be
> >> > > > completely removed by the time Airflow 3.0 is released. But there
> >> will
> >> > > be a
> >> > > > transition time while we get both new projects feature-complete.
> >> > > >
> >> > > > This means that sometimes we will still have to accept changes to
> >> the
> >> > > > `airflow/www` javascript files, `airflow/www/views.py` webserver
> >> > > endpoints
> >> > > > and `airflow/api_connexion` rest API endpoints. But we want to
> limit
> >> > > > contributions to "legacy" code which will be deleted in a few
> short
> >> > > > months. Which
> >> > > > is specified here in the Airflow docs.
> >> > > > <https://github.com/apache/airflow/pull/41903>
> >> > > >
> >> > > > 1. Bug fixes to cherry pick for 2.10.x and 2.11
> >> > > > 2. The minimum necessary to unblock other Airflow 3.0 feature work
> >> > > > 3. Fixes to views and endpoints which we haven't migrated over
> yet,
> >> but
> >> > > can
> >> > > > still be ported over to the new UI
> >> > > >
> >> > > > For example, we will not migrate the legacy UI to use the new REST
> >> API.
> >> > > > This means that, for a time, we will have duplicate code (ex: two
> >> > > different
> >> > > > grid_data endpoints). But this reduces the surface area that we
> must
> >> > > > maintain and allows us to redesign views and endpoints when
> >> necessary
> >> > > (ex:
> >> > > > making the grid_data more efficient and to better support DAG
> >> > > versioning).
> >> > > >
> >> > > > We see three phases to migrating to the UI:
> >> > > > 1. New UI has very few features. Show a dismissible banner to
> "Check
> >> > out
> >> > > > the new UI"
> >> > > > 2. New UI has most of the core features of Airflow. Make the new
> UI
> >> the
> >> > > > default, and link to the legacy UI as an escape hatch. What is
> >> > sufficient
> >> > > > for "core features" is to be determined.
> >> > > > 3. New UI is fully feature-complete, delete the entire legacy UI
> >> > project.
> >> > > >
> >> > > > Let me know what you all think. I am happy to discuss more on the
> >> dev
> >> > > call
> >> > > > tomorrow.
> >> > > >
> >> > > > - Brent
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Bugra Ozturk
> >> >
> >>
> >
>

Re: UI and API Contributions for Airflow 3.0

[Jarek Potiuk <ja...@potiuk.com>]

Created an issue in CI/CD project describing what would need to be done to
have CI/CD automation in place for it:
https://github.com/apache/airflow/issues/42031 - should be very easy.

On Thu, Sep 5, 2024 at 2:46 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Labels are cool Indeed.
>
> Automated test is not too difficult either. Breeze selective check has all
> that is needed to figure out the scope of the change in the PR ->
> https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L183
> and we can produce the right outputs so that they can be used directly in
> the actions.
>
> It's about 15 lines of code to add :). Might be one of the good first
> issues to tackle by the newly formed CI/CD team.
>
> J.
>
> On Thu, Sep 5, 2024 at 2:13 PM Pierre Jeambrun <pi...@gmail.com>
> wrote:
>
>> Thanks Brent.
>>
>> Yes I like the idea of labels, I believe this will help reviewers know
>> that
>> they have to pay extra attention because specific rules apply to updating
>> the legacy-ui/api during airflow 3 development.
>>
>> An automated test is even better but might be more effort to develop.
>>
>> On Wed, Sep 4, 2024 at 10:34 PM Buğra Öztürk <oz...@gmail.com>
>> wrote:
>>
>> > Thanks for preparing! I think making this distinction between legacy and
>> > new UI is beneficial for us. It will make it easy to break and change
>> > things. The plan looks great!
>> >
>> > Great point Jarek. Even though it's not critical, I think it would be
>> > beneficial for everyone to see the PR editing the legacy code pieces.
>> > Maybe, we can include a set of labels (like legacy-ui, legacy-api or
>> > some-label...) by using boring-cyborg powers to auto-label certain
>> legacy
>> > code pieces.
>> >
>> > On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>> >
>> > > I like the plan in its entirety.
>> > >
>> > > Some technicalities - likely we do not want to automate what is / is
>> not
>> > > allowed - managing it might be difficult, but we could as well add
>> some
>> > > separate non-critical / failing test that will "fail" when the "old"
>> area
>> > > is touched in the PR (but it could be very clearly "just failing
>> because
>> > it
>> > > might not be good to make this.change" - however we could either set a
>> > > special label on such PRs (to avoid the error) or just merge it with
>> > "red"
>> > > status.
>> > >
>> > > Not critical though. It could also be based on reviews.
>> > >
>> > > J.
>> > >
>> > > On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi
>> <brent@astronomer.io.invalid
>> > >
>> > > wrote:
>> > >
>> > > > Hi all,
>> > > >
>> > > > As part of AIPs 38, 79 and 84, Pierre and I have started a new API
>> > based
>> > > on
>> > > > FastAPI and a new UI based purely off of React. The current UI, rest
>> > API
>> > > > and webserver endpoints will now be considered "legacy" and will be
>> > > > completely removed by the time Airflow 3.0 is released. But there
>> will
>> > > be a
>> > > > transition time while we get both new projects feature-complete.
>> > > >
>> > > > This means that sometimes we will still have to accept changes to
>> the
>> > > > `airflow/www` javascript files, `airflow/www/views.py` webserver
>> > > endpoints
>> > > > and `airflow/api_connexion` rest API endpoints. But we want to limit
>> > > > contributions to "legacy" code which will be deleted in a few short
>> > > > months. Which
>> > > > is specified here in the Airflow docs.
>> > > > <https://github.com/apache/airflow/pull/41903>
>> > > >
>> > > > 1. Bug fixes to cherry pick for 2.10.x and 2.11
>> > > > 2. The minimum necessary to unblock other Airflow 3.0 feature work
>> > > > 3. Fixes to views and endpoints which we haven't migrated over yet,
>> but
>> > > can
>> > > > still be ported over to the new UI
>> > > >
>> > > > For example, we will not migrate the legacy UI to use the new REST
>> API.
>> > > > This means that, for a time, we will have duplicate code (ex: two
>> > > different
>> > > > grid_data endpoints). But this reduces the surface area that we must
>> > > > maintain and allows us to redesign views and endpoints when
>> necessary
>> > > (ex:
>> > > > making the grid_data more efficient and to better support DAG
>> > > versioning).
>> > > >
>> > > > We see three phases to migrating to the UI:
>> > > > 1. New UI has very few features. Show a dismissible banner to "Check
>> > out
>> > > > the new UI"
>> > > > 2. New UI has most of the core features of Airflow. Make the new UI
>> the
>> > > > default, and link to the legacy UI as an escape hatch. What is
>> > sufficient
>> > > > for "core features" is to be determined.
>> > > > 3. New UI is fully feature-complete, delete the entire legacy UI
>> > project.
>> > > >
>> > > > Let me know what you all think. I am happy to discuss more on the
>> dev
>> > > call
>> > > > tomorrow.
>> > > >
>> > > > - Brent
>> > > >
>> > >
>> >
>> >
>> > --
>> > Bugra Ozturk
>> >
>>
>

Re: UI and API Contributions for Airflow 3.0

[Jarek Potiuk <ja...@potiuk.com>]

Labels are cool Indeed.

Automated test is not too difficult either. Breeze selective check has all
that is needed to figure out the scope of the change in the PR ->
https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L183
and we can produce the right outputs so that they can be used directly in
the actions.

It's about 15 lines of code to add :). Might be one of the good first
issues to tackle by the newly formed CI/CD team.

J.

On Thu, Sep 5, 2024 at 2:13 PM Pierre Jeambrun <pi...@gmail.com>
wrote:

> Thanks Brent.
>
> Yes I like the idea of labels, I believe this will help reviewers know that
> they have to pay extra attention because specific rules apply to updating
> the legacy-ui/api during airflow 3 development.
>
> An automated test is even better but might be more effort to develop.
>
> On Wed, Sep 4, 2024 at 10:34 PM Buğra Öztürk <oz...@gmail.com>
> wrote:
>
> > Thanks for preparing! I think making this distinction between legacy and
> > new UI is beneficial for us. It will make it easy to break and change
> > things. The plan looks great!
> >
> > Great point Jarek. Even though it's not critical, I think it would be
> > beneficial for everyone to see the PR editing the legacy code pieces.
> > Maybe, we can include a set of labels (like legacy-ui, legacy-api or
> > some-label...) by using boring-cyborg powers to auto-label certain legacy
> > code pieces.
> >
> > On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > I like the plan in its entirety.
> > >
> > > Some technicalities - likely we do not want to automate what is / is
> not
> > > allowed - managing it might be difficult, but we could as well add some
> > > separate non-critical / failing test that will "fail" when the "old"
> area
> > > is touched in the PR (but it could be very clearly "just failing
> because
> > it
> > > might not be good to make this.change" - however we could either set a
> > > special label on such PRs (to avoid the error) or just merge it with
> > "red"
> > > status.
> > >
> > > Not critical though. It could also be based on reviews.
> > >
> > > J.
> > >
> > > On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi
> <brent@astronomer.io.invalid
> > >
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > As part of AIPs 38, 79 and 84, Pierre and I have started a new API
> > based
> > > on
> > > > FastAPI and a new UI based purely off of React. The current UI, rest
> > API
> > > > and webserver endpoints will now be considered "legacy" and will be
> > > > completely removed by the time Airflow 3.0 is released. But there
> will
> > > be a
> > > > transition time while we get both new projects feature-complete.
> > > >
> > > > This means that sometimes we will still have to accept changes to the
> > > > `airflow/www` javascript files, `airflow/www/views.py` webserver
> > > endpoints
> > > > and `airflow/api_connexion` rest API endpoints. But we want to limit
> > > > contributions to "legacy" code which will be deleted in a few short
> > > > months. Which
> > > > is specified here in the Airflow docs.
> > > > <https://github.com/apache/airflow/pull/41903>
> > > >
> > > > 1. Bug fixes to cherry pick for 2.10.x and 2.11
> > > > 2. The minimum necessary to unblock other Airflow 3.0 feature work
> > > > 3. Fixes to views and endpoints which we haven't migrated over yet,
> but
> > > can
> > > > still be ported over to the new UI
> > > >
> > > > For example, we will not migrate the legacy UI to use the new REST
> API.
> > > > This means that, for a time, we will have duplicate code (ex: two
> > > different
> > > > grid_data endpoints). But this reduces the surface area that we must
> > > > maintain and allows us to redesign views and endpoints when necessary
> > > (ex:
> > > > making the grid_data more efficient and to better support DAG
> > > versioning).
> > > >
> > > > We see three phases to migrating to the UI:
> > > > 1. New UI has very few features. Show a dismissible banner to "Check
> > out
> > > > the new UI"
> > > > 2. New UI has most of the core features of Airflow. Make the new UI
> the
> > > > default, and link to the legacy UI as an escape hatch. What is
> > sufficient
> > > > for "core features" is to be determined.
> > > > 3. New UI is fully feature-complete, delete the entire legacy UI
> > project.
> > > >
> > > > Let me know what you all think. I am happy to discuss more on the dev
> > > call
> > > > tomorrow.
> > > >
> > > > - Brent
> > > >
> > >
> >
> >
> > --
> > Bugra Ozturk
> >
>

Re: UI and API Contributions for Airflow 3.0

[Pierre Jeambrun <pi...@gmail.com>]

Thanks Brent.

Yes I like the idea of labels, I believe this will help reviewers know that
they have to pay extra attention because specific rules apply to updating
the legacy-ui/api during airflow 3 development.

An automated test is even better but might be more effort to develop.

On Wed, Sep 4, 2024 at 10:34 PM Buğra Öztürk <oz...@gmail.com>
wrote:

> Thanks for preparing! I think making this distinction between legacy and
> new UI is beneficial for us. It will make it easy to break and change
> things. The plan looks great!
>
> Great point Jarek. Even though it's not critical, I think it would be
> beneficial for everyone to see the PR editing the legacy code pieces.
> Maybe, we can include a set of labels (like legacy-ui, legacy-api or
> some-label...) by using boring-cyborg powers to auto-label certain legacy
> code pieces.
>
> On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > I like the plan in its entirety.
> >
> > Some technicalities - likely we do not want to automate what is / is not
> > allowed - managing it might be difficult, but we could as well add some
> > separate non-critical / failing test that will "fail" when the "old" area
> > is touched in the PR (but it could be very clearly "just failing because
> it
> > might not be good to make this.change" - however we could either set a
> > special label on such PRs (to avoid the error) or just merge it with
> "red"
> > status.
> >
> > Not critical though. It could also be based on reviews.
> >
> > J.
> >
> > On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi <brent@astronomer.io.invalid
> >
> > wrote:
> >
> > > Hi all,
> > >
> > > As part of AIPs 38, 79 and 84, Pierre and I have started a new API
> based
> > on
> > > FastAPI and a new UI based purely off of React. The current UI, rest
> API
> > > and webserver endpoints will now be considered "legacy" and will be
> > > completely removed by the time Airflow 3.0 is released. But there will
> > be a
> > > transition time while we get both new projects feature-complete.
> > >
> > > This means that sometimes we will still have to accept changes to the
> > > `airflow/www` javascript files, `airflow/www/views.py` webserver
> > endpoints
> > > and `airflow/api_connexion` rest API endpoints. But we want to limit
> > > contributions to "legacy" code which will be deleted in a few short
> > > months. Which
> > > is specified here in the Airflow docs.
> > > <https://github.com/apache/airflow/pull/41903>
> > >
> > > 1. Bug fixes to cherry pick for 2.10.x and 2.11
> > > 2. The minimum necessary to unblock other Airflow 3.0 feature work
> > > 3. Fixes to views and endpoints which we haven't migrated over yet, but
> > can
> > > still be ported over to the new UI
> > >
> > > For example, we will not migrate the legacy UI to use the new REST API.
> > > This means that, for a time, we will have duplicate code (ex: two
> > different
> > > grid_data endpoints). But this reduces the surface area that we must
> > > maintain and allows us to redesign views and endpoints when necessary
> > (ex:
> > > making the grid_data more efficient and to better support DAG
> > versioning).
> > >
> > > We see three phases to migrating to the UI:
> > > 1. New UI has very few features. Show a dismissible banner to "Check
> out
> > > the new UI"
> > > 2. New UI has most of the core features of Airflow. Make the new UI the
> > > default, and link to the legacy UI as an escape hatch. What is
> sufficient
> > > for "core features" is to be determined.
> > > 3. New UI is fully feature-complete, delete the entire legacy UI
> project.
> > >
> > > Let me know what you all think. I am happy to discuss more on the dev
> > call
> > > tomorrow.
> > >
> > > - Brent
> > >
> >
>
>
> --
> Bugra Ozturk
>

Re: UI and API Contributions for Airflow 3.0

[Buğra Öztürk <oz...@gmail.com>]

Thanks for preparing! I think making this distinction between legacy and
new UI is beneficial for us. It will make it easy to break and change
things. The plan looks great!

Great point Jarek. Even though it's not critical, I think it would be
beneficial for everyone to see the PR editing the legacy code pieces.
Maybe, we can include a set of labels (like legacy-ui, legacy-api or
some-label...) by using boring-cyborg powers to auto-label certain legacy
code pieces.

On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> I like the plan in its entirety.
>
> Some technicalities - likely we do not want to automate what is / is not
> allowed - managing it might be difficult, but we could as well add some
> separate non-critical / failing test that will "fail" when the "old" area
> is touched in the PR (but it could be very clearly "just failing because it
> might not be good to make this.change" - however we could either set a
> special label on such PRs (to avoid the error) or just merge it with "red"
> status.
>
> Not critical though. It could also be based on reviews.
>
> J.
>
> On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi <br...@astronomer.io.invalid>
> wrote:
>
> > Hi all,
> >
> > As part of AIPs 38, 79 and 84, Pierre and I have started a new API based
> on
> > FastAPI and a new UI based purely off of React. The current UI, rest API
> > and webserver endpoints will now be considered "legacy" and will be
> > completely removed by the time Airflow 3.0 is released. But there will
> be a
> > transition time while we get both new projects feature-complete.
> >
> > This means that sometimes we will still have to accept changes to the
> > `airflow/www` javascript files, `airflow/www/views.py` webserver
> endpoints
> > and `airflow/api_connexion` rest API endpoints. But we want to limit
> > contributions to "legacy" code which will be deleted in a few short
> > months. Which
> > is specified here in the Airflow docs.
> > <https://github.com/apache/airflow/pull/41903>
> >
> > 1. Bug fixes to cherry pick for 2.10.x and 2.11
> > 2. The minimum necessary to unblock other Airflow 3.0 feature work
> > 3. Fixes to views and endpoints which we haven't migrated over yet, but
> can
> > still be ported over to the new UI
> >
> > For example, we will not migrate the legacy UI to use the new REST API.
> > This means that, for a time, we will have duplicate code (ex: two
> different
> > grid_data endpoints). But this reduces the surface area that we must
> > maintain and allows us to redesign views and endpoints when necessary
> (ex:
> > making the grid_data more efficient and to better support DAG
> versioning).
> >
> > We see three phases to migrating to the UI:
> > 1. New UI has very few features. Show a dismissible banner to "Check out
> > the new UI"
> > 2. New UI has most of the core features of Airflow. Make the new UI the
> > default, and link to the legacy UI as an escape hatch. What is sufficient
> > for "core features" is to be determined.
> > 3. New UI is fully feature-complete, delete the entire legacy UI project.
> >
> > Let me know what you all think. I am happy to discuss more on the dev
> call
> > tomorrow.
> >
> > - Brent
> >
>


-- 
Bugra Ozturk

Re: UI and API Contributions for Airflow 3.0

[Jarek Potiuk <ja...@potiuk.com>]

I like the plan in its entirety.

Some technicalities - likely we do not want to automate what is / is not
allowed - managing it might be difficult, but we could as well add some
separate non-critical / failing test that will "fail" when the "old" area
is touched in the PR (but it could be very clearly "just failing because it
might not be good to make this.change" - however we could either set a
special label on such PRs (to avoid the error) or just merge it with "red"
status.

Not critical though. It could also be based on reviews.

J.

On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi <br...@astronomer.io.invalid>
wrote:

> Hi all,
>
> As part of AIPs 38, 79 and 84, Pierre and I have started a new API based on
> FastAPI and a new UI based purely off of React. The current UI, rest API
> and webserver endpoints will now be considered "legacy" and will be
> completely removed by the time Airflow 3.0 is released. But there will be a
> transition time while we get both new projects feature-complete.
>
> This means that sometimes we will still have to accept changes to the
> `airflow/www` javascript files, `airflow/www/views.py` webserver endpoints
> and `airflow/api_connexion` rest API endpoints. But we want to limit
> contributions to "legacy" code which will be deleted in a few short
> months. Which
> is specified here in the Airflow docs.
> <https://github.com/apache/airflow/pull/41903>
>
> 1. Bug fixes to cherry pick for 2.10.x and 2.11
> 2. The minimum necessary to unblock other Airflow 3.0 feature work
> 3. Fixes to views and endpoints which we haven't migrated over yet, but can
> still be ported over to the new UI
>
> For example, we will not migrate the legacy UI to use the new REST API.
> This means that, for a time, we will have duplicate code (ex: two different
> grid_data endpoints). But this reduces the surface area that we must
> maintain and allows us to redesign views and endpoints when necessary (ex:
> making the grid_data more efficient and to better support DAG versioning).
>
> We see three phases to migrating to the UI:
> 1. New UI has very few features. Show a dismissible banner to "Check out
> the new UI"
> 2. New UI has most of the core features of Airflow. Make the new UI the
> default, and link to the legacy UI as an escape hatch. What is sufficient
> for "core features" is to be determined.
> 3. New UI is fully feature-complete, delete the entire legacy UI project.
>
> Let me know what you all think. I am happy to discuss more on the dev call
> tomorrow.
>
> - Brent
>