[GitHub] [airflow] potiuk commented on issue #26215: Trigger DAG UI Extension w/ Flexible User Form Concept

[GitBox <gi...@apache.org>]

potiuk commented on issue #26215:
URL: https://github.com/apache/airflow/issues/26215#issuecomment-1240022031

   I think there is nothing "wrong" about this proposal. It does look sound initially and there is nothing "blocking" at a first glance. However the size and scope of it I think qualifies to write an Airlfow Improvement proposal instead of creating a feature issue in Github: https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals . I am happy to add you to be able to create a proposal - based on this issue @jens-scheffler-bosch if you post here user-name you will register at our Confluence page.
   
   Also I personally think (@bbovenzi @pierrejeambrun - I guess you might want to comment on it) this should be much bigger discussion than just "Trigger UI". I think we already know that we are moving away from Flask App Builder and we are implementing new UI components in React, and we will eventually migrate all our UI to React. Also what is important is that we currently have the mechanism of adding Plugins (via FAB mechanisms) and it's pretty useful for our users, so we likely want to replace the custom views developed with FAB with custom views develop with something else (What? ). Should it be react based? Maybe Embedded Streamlit apps ?(personally I think this option is an interesting one and should be explored at least).
   
   I think whatever we implement as "custom trigger UI" should be at the very least already implemented in the same technology that we choose to extend Airflow UI in the future.  And this proposal should not only focus on the "trigger UI" but  also be at the very least first step in the direction of "lets define a new way how to add customised UI to Airflow". This likely calls for a POC implementation of a few options and choosing the best one based on a POC concept first. This is important, because it might heavily influence on the ways how such custom trigger ui will be described (declarative? Python code?) and deployed (when it comes to Web UI, security is super-important and we need to know what will be the deployment model of those "customisations" - who will be able to add them, how, what are the risks involved, whether ther will be any sandbox the custom code will be executed? Will it be server-side as well as client-only, or maybe it should only execute in the browser's javas
 cript). I think there are a lot of "inrastructural" qustions to answer - that's why I think AIP (and likely quite some time of discussing and trying out different options is inevitable). 
   
   I am not sure if others have already thoguht about it and maybe have their own ideas there, or maybe that was something put-off for later, but I am pretty sure we should not add any customizable UI addition without knowing what is our strategic direction there.
   
   Happy to hear what others think about it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org