chatlogic/src/graphql.py needs rearchitecting to decouple GraphQL from the server calls.
This is the current architecture:
User query -> LLM parses and returns an API query method -> is processed into raw GQL query -> Query is sent and data is received and parsed back into Pydantic object.
An intermediary step should be added to make GQL a specific implementation that could be swapped out for REST endpoints:
User query -> LLM parses and returns an API query method -> implementation function is called -> is processed into raw GQL query OR a REST endpoint is called -> Query is sent and data is received and parsed back into Pydantic object.
Currently, the LLM is given a list of gql query endpoints that it can choose from, and it is trained to return a GQLQueryModel json object which contains the query name, list of fields to be returned and the parameters. This model is then used in _generate_complete_gql_query to generate a raw gql query string which is then executed.
What would be more ideal is to decouple GraphQL entirely from the db server calls. One way to do this would be to create a local function for each gql query that matches the gql structure. For example:
Specific database implementation call would go inside the function. It could assemble a gql raw query using _generate_complete_gql_query , or it could be calling an REST endpoint. The implementation to serialize this into Pydantic would also be contained here.
(If you want to get even more sophisticated, you could create an interface and an implementation class which you inject into the constructor, following the Springboot design.)
Then if you wanted to execute that query, you would simply call:
chatlogic/src/graphql.py
needs rearchitecting to decouple GraphQL from the server calls.This is the current architecture:
An intermediary step should be added to make GQL a specific implementation that could be swapped out for REST endpoints:
Currently, the LLM is given a list of gql query endpoints that it can choose from, and it is trained to return a
GQLQueryModel
json object which contains the query name, list of fields to be returned and the parameters. This model is then used in_generate_complete_gql_query
to generate a raw gql query string which is then executed.What would be more ideal is to decouple GraphQL entirely from the db server calls. One way to do this would be to create a local function for each gql query that matches the gql structure. For example:
Specific database implementation call would go inside the function. It could assemble a gql raw query using
_generate_complete_gql_query
, or it could be calling an REST endpoint. The implementation to serialize this into Pydantic would also be contained here.(If you want to get even more sophisticated, you could create an interface and an implementation class which you inject into the constructor, following the Springboot design.)
Then if you wanted to execute that query, you would simply call:
and irregardless of the database implementation, it will return a Pydantic model.