Needs GraphQL implementation
mlejva opened this issue · comments
We've received feedback from an advanced user (working on AutoPack and Beebot) that the GraphQL implementation of the protocol might suit the needs of agent developers better:
-
I needed access to the app instance. with the module-level defined app object it's super hard to do that. i needed to add CORS stuff as well as the websocket server
-
Since I am using database persistence I would've needed to keep the state of the module-level variables tasks and steps in sync with the database, which is super hard to do.
-
The handler data structures were hard to work with and it was easier to just directly plug in to my own lifecycle functions
-
My recommendation is to have a class so that an agent can create a subclass that overrides whatever functionality they need to. The class would hold the FastAPI instance- meaning that the agent themselves can pass in their own app if they need to. figuring out persistence and state is harder, but i think it's a good idea to have a proper data structure for state and make it easier for agent developers to plug in their own state systems
-
GraphQL would allow using subscriptions
The disadvantage is that GraphQL learning curve is steeper.
We should probably support both REST and GraphQL implementation but we can't do both at the same time for v1.
FYI if this happens I would recommend Ariadne for the python library. Here's a quick page on how to integrate it into an existing fastapi instance so it's easy for graphql and rest endpoints to coexist.
If I'm not mistaken, ariadne is schema first. We can then use this tool to get GQL. That should make it easier to keep everything in sync (and maybe to implement as well)