Collocation of Data Requirements without GraphQL Fragments

[lilac cloak]

hi everyone, i wonder what your thoughts / solutions on Data Collocation without GraphQL Fragments:

"
Let's say you've got a page that displays a list of blog posts, and each blog post has a list of comments.

The Comment component has two data dependencies: title and content. Let's say we're using this component in 10 different places in our application. If we want to add a new field to the Comment component, e.g. author, we have to figure out all the places where we're using the Comment component, navigate to the root component, find the procedure that fetches the data, and add the new field to it.

You can see how this can quickly become a huge maintenance burden. The problem that leads to this is that we're fetching data top down. The result is tight coupling between the data fetching logic and the components.

With Relay and Fragments, we're able to collocate the data requirements with the component, while simultaneously decoupling the data fetching logic from the component.
"

hi @errant swallow 👋 i'd like to tag you here because we are in a very similar situation, and i was curious about what you think about this problem.

i don't define hundreds of API nor do i use GraphQL, instead i use a db client, like Drizzle ORM in your case.

so we can directly send a customized query we want.

but the above remains a problem bothering me. i wonder how you (and other people) think about this data collocation problem?

[errant swallow]

Hey, well I'm not too familiar with Relay or GraphQL, and my current Qwik side project is a small game, it has two tables and really only one place to show the data, other than my db-seed page which I use for testing. But I'll throw out some ideas which may help:

One thing that comes to mind is building a context provider/service which could encapsulate the serverDbService (which holds the server$ query functions). It could be the single place that interacts with the dbService and could store the responses/data in the context, and you could develop custom usePosts or useComments hooks to also provide specific data in the children. (See #general message for an idea of how you can have functions and state inside a context, but instead of fetching you can use server$ functions directly or the serverDbService object - you could also make CustomerProvider a component returning a <Slot /> and use as a component in the layout e.g. index.tsx: <CustomerProvider><App /></CustomerProvider> or layout.tsx: <CustomerProvider><Slot /></CustomerProvider> if you prefer that style)

I liked using React-Query on a previous job, but that was for an advertising platform so the data was unique to the page, but still can build wrapper hooks to encapsulate the query/mutation for reuse. (There is a Qwik-Query, I think the basic functionality is working but it's on Qwik v1.2.6 (and tanstack v4.33) so at least would need to update the Qwik version!)

Seems like Relay is kinda like Redux mixed with a query client (like ReduxToolKitQuery or kinda like React-Query) so that's why I was thinking about that. But context is powerful so without our own query/data client you could make a dbContextService etc. Hope that helps! Feel free to provide more info/examples if I'm off the mark.

[lilac cloak]

thanks so much for sharing!

you can read this part: https://wundergraph.com/blog/relay_wundergraph_integration_announcement#collocation-of-data-requirements-using-fragments

i used relay + graphql before and did not choose this tech stack this time (Qwik is one of the reasons), and realized i have to face the chanllenge that Relay helps solved automatically:

1. data collocation
2. data masking

i have not yet found any other solution today can do these (at least the first point) ... so i was curious how other folks think abou this.

another thing i really miss about GraphQL is the tooling around type generation for frontend apps

[errant swallow]

About types, I'll also mention that I use Drizzle so I define my table, and then I use that table to create my types. Then I can use those types everywhere. Actually can create an "insert" type and a "select" type, because perhaps you have an auto-incrementing id column so your "insert" type will be all columns except the id. That at least gets you started with the basic types, so then you only need them defined in one place (the table definition)

[lilac cloak]

thanks for sharing!

[uneven kernel]

One of the reasons I like GraphQL is that it forces you to have a translation layer between the server and the client. Since we don't really need graphql in Qwik, I'd recommend putting the db behind a bunch of helper functions, and calling only those helpers in server$.

Then, types are already solved, server$ does the right thing.

One thing you have to watch out for is that anybody can call the server$ qrls at any time, so you should make sure that your helper functions validate all arguments. There is no guarantee that any server$ parameter or scope variable is defined or matches the type.

[lilac cloak]

thanks for sharing your insights!

i am not sure i get the "types are already solved" part? i was more about generating static type definition files for hundreds of tables in db. although it's not really a Qwik problem, it's just the db client i use lacks the tool to generate types automatically.

anybody can call the server$ qrls at any time

thanks for this reminder, this is really useful.

since the db client lives only on server, i define only one high privilege machine user to interact with db.

so, i imagine a bad actor can get the access token from browser dev tools, then call the server$ qrls

but just to confirm, when they call server$ qrls, the request will still go through the authentication layer in my Qwik web app, right? so they still need to have a valid jwt token.

^^ assuming i have a auth plugin file.