Skip to content

[Endpoints] [11/x] Main Gateway page and create endpoint#19042

Closed
BenWilson2 wants to merge 2 commits intomlflow:masterfrom
BenWilson2:stack/endpoints/ui-create-endpoint
Closed

[Endpoints] [11/x] Main Gateway page and create endpoint#19042
BenWilson2 wants to merge 2 commits intomlflow:masterfrom
BenWilson2:stack/endpoints/ui-create-endpoint

Conversation

@BenWilson2
Copy link
Member

@BenWilson2 BenWilson2 commented Nov 26, 2025

🥞 Stacked PR

Use this link to review incremental changes.


Related Issues/PRs

#xxx

What 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?

  • Existing unit/integration tests
  • New unit/integration tests
  • Manual tests

Does this PR require documentation update?

  • No. You can skip the rest of this section.
  • Yes. I've updated:
    • Examples
    • API references
    • Instructions

Release Notes

Is this a user-facing change?

  • No. You can skip the rest of this section.
  • Yes. Give a description of this change to be included in the release notes for MLflow users.

What component(s), interfaces, languages, and integrations does this PR affect?

Components

  • area/tracking: Tracking Service, tracking client APIs, autologging
  • area/models: MLmodel format, model serialization/deserialization, flavors
  • area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
  • area/scoring: MLflow Model server, model deployment tools, Spark UDFs
  • area/evaluation: MLflow model evaluation features, evaluation metrics, and evaluation workflows
  • area/gateway: MLflow AI Gateway client APIs, server, and third-party integrations
  • area/prompts: MLflow prompt engineering features, prompt templates, and prompt management
  • area/tracing: MLflow Tracing features, tracing APIs, and LLM tracing functionality
  • area/projects: MLproject format, project running backends
  • area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server
  • area/build: Build and test infrastructure for MLflow
  • area/docs: MLflow documentation pages

How 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" section
  • rn/breaking-change - The PR will be mentioned in the "Breaking Changes" section
  • rn/feature - A new user-facing feature worth mentioning in the release notes
  • rn/bug-fix - A user-facing bug fix worth mentioning in the release notes
  • rn/documentation - A user-facing documentation change worth mentioning in the release notes

Should this PR be included in the next patch release?

Yes should be selected for bug fixes, documentation updates, and other small changes. No should 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?
  • Minor release: a release that increments the second part of the version number (e.g., 1.2.0 -> 1.3.0).
    Bug fixes, doc updates and new features usually go into minor releases.
  • Patch release: a release that increments the third part of the version number (e.g., 1.2.0 -> 1.2.1).
    Bug fixes and doc updates usually go into patch releases.
  • Yes (this PR will be cherry-picked and included in the next patch release)
  • No (this PR will be included in the next minor release)

@BenWilson2 BenWilson2 changed the title endpoint pages [Endpoints] [11/x] Main Gateway page and create endpoint Nov 26, 2025
@BenWilson2 BenWilson2 marked this pull request as ready for review November 26, 2025 03:47
@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch from c956027 to 9891ffe Compare November 27, 2025 02:52
@github-actions github-actions bot added area/uiux Front-end, user experience, plotting, JavaScript, JavaScript dev server rn/feature Mention under Features in Changelogs. labels Nov 27, 2025
@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch from 9891ffe to 73485a7 Compare November 27, 2025 06:31
@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch 2 times, most recently from 4c1de82 to 2db062c Compare December 2, 2025 02:14
@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch 2 times, most recently from 6410f45 to 180c20e Compare December 2, 2025 22:49
@github-actions
Copy link
Contributor

github-actions bot commented Dec 2, 2025

Documentation preview for b85afbc is available at:

More info
  • Ignore this comment if this PR does not change the documentation.
  • The preview is updated when a new commit is pushed to this PR.
  • This comment was created by this workflow run.
  • The documentation was built by this workflow run.

@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch 5 times, most recently from 346ab42 to 48247dd Compare December 4, 2025 01:54
}

// Build the menu items with section headers
const menuItems: JSX.Element[] = [];
Copy link
Collaborator

@danielseong1 danielseong1 Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's good to memoize this so we don't create a new reference every render cycle

};
}

const CreateEndpointPage = () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch 14 times, most recently from 30a606e to c206ed9 Compare December 11, 2025 16:10
Signed-off-by: Ben Wilson <benjamin.wilson@databricks.com>
Signed-off-by: Ben Wilson <benjamin.wilson@databricks.com>
@BenWilson2 BenWilson2 force-pushed the stack/endpoints/ui-create-endpoint branch from c206ed9 to b85afbc Compare December 11, 2025 22:43
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").
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's fine here, but in the future i think we can probably split out the python and JS changes into separate PRs

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BenWilson2 I thought we removed credential_name. Is this diff because the branch is not yet rebased?

Comment on lines +73 to +86
<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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good - will migrate

Copy link
Collaborator

@daniellok-db daniellok-db Dec 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file seems to change a lot in #19070 and #19176, so i won't leave much comments here

Copy link
Collaborator

@daniellok-db daniellok-db left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. python changes to add credential_name to protos
  2. secrets list - we should probably have done secrets first since it seems relatively independent
  3. 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
  4. secrets edit
  5. endpoint list page. in this PR you can have the EndpointsList + useEndpointsQuery changes
  6. create endpoint form part 1 - render the page + layout helpers
  7. create endpoint form part 2 - model section + provider fetching queriers
  8. create endpoint form part 3 - auth section
  9. edit endpoints, ideally this could have just reused the create endpoint stuff but add a new prop like isEditing to control which endpoint we call, since the form is otherwise the same
  10. 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)': {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@BenWilson2 BenWilson2 closed this Dec 29, 2025
@BenWilson2 BenWilson2 deleted the stack/endpoints/ui-create-endpoint branch December 29, 2025 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/uiux Front-end, user experience, plotting, JavaScript, JavaScript dev server rn/feature Mention under Features in Changelogs.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants