You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this question is somewhat in line with #3, but has there been any discussion around making moonraker and/or klipper have a schema first approach for delivering a web api?
I am toying with the idea of building a native android application (or maybe even do iOS and web concurrently all in kotlin). Obviously all on top of moonraker, but the effort required initially and ongoing would be far less if the api surface was communicated in a rigorous formal way.
There might be an argument that the growth rate of the klipper eco-system would benefit best from such a contract driven approach. I for one would LOVE to see a gRPC or GraphQL system as a way to interact with klipper.
The text was updated successfully, but these errors were encountered:
GraphQL looks interesting and I might consider adding support for it. I don't have a time frame on it though, I have a few other items I need to get done before I could start working on it.
I think this question is somewhat in line with #3, but has there been any discussion around making moonraker and/or klipper have a schema first approach for delivering a web api?
I am toying with the idea of building a native android application (or maybe even do iOS and web concurrently all in kotlin). Obviously all on top of moonraker, but the effort required initially and ongoing would be far less if the api surface was communicated in a rigorous formal way.
Things like gRPC, GraphQL, or OpenApi come to mind.
There might be an argument that the growth rate of the klipper eco-system would benefit best from such a contract driven approach. I for one would LOVE to see a gRPC or GraphQL system as a way to interact with klipper.
The text was updated successfully, but these errors were encountered: