Forem: EF World Journeys

Computed local-only fields in Apollo Client

Josh Console — Thu, 30 Jun 2022 12:46:18 +0000

This article was also posted on eftech.com

One valuable feature of Apollo Client is local-only fields. These fields are redacted from an operation that is sent to the server by an application, and then computed and added to the server response to generate the final result. The Apollo docs clearly explain how to leverage this feature for local state management, but it's less clear on how to derive pure local-only fields solely from other fields on the operation result.

A (Contrived) Example

Suppose we have an operation that queries for the current user.

const USER_QUERY = gql`
  query User {
    user {
      id
      firstName
      lastName
      department {
        id
        name
      }
    }
  }
`;

We use the result of this operation in some UserProfile component to render a display name in the format of John Doe - Engineering team.

const UserProfile = () => {
  const { data } = useQuery(USER_QUERY);
  const displayName = `${data.user.firstName} ${data.user.lastName} - ${data.user.department.name} team`;

  return (
    <div>
      <ProfilePicture />
      <p>{displayName}</p>
      <ContactInfo />
    </div>
  );    
}

As time goes on, we find ourselves using this same displayName format in numerous places throughout our application, duplicating the same logic each time.

const BlogPost = () => {
  const { data } = useQuery(USER_QUERY);
  const displayName = `${data.user.firstName} ${data.user.lastName} - ${data.user.department.name} team`;

  return (
    <div>
      <BlogTitle />
      <p>Written by {displayName}</p>
      <BlogContent />
    </div>
  );
}

We consider how best to reuse this formatted name across our application. Our first thought might be a server-side resolver, but this isn't always feasible. We might want to make use of client-side data - local time, for example - or maybe our calculation will use fields from a variety of subgraphs that are difficult to federate between. Our next thought is a React component, but this won't work very well either. We want a consistent format for our displayName, but usage or styling might vary considerably depending on context. What about a hook, then? Maybe a useDisplayName hook that encapsulates the query and display logic? Better, but inelegant: we'll probably find ourselves invoking both the useQuery and useDisplayName hook in the same components, over and over. What we'd really like is not logic derived from the query result, but rather logic incorporated in the query result.

A Solution

The first requirement for a local-only field is a corresponding field policy with a read function in our cache. (Technically, a field policy could be omitted in favor of reading to and writing from the cache, but we'll save that for another post.)

const cache = new InMemoryCache({
  typePolicies: {
    User: {
      fields: {
        displayName: {
          read(_) {
            return null;  // We'll implement this soon
          }
        }
      }
    }
  }
});

The first argument of the read function is the existing field value, which will be undefined for local-only fields since by definition they do not yet exist.

The other requirement for a local-only field is to add it to the operation with the @client directive. This directs Apollo Client to strip the field from the server request and then restore it to the result, with the value computed by the read function.

const USER_QUERY = gql`
  query User {
    user {
      id
      firstName
      lastName
      displayName @client
      department {
        id
        name
      }
    }
  }
`;

This field will now be included in the data field returned by our useQuery hook, but of course, it always returns null right now. Our desired format requires three fields from the server response: the user firstName and lastName, and the department name. The trick here is readField, a helper provided by the second "options" argument of the read function. This helper will provide the requested value (if it exists) from the parent object of the field by default, or from another object if it's included as the second argument. This helper will also resolve normalized references, allowing us to conveniently nest readField invocations. Note that we can't really force the operation to include the fields on which the local-only field is dependent, and thus readField always has the potential to return a value of undefined (even if it's a non-nullable field).

const cache = new InMemoryCache({
  typePolicies: {
    User: {
      fields: {
        displayName: {
          read(_, { readField }) {
            // References the parent User object by default
            const firstName = readField("firstName");
            const lastName = readField("lastName");
             // References the Department object of the parent User object
            const departmentName = readField("name", readField("department"));

            // We can't guarantee these fields were included in the operation
            if (!firstName || !lastName || !departmentName) {
              return "A Valued Team Member";
            }
            return `${data.user.firstName} ${data.user.lastName} - ${data.user.department.name} team`;
          }
        }
      }
    }
  }
});

Now, it's trivial to use this formatted display name anywhere in our application - it's just another field on our query data!

const BlogPost = () => {
  const { data } = useQuery(USER_QUERY);

  return (
    <div>
      <BlogTitle />
      <p>Written by {data.displayName}</p>
      <BlogContent />
    </div>
  );
}

Bonus: Local-only fields with GraphQL Code Generation

It's trivial to include local-only fields if you're using graphql-codegen (and if you're not using it, it's pretty easy to get started, too.). All you need to do is extend the type to which you're adding the local-only field in your client-side schema file.

const typeDefs = gql`
  extend type User {
    # Don't forget to return a default value
    # in the event a field dependency is undefined
    # if the local-only field is non-nullable
    displayName: String!
  }
`;

Optimizing React Native offline mode using Apollo Cache Persist

Nico Bermudez — Tue, 24 Aug 2021 22:43:41 +0000

Having offline mode is extremely important for most mobile apps in the market. For us as a travel business, it is vital. Due to the nature of our industry, a lot of our users will simply not have access to cellular connection or wifi. Therefore, one of the most important aspects of our mobile app is to allow our users to be able to see information about their tour, while they're on tour. We want to be able to have them access their day to day itinerary, their flights or hotels, or any other important information about the tour, at any time.

Background

In the past, we've explored different options, including maybe the most popular approach which is to use SQLite. This is a fine solution, but it can get pretty tedious in terms of extra configuration and needing to read and write manually directly from this database.

In this simple todo app example taken from Expo, we need to manually read and write on initial render:

useEffect(() => {   
   db.transaction((tx) => {
      tx.executeSql("create table if not exists items (id integer       primary key not null, done int, value text);");    
   }); 
}, []);

Here, we need to initialize our table if we haven't done so yet.

Same goes for any other function that needs to write to the db. Let's take a look at adding a todo below.

const add = (text) => {
   if (text === null || text === "") {
      return false;    
   }     
   db.transaction((tx) => {        
      tx.executeSql("insert into items (done, value) values (0, ?)", [text]);        
      tx.executeSql("select * from items", [], (_, { rows }) =>          console.log(JSON.stringify(rows)));      
   }, null, forceUpdate);  
};

In this function, we are directly calling our database to insert our new todo items, as well as then read them.

While all of this effectively works, you can quickly see how this can become difficult to maintain for larger apps.

Apollo Client

With our current architecture, we have over 40 federated GraphQL micro-services. So we share these API's amongst all of our clients, including both web and mobile. We consume these API's using Apollo Client. "Apollo Client is a comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. Use it to fetch, cache, and modify application data, all while automatically updating your UI." For the purposes of this blog post, I won't get into the details of what Apollo accomplishes for us, but you can read more about it in their docs.

One of the main benefits from Apollo is its out of the box caching implementation. They store all of your query results in a local, normalized, in-memory cache. What this means for your mobile app is that if you navigate to a screen, fetch the data, and then return to that screen (all while your app is still open), you won't need to re-fetch all of that data again from the network. Instead, Apollo is simply smart enough to get that data from the in-memory cache.

There's a lot of different strategies in the way you should properly cache data using Apollo Client. You can configure how you want to balance fetching data from your cache through Apollo's fetchPolicies. It's also very important to make sure your data is being cached properly. Apollo does this by generating a cache ID using a typename and an "id or _id" field on your data object. So it's vital that you specify a unique identifier on each of your data models, otherwise, you can specify how you plan on merging those objects in your typePolicies.

Apollo Cache Persist

So now we should have our cache properly working, but we notice that once you close out the app, you'll be forced to fetch from the network again, since Apollo Client simply provides an in-memory cache. Going back to earlier, this won't work for us. Travelers on the road need to be able to access their data offline, which means once they close out their app, they won't be able to fetch data from the network and they also won't have the cache available in memory. So what do we do?

We can use Apollo Cache Persist! Apollo Cache Persist is a library which seamlessly saves and restores your Apollo cache from persistent storage.

The setup is extremely simple. First, we need to decide which configurations we want to add. For example, if we want to change the maxSize, which defaults to 1MB, we can set this here. You can reference the additional configuration here. For our example, we'll focus on just providing our storage provider, which will be AsyncStorage.

import { ApolloClient, InMemoryCache } from "@apollo/client";
import AsyncStorage from "@react-native-async-storage/async-storage";
import { AsyncStorageWrapper, CachePersistor } from "apollo3-cache-persist";
import { useEffect } from "react";
const cache = new InMemoryCache({
   // your cache configuration
});
const persistor = new CachePersistor({
   cache,
   storage: new AsyncStorageWrapper(AsyncStorage),
});
// then later when initializing your App
useEffect(() => {
   async function initializeCache() {
      await persistor.restore();
      const client = new ApolloClient({
         // your Apollo Client initialization
      });
      client.onClearStore(async () => {
         await persistor.purge();
      });
   }
   initializeCache();
}, []);

First, we set up our initialize our CachePersistor from apollo-cache-persist. We reference our cache by passing it in, and we determine our storage and initialize our AsyncStorageWrapper with AsyncStorage from @react-native-async-storage/async-storage. Then, in our app initialization, we restore our cache using persistor.restore(). This takes care of the hard work for us by checking against Async Storage and seeing if we have any data that we need to restore as part of our cache. Once we have this part setup, we can close our app and you'll notice you have data available without needing to make network requests (Assuming you already fetched at least once before and have it in your cache). You can switch to airplane mode to properly test this out.

Since we have proper authentication, we still have one more step. We need to make sure this data is cleared from storage on logout because of security and to prevent any bugs with data from any other users logging in using the same device. In your app initialization, we can add client.onClearStore(async () => { await persistor.purge() });, which now allows us to purge our async storage whenever we clear our Apollo Client store. So now, when we sign our users out, we can simply clear the store.

<Button
   title="Sign out"
   onPress={async () => {
      await client.clearStore();
   }}
/>

That's it! Now our travelers are happy on the road being able to access their tour data and now you have your mobile app working for offline mode for all of your data and making the user experience that much better.

Example Repo

You can find a working demo here. It is made so you can see a working app with the examples we've outlined in this blog post.
https://github.com/nicobermudez/expo-offline-app-example

Thanks for reading 👋

If you have any questions, please feel free to comment below.

We're hiring! If you're interested in pursuing a Career with us, feel free to reach out to me on LinkedIn.

NestJS Dependency Injection with Abstract Classes

Josh Console — Tue, 18 May 2021 20:43:27 +0000

This article was also posted on eftech.com

A seemingly common complaint regarding NestJS and TypeScript is the absence of interfaces in runtime code (since interfaces are removed during transpilation). This limitation prevents the use of constructor-based dependency injection and instead necessitates use of the @Inject decorator. That decorator requires us to associate some "real" JavaScript token with the interface to resolve the dependency - often just a string of the interface name:

/* IAnimal.ts */
export interface IAnimal {
  speak(): string;
}

/* animal.service.ts */
export class Dog implements IAnimal {
  speak() {
    return "Woof";
  }
}

/* animal.module.ts */
@Module({
  providers: [{
    provide: "IAnimal",
    useClass: Dog,
  }]
})
export class AnimalModule

/* client.ts */
export class Client {
  constructor(@Inject("IAnimal") private animal: IAnimal) {}

  // Later...
  this.animal.speak();
}

This approach is adequate, but the "IAnimal" magic string is a little fragile and not actually associated with the interface. A modest improvement can be made by exporting a token with the interface:

/* IAnimal.ts */
export interface IAnimal {
  speak(): string;
}

export const IAnimalToken = "IAnimal";
// or slightly better...
export const IAnimalToken = Symbol("IAnimal");

/* animal.module.ts */
@Module({
  providers: [{
    provide: IAnimalToken,
    useClass: Dog,
  }]
})
export class AnimalModule

/* client.ts */
export class Client {
  constructor(@Inject(IAnimalToken) private animal: IAnimal) {}

  // Later...
  this.animal.speak();
}

At least now the token reference is consistent. Still, manually injecting tokens like this can be cumbersome and conceptually unsatisfying. What we would really like is a true JavaScript object in the place of the interface, which we can reference universally at runtime. What we would really like is...an abstract class!

/* IAnimal.ts */
export abstract class IAnimal {
    abstract speak(): string;
}

/* animal.service.ts */
// You can implement an abstract class without extending it!
export class Dog implements IAnimal {
  speak() {
    return "Woof";
  }
}

/* animal.module.ts */
@Module({
  providers: [{
    provide: IAnimal,
    useClass: Dog,
  }]
})
export class AnimalModule

/* client.ts */
export class Client {
  constructor(private animal: IAnimal) {}

  // Later...
  this.animal.speak();
}

Now a single, "real" JavaScript reference is used throughout the application to resolve the dependency. Whether or not the minor inconvenience of token-based dependency injection justifies this usage of abstract classes is a separate question. If you're feeling lazy, though, this is a convenient option!