Auto-generate rest client

[callumforrester]

We should auto-generate the rest client code rather than handcraft it. Replacing blueapi.cli.rest.BlueapiRestClient with something generated with swagger-codegen or similar

[stan-dot]

todo - make a test repository demonstrating proof of concept with fastapi
https://fastapi.tiangolo.com/advanced/generate-clients/

[stan-dot]

@callumforrester need more info on the use case for this client. Will it be called from a Python GUI app? Right now it's only the CLI client.

most generators focus on the Typescript use case. The documentation for the Python one isn't that great https://openapi-generator.tech/docs/generators/python/

[stan-dot]

ah I see there's a huge benefit from autocompletion - but I'm not sure if I got it running on my device

[stan-dot]

what is the target use case for building this CLI? Testing the API? running it? I've looked into autogeneration and there are libraries for that, but then we'd need to write custom CLI to it. I haven't noticed a library that would produce the CLI at the same time. We would need then to manually update the cli code on every regeneration. there is a plethora of tools for rapid api testing or calling remote servers. They are much more powerful than custom CLI, with more support.

If we go with recommending a GUI option like Postman, users could even have an account and keep their API call data across devices. If not Postman we can consider some alternatives:

• httpie
• jmeter from apache
• testsigma - more geared towards automation
• insomnia - with also support for git storage, websockets and grpc
• soapUI
• redocly - not necessarily a rest client, but a good tool to use with openapi
• postman windows client - this could be huge for many users

In conclusion, using a third party instead of in house CLI would be beneficial.

In regards to the client for a GUI python / web app that can be done quite easily. I will add a github action workflow soon

[callumforrester]

For now I think the only use case is auto-generating a version of this class:

blueapi/src/blueapi/cli/rest.py

Line 26 in 7bbc94e

class BlueapiRestClient:

Future classes that fulfil the use cases you suggest can build on top of it.

[stan-dot]

I mean use case in the broad sense of having the Python Rest client in the first place

[callumforrester]

Yes, the use case is mainly testing/debugging. The reason for writing this and not just using rest tools is that
the CLI doesn't just make rest calls though, it combines several rest calls together for the user's convenience and also listens to the message bus via a query-then-subscribe model.

[stan-dot]

just use this https://openapi-generator.tech/docs/generators/python-pydantic-v1/

[stan-dot]

if the client is generated, we could publish it as a pypi package and have cli as a separate project. admittedly if Kubernetes is the inspiration, they have a build setup with a monorepo.

depends on what is the target use case I guess

https://github.com/kubernetes/kubernetes/blob/master/build/root/Makefile

[stan-dot]

For most cases, especially in a microservices architecture or when sharing clients among multiple teams, the registry approach aligns better with continuous integration and delivery practices. It optimizes reuse and version management, although it requires a bit more setup initially.

chatgpt has an opinion

[stan-dot]

note: java has a build repo in gitlab maven using this dynamically, with version set manually on release. not scalable

[stan-dot]

note: this setup has a tighter loop for DX rather that leaving this to CI. can be explored next https://chat.openai.com/share/eb5d3fb7-5024-4146-a50a-4cda7c37c70f

[stan-dot]

working on this now

[stan-dot]

the generator produces not one file, but a whole project:
`

`

[stan-dot]

note from discussion - to reuse the structure from the tiled repo.

[stan-dot]

based on the #449 pydantic 2 migration we'll be able to use the generic python generator instead of the odd pydantic-v1 version. It makes no sense to migrate at the moment to v1 if after #449 we'd need to migrate again. delaying this right now