[Endpoints] [11/x] Main Gateway page and create endpoint#19042
[Endpoints] [11/x] Main Gateway page and create endpoint#19042BenWilson2 wants to merge 2 commits intomlflow:masterfrom
Conversation
c956027 to
9891ffe
Compare
9891ffe to
73485a7
Compare
4c1de82 to
2db062c
Compare
6410f45 to
180c20e
Compare
|
Documentation preview for b85afbc is available at: More info
|
346ab42 to
48247dd
Compare
| } | ||
|
|
||
| // Build the menu items with section headers | ||
| const menuItems: JSX.Element[] = []; |
There was a problem hiding this comment.
it's good to memoize this so we don't create a new reference every render cycle
| }; | ||
| } | ||
|
|
||
| const CreateEndpointPage = () => { |
There was a problem hiding this comment.
more of a recommendation but one common practice is to separate components into 'container' components and 'renderer' components. container contains all business logic (state handling, the form definition, data fetching hooks, etc.), and renderer is a pretty dumb component that just renders data that is passed into it. it could be useful here because then we can easily swap out different renderers - a full page version, modal version, etc - while reusing all the important business logic.
30a606e to
c206ed9
Compare
Signed-off-by: Ben Wilson <benjamin.wilson@databricks.com>
Signed-off-by: Ben Wilson <benjamin.wilson@databricks.com>
c206ed9 to
b85afbc
Compare
| created_at: Timestamp (milliseconds) when the secret was created. | ||
| last_updated_at: Timestamp (milliseconds) when the secret was last updated. | ||
| provider: LLM provider this secret is for (e.g., "openai", "anthropic"). | ||
| credential_name: Credential identifier for display (e.g., "api_key", "access_keys"). |
There was a problem hiding this comment.
it's fine here, but in the future i think we can probably split out the python and JS changes into separate PRs
There was a problem hiding this comment.
@BenWilson2 I thought we removed credential_name. Is this diff because the branch is not yet rebased?
| <ScrollablePageWrapper css={{ overflow: 'hidden', display: 'flex', flexDirection: 'column' }}> | ||
| <FormProvider {...form}> | ||
| <div css={{ padding: theme.spacing.md }}> | ||
| <Breadcrumb includeTrailingCaret> | ||
| <Breadcrumb.Item> | ||
| <Link to={GatewayRoutes.gatewayPageRoute}> | ||
| <FormattedMessage defaultMessage="Gateway" description="Breadcrumb link to gateway page" /> | ||
| </Link> | ||
| </Breadcrumb.Item> | ||
| </Breadcrumb> | ||
| <Typography.Title level={2} css={{ marginTop: theme.spacing.sm }}> | ||
| <FormattedMessage defaultMessage="Create endpoint" description="Page title for create endpoint" /> | ||
| </Typography.Title> | ||
| </div> |
There was a problem hiding this comment.
nit: from an organization perspective i would probably put these providers / wrappers / breadcrumbs in the parent component (CreateEndpointPage) rather than in this form renderer as they are more part of the page than the form.
this also allows us to have non full-page renderings of the form for example
There was a problem hiding this comment.
sounds good - will migrate
There was a problem hiding this comment.
stamping to unblock but i think this one PR could have been broken up into 7 or more smaller PRs. it tends to be easier to break up if you follow the user flow:
- python changes to add
credential_nameto protos - secrets list - we should probably have done secrets first since it seems relatively independent
- secrets creation - this could come with the creation hooks. in general i like to keep the data fetches / mutator changes either in the same PR as the UI changes or in one PR before, so review can be focused
- secrets edit
- endpoint list page. in this PR you can have the EndpointsList + useEndpointsQuery changes
- create endpoint form part 1 - render the page + layout helpers
- create endpoint form part 2 - model section + provider fetching queriers
- create endpoint form part 3 - auth section
- edit endpoints, ideally this could have just reused the create endpoint stuff but add a new prop like
isEditingto control which endpoint we call, since the form is otherwise the same - endpoint details page
each PR could come with focused screenshots showing the change so that it's easy to keep the review focused and detailed, and we have less chances of missing stuff.
i think the guiding principle is to keep PRs under 300 lines long and it's okay to do things in parts (e.g. if parts of the create form are complex and require lots of utils, we can just implement the form bit by bit). we can use feature flags to gate off partial work if we're merging straight to master, for example we could just hide the gateway entrypoint in the sidebar while we're still working on it.
i understand it's pretty difficult to think of the PR structure beforehand, in fact i don't do that myself. what i typically do is make all the changes in one mega branch, then after i have things working the way i want and i know generally what all the changes will be, then it's a lot easier to think how the PRs should be sequenced. i then go back to master and create the stack, copy-pasting things from my mega branch. it's time consuming but the benefit is that reviews go a lot faster, and bugs can actually be caught and fixed easily
| paddingTop: theme.spacing.lg, | ||
| paddingBottom: theme.spacing.lg, | ||
| borderBottom: hideDivider ? 'none' : `1px solid ${theme.colors.borderDecorative}`, | ||
| '@media (max-width: 767px)': { |
There was a problem hiding this comment.
i see we sometimes use 767 as the breakpoint and other times we use 1023. should we just have a consistent breakpoint at which we consider the form to be "narrow"? it seems like we could always just use 1023 or maybe something even higher as it starts to look odd already at ~1100
Screen.Recording.2025-12-15.at.12.18.07.PM.mov
| > | ||
| <div css={{ display: 'flex', flexDirection: 'column', gap: theme.spacing.xs }}> | ||
| <div css={{ display: 'flex', alignItems: 'center', gap: theme.spacing.sm }}> | ||
| <Typography.Text bold>{model.model}</Typography.Text> |
There was a problem hiding this comment.
I saw model name contains provider name like gemini/gemini-2.5-flash, so can we remove provider names when displaying in UI?
| } | ||
| }; | ||
|
|
||
| const handleSelect = (model: Model) => { |
There was a problem hiding this comment.
I wonder if we can allow users to still type in the model name since LiteLLM might not have the latest models in their config while the models can be called using the LiteLLM client
🥞 Stacked PR
Use this link to review incremental changes.
Related Issues/PRs
#xxxWhat changes are proposed in this pull request?
Adds the endpoint listing page, endpoint creation page, endpoint details page, endpoint edit page, and the model selection modal.
How is this PR tested?
Does this PR require documentation update?
Release Notes
Is this a user-facing change?
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/tracking: Tracking Service, tracking client APIs, autologgingarea/models: MLmodel format, model serialization/deserialization, flavorsarea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/evaluation: MLflow model evaluation features, evaluation metrics, and evaluation workflowsarea/gateway: MLflow AI Gateway client APIs, server, and third-party integrationsarea/prompts: MLflow prompt engineering features, prompt templates, and prompt managementarea/tracing: MLflow Tracing features, tracing APIs, and LLM tracing functionalityarea/projects: MLproject format, project running backendsarea/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesHow should the PR be classified in the release notes? Choose one:
rn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notesShould this PR be included in the next patch release?
Yesshould be selected for bug fixes, documentation updates, and other small changes.Noshould be selected for new features and larger changes. If you're unsure about the release classification of this PR, leave this unchecked to let the maintainers decide.What is a minor/patch release?
Bug fixes, doc updates and new features usually go into minor releases.
Bug fixes and doc updates usually go into patch releases.