dstandish commented on code in PR #53429:
URL: https://github.com/apache/airflow/pull/53429#discussion_r2226133704
##########
airflow-core/src/airflow/api_fastapi/core_api/routes/ui/dags.py:
##########
@@ -191,3 +195,36 @@ def get_dags(
total_entries=total_entries,
dags=list(dag_runs_by_dag_id.values()),
)
+
+
+@dags_router.get(
+ "/{dag_id}/latest_run",
+ responses=create_openapi_http_exception_doc([status.HTTP_404_NOT_FOUND]),
+ dependencies=[Depends(requires_access_dag(method="GET",
access_entity=DagAccessEntity.RUN))],
+)
+def get_latest_run_info(dag_id: str, session: SessionDep) ->
list[DAGRunLightResponse]:
+ """Get latest run."""
+ if dag_id == "~":
+ raise HTTPException(
+ status.HTTP_400_BAD_REQUEST,
+ "`~` was supplied as dag_id, but querying multiple dags is not
supported.",
Review Comment:
My perspective is sorta, who cares if we're making another endpoint -- isn't
that what the private API is for?
It's like, adding some internal function that gets the data you need. Not
part of the public interface. Doesn't really matter at all. We would not bat
an eye at someone adding a private helper function in a internal module. Why
do we care about limiting private endpoints -- why is that even a
consideration? It's like a private function that happens to be an endpoint.
Is there something special about it being an "API" instead of just a function
that means we need to limit the number we add? It would be different if I were
adding to public interface -- then we would want to be more thoughtful with
curating the UX, you would think. But, it's internal and essentially
throwaway.
To me anyway, the ugliness and inefficiency of the public API is a known
issue and the inneficiency of it so me seems pretty obvious and in some ways
unavoidable. It has to return all the columns and joins and do all the things,
because it tries to do everything, because it has no clue what its use case is.
It deals with pagination, and tons of possible filters. It may need to
deserilaize a dag. It's just pretty heavy in general. If you want to make its
behavior conditionally optimized, it would get ugly. Isn't that why the
private API exists?
I asked my full stack friend about this issue. He mentioned "backend for
frontend" pattern. He also mentioned graphql is another way this sort of thing
is dealt with. But, of course, that is not likely practical for us.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
