POC: Generate RTK Query clients for App Platform APIs #87545
Conversation
|
interesting to see what comes out of codegen... honestly kinda gross and mostly highlights all the things we do not want people using from the UI 😬 The only part that is not boilerplate (exactly identical for any ResourceServer) is the typed response. The openapi spec just identifies a bunch of our key metadata as |
|
I have not yet explored how https://github.com/kubernetes/dashboard/tree/master/modules/web handles their client -- it also supports the "watch" command so that may be interesting to look at |
joshhunt
force-pushed
the
joshhunt/generate-k8s-rtk-q-apis
branch
from
851bc48
to
f3c75ae
Compare
joshhunt
force-pushed
the
joshhunt/generate-k8s-rtk-q-apis
branch
from
d2acda2
to
0e2a38c
Compare
| getApiResources: build.query<GetApiResourcesApiResponse, GetApiResourcesApiArg>({ | ||
| query: () => ({ url: `/apis/playlist.grafana.app/v0alpha1/` }), | ||
| }), | ||
| listPlaylists: build.query<ListPlaylistsApiResponse, ListPlaylistsApiArg>({ |
There was a problem hiding this comment.
How did you get these endpoint names (without the namespace stuff), manual search + replace?
There was a problem hiding this comment.
Yeah - I manually edited the OpenAPI spec and then generated from that 0e2a38c
| @@ -3,6 +3,17 @@ | |||
| "info": { | |||
There was a problem hiding this comment.
Do we expect each resource to contain these spec files?
There was a problem hiding this comment.
Yes! They basically do already - see all the zz_generated.openapi.go files in the repo. This is just a JSON serialisation of those files.
| } | ||
| } | ||
| } | ||
| ], |
There was a problem hiding this comment.
So this abstracts the base URL, so we don't need to define those separately for each endpoint?
There was a problem hiding this comment.
Yes, that's the role of it in OpenAPI specs.
But, here I've used this to avoid RTK Query generating URLs that require a namespace parameter, and it'll be defined centrally/manually in the baseAPI.ts file. It's half hack, half what it's designed for.
| @@ -23,6 +23,25 @@ const config: ConfigFile = { | |||
| 'getDashboardByUid', | |||
| ], | |||
| }, | |||
|
|
|||
There was a problem hiding this comment.
Wonder how to make this work for Enterprise. Should we define the same file there with own paths and then somehow merge it with this one?
There was a problem hiding this comment.
Yeah, that's a valid question. Where would the API clients for enterprise live? Given the legacy api enterprise spec lives in the OSS repo, i think it's fine to generate the clients into OSS repo as well.
There was a problem hiding this comment.
I think the generated clients should be in the same place as the feature (the FE part), under the api folder, so Enterprise clients would be in the Enterprise repo. As for the scripts that generate those clients, I'm not sure.
There was a problem hiding this comment.
Yeah, that's valid. The problem is that there's this desire to share at least some of these API clients with plugins, probably through the grafana-runtime package.
| baseURL: `/apis/playlist.grafana.app/v0alpha1/namespaces/${config.namespace}/`, | ||
| }), | ||
| endpoints: () => ({}), | ||
| }); |
There was a problem hiding this comment.
This file looks like it'll be quite similar for all clients, could it be also generated?
|
There's probably not going to be much more work on this branch for now, so I'll close the PR and see what happens next :). Comments are still welcome! |
Part of #87540