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
