Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple GraphQL client from server endpoints #10

Open
sxflynn opened this issue Apr 24, 2024 · 0 comments
Open

Decouple GraphQL client from server endpoints #10

sxflynn opened this issue Apr 24, 2024 · 0 comments

Comments

@sxflynn
Copy link
Owner

sxflynn commented Apr 24, 2024

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:

def summarizeWholeClassCourseGradeBetweenDates(
     teacher_last_name: str, 
     course_nam: str, 
     startDate: str, 
     endDate: str
) -> ReportCard

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:

summarizeWholeClassCourseGradeBetweenDates(teacherLastName = "Saunders", courseName = "Writing", startDate = "2023-10-01", endDate = "2023-10-30")

and irregardless of the database implementation, it will return a Pydantic model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant