The paradigm of Remix for those of us who persist in old ways

[marwan38]

Adopting Remix has been somewhat challenging due to the different paradigm and thought patterns that is required by the developer to efficiently adopt and use Remix. One of these paradigms, is the usage of Apollo client within the application. This discussion is directly related to the Apollo client example that was created here: #1626.

Users who are new to Remix, like myself and the company I work at, are tied into the old ways of doing things (old? perhaps just different ways :) ). These ways were explicitly highlighted by @ryanflorence here as being inefficient and more so, against the ways of how Remix does things. These points were directed towards the apollo client example but they also apply to many other things that one might approach.

A quick reference to Ryans points on that PR:

• On the initial SSR, getDataFromTree wipes out all the benefits of Remix's SSR approach.
  

• You can't fetch all data in parallel on the initial SSR
  

• You can't fetch all data/modules/css in parallel on client side transitions
  

• You can't prefetch pages the user is about to navigate to
  

• It ships a lot more JS to the client
  

• You can't model mutations in the UI as simple forms
  

Here is my original comment on the pr that I was hoping to get answered, as it's quite important for myself and for others.

Hi @ryanflorence, I feel like i'm stepping out of line by butting in on something that has nothing to do with me, but, I really wanted to understand more on some of the points you've mentioned here. At my company, we're about to adopt Remix for a big re-design of the application (for various reasons). We are heavily reliant on apollo and our mindset and paradigm are very different from what Remix is introducing, so, It will be a slow and potentially a not so straightforward path.

I'm having difficulties understanding the first 2 points you've mentioned, and both of which, I need to fully understand as we embark on to adopting Remix. Point 3 onwards, I think, is clear to why these are issues (it's pretty much the cons of client side logic). The first two points I can't wrap my head around because of my lack of knowledge here.

How does On the initial SSR, getDataFromTree wipes out all the benefits of Remix's SSR approach.? What approach are you talking about and what are the benefits being wiped out, and why?
Why can't the data be fetched in parallel? Whether it is apollo or just a regular fetch being awaited, in the end it's just a promise waiting to be resolved, no? What am I missing here?

CC @kentcdodds since you've been assigned here. I hope my tags don't add any weight to your work and that this post (and hopefully the reply) will be beneficial to others who might be in a similar situation to us.

[kiliman]

I believe what Ryan is alluding to is to keep Apollo on the server. Use loaders for queries and actions for mutations. Then your routes only need to useLoaderData to get the data instead of having to use Apollo hooks.

You can still leverage your knowledge of Apollo, just keep it on the server instead of in your route components.

Remember, normal components that are part of the route can still call userLoaderData to get access to the current route's data, or you can pass it to the components via props. useLoaderData is essentially reading the data out of Remix Context (standard React Context). You can also useMatches to get data for all active routes from anywhere in the React tree.

It may be helpful if you can ask specific questions on how to use Remix with Apollo.

[kentcdodds]

You won't. But you also won't need it because Remix will manage that for you. By the end of it, you'll have a faster app and a better user experience by relying on Remix in the client instead of Apollo.

[barbinbrad]

I've been fiddling around with this for a while now because we've got an existing GraphQL API that won't be going away, and while I definitely see the advantage of using loaders with raw queries (like the example) instead of useQuery + ssr, I think useMutation (especially the with the generated hooks) is still much better than raw queries in actions (in terms of DX and Typescript).

The reason I'm leaning towards the typed mutation hooks is that it's already typed, so if I want to send booleans, arrays and objects in my GraphQL payload, I don't have to coerce strings via FormData. I think something like a JSON field + io-ts is great if you don't have the types already being generated, but if you do it feels redundant.

I could be wrong, but it feels like if you've got a GraphQL backend, then it's better to use something like react-hook-form + codegen + generated hooks + a useSubmit with a lightweight action that forces a refetch after the mutation.

[marwan38]

I've been fiddling around with this for a while now because we've got an existing GraphQL API that won't be going away, and while I definitely see the advantage of using loaders with raw queries (like the example) instead of useQuery + ssr, I think useMutation (especially the with the generated hooks) is still much better than raw queries in actions (in terms of DX and Typescript).

The reason I'm leaning towards the typed mutation hooks is that it's already typed, so if I want to send booleans, arrays and objects in my GraphQL payload, I don't have to coerce strings via FormData. I think something like a JSON field + io-ts is great if you don't have the types already being generated, but if you do it feels redundant.

I could be wrong, but it feels like if you've got a GraphQL backend, then it's better to use something like react-hook-form + codegen + generated hooks + a useSubmit with a lightweight action that forces a refetch after the mutation.

We decided to go with apollo explicitly on the server side only. The reason being is that we have middleware and custom logic that's already working pretty well. The client has no access to apollo and purely uses the remix api. It's been working pretty alright for us.

[barbinbrad]

Oh that's interesting. I guess they way I'm thinking about was is just the opposite. So for mutations, do you send form data and then create the mutation variables in the action? To me that's the big annoyance. What's the advantage of using apollo on the server vs. something like this?

const api = {
  graphql: async <T>(
    request: Request,
    query: DocumentNode,
    variables?: Record<string, any>
  ): Promise<{ data?: T; errors?: GraphQLError[] }> => {
    const { name } = query.definitions[0] as ExecutableDefinitionNode;
    const requestBody: any = { query: print(query) }; // could also use query.loc?.source.body

    if (variables) requestBody.variables = variables;
    try {
      const response = await fetch(`${endpoint}?operation=${name?.value}`, {
        body: JSON.stringify(requestBody),
        headers: await api.getHeadersFromRequest(request),
        method: "POST",
      });

      if (response.ok) {
        return response.json();
      }

      return {
        errors: [
          {
            message: await response.text(),
          } as GraphQLError,
        ],
      };
    } catch (error) {
      const message =
        error instanceof Error ? error.message : "Unhandled error";
      return {
        errors: [
          {
            message: message,
          } as GraphQLError,
        ],
      };
    }
  },
}

[marwan38]

Oh that's interesting. I guess they way I'm thinking about was is just the opposite. So for mutations, do you send form data and then create the mutation variables in the action? To me that's the big annoyance. What's the advantage of using apollo on the server vs. something like this?

const api = {
  graphql: async <T>(
    request: Request,
    query: DocumentNode,
    variables?: Record<string, any>
  ): Promise<{ data?: T; errors?: GraphQLError[] }> => {
    const { name } = query.definitions[0] as ExecutableDefinitionNode;
    const requestBody: any = { query: print(query) }; // could also use query.loc?.source.body

    if (variables) requestBody.variables = variables;
    try {
      const response = await fetch(`${endpoint}?operation=${name?.value}`, {
        body: JSON.stringify(requestBody),
        headers: await api.getHeadersFromRequest(request),
        method: "POST",
      });

      if (response.ok) {
        return response.json();
      }

      return {
        errors: [
          {
            message: await response.text(),
          } as GraphQLError,
        ],
      };
    } catch (error) {
      const message =
        error instanceof Error ? error.message : "Unhandled error";
      return {
        errors: [
          {
            message: message,
          } as GraphQLError,
        ],
      };
    }
  },
}

It's a big difference, and yes, I just use regular forms. The advantage is that you're not serving additional js to the client, that can become quite a lot with not just apollo, but, also gql queries. This has been mentioned in either this thread or the issue posted here somewhere. Btw, in your example you're parsing the query runtime.. You can read more about that here. There's also the issue of the apollo ssr implementation that doesn't work well with the parallelization of loaders in remix. This was also mentioned here or that other thread.

The API using form data is way easier, and it's quite simpler. I'm a big fan of remix has brought to us and performance is one of it's big +'s.

[vladinator1000]

So is the takeaway here to rewrite everything to loaders and actions?

What about the benefits of Apollo cache?

It ships a lot more JS to the client

If we reframe this as a trade-off, I think downloading all of that JS allows you to download the cache, and have subsequent requests skip the SSR path, download a small quantity of data, or if the data is cached, skip the network completely.

I also found this Discord discussion on the subject https://discord.com/channels/770287896669978684/1230493730742730882

I'm trying to see if it's worth migrating for my Apollo, but so far it's unclear what a good way to do things is.

[sergiodxa]

You could use Apollo client inside your loaders and actions, in the loader use it to run GraphQL queries, in the action use it to run GraphQL mutations, then it can leverage the Apollo cache internally.