Chainlit Frontend Bypasses Functional

[HESleagacy]

The FastAPI backend exposes two distinct routes for GraphQL query generation:

• /flat_graphql

  • Intended for simple, single-level queries
  • Example: "Query all male patients"

• /nested_graphql

  • Intended for complex, multi-level relationship queries involving nested PCDC GitOps nodes
  • Example: "Patients with metastatic tumors located in the skin"

However, the current Chainlit frontend implementation routes all user messages exclusively through /nested_graphql, beginning at Line 89.

This makes the /flat_graphql endpoint completely inaccessible from the UI.

[suruanush]

can i fix it

[HESleagacy]

@suruanush Yes, that would be a helpful solution.

Since /nested_graphql is currently used for all queries, /flat_graphql is essentially unused from the user interface. It would make more sense to expose and route to /flat_graphql for straightforward single-level filters.
Although I'm not the maintainer, based on what I understand of the current flow, it would be more in line with the intended architecture to enable both endpoints in the frontend.

[aarnavp25-sys]

Hi, I was going through this issue while exploring the repository after my recent PR.

From what I understand, the frontend is currently routing all queries through the nested_graphql endpoint, which makes sense for complex queries but seems to bypass simpler cases where flat_graphql would be more appropriate.

Would it make sense to introduce a small routing or validation layer in the frontend (or backend) that decides which endpoint to use based on query complexity?

I’ve been working with GraphQL-based data processing in my heatmap prototype, and I’ve seen similar cases where separating simple vs nested queries improves both clarity and performance. Happy to explore this further if needed.—

[HESleagacy]

@aarnavp25-sys That would be great, just avoid LLM classification because already the project relies on AI too much instead for the routing layer try relationship count i.e, If query involves more than one entity consider it as nested

[aarnavp25-sys]

Yeah that makes sense, keeping it based on relationship count is much cleaner.

So basically if the query involves multiple entities, we can treat it as nested and route it accordingly. I’ll try exploring how to detect that from the query structure or schema.

Thanks, this clears things up a lot.

[HESleagacy]

@aarnavp25-sys Good Choice, I am also willing to work with you given we get approval from the maintainers first since we are intoducing a new layer.