Swappable operation implementations

[pmelab]

Description of changes

• Introduce a new system for swapping execution of GraphQL operations. The new shared package @amazeelabs/executors allows to register execution functions for specific GraphQL operations and parameter combinations.
• Unify all data-access to use useOperation and this new system under the hood.

Note: The package is currently part of the PR, but will be moved to silverback-mono before merging.

Motivation and context

This approach solves two problems:

1. Take out the guesswork "where" data comes from in UI components. Right now, it depends on the implementation. Gatsby data comes from props, dynamic queries from useOperation. This binds the UI to the implementation and makes it harder to use components in other environments (e.g. previews). Now every data operation has a GraphQL operation in the schema package and the UI component always uses useOperation and the implementation (Gatsby, Decap, Next ...) controls how the query is resolved.
2. Make it easier to swap out data sources for different purposes, even based on parameter matching (e.g. pre-render page 1 of content hub, resolve others with http-request to Drupal).

Use cases:

• preview handling (drupal, decap ...)
• simplify data-mocking in storybook
• pre-rendering of listings
• injection of global data (menus, breadcrumbs) without prop-drilling

How has this been tested?

• Manually
• Unit tests
• Integration tests

[Leksat]

Looks great in general!

[Leksat]

devDependencies?

[Leksat]

TS function overloading does not always play well. For example, guess the inferred types:

type FirstParam = Parameters<typeof registerExecutor>[0];
type LastParam = Parameters<typeof registerExecutor>[2];

Answer

I would suggest using a single object parameter:

export function registerExecutor(args: RegistryEntry) {
  registry.push(args);
}

IMHO it would make make the function calls easier to read:

registerExecutor({ executor: myFunc, id: 'foo-bar' });

---

Or am I missing something?

[pmelab]

I thought it would produce a more natural API:

// register an executor that matches everything
registerExecutor(iDoEverythingOverHttp);
// register one for a specific operation;
registerExecutor(MyOperationId, myOperationImplementation);
// for a specific set of input:
registerExecutor(ContentHubQuery, {page: 1}, staticFirstPage);

Compared to:

// register an executor that matches everything
registerExecutor({executor: iDoEverythingOverHttp});
// register one for a specific operation;
registerExecutor({id: MyOperationId, executor: myOperationImplementation});
// for a specific set of input:
registerExecutor({id:ContentHubQuery, args: {page: 1}, executor: staticFirstPage});

I'm not sure if it has to be possible to infer types here, since theOperation* type helpers are available to infer return types and variables:

type first = AnyOperationId;
type second = Partial<OperationVariables<first>>;
type third = () => Promise<OperationResult<first>>;

But I also don't have a very strong opinion on this. How strong are yours? Should we pull in more voices?

[Leksat]

What's the return type?

[Leksat]

BTW, in my pet projects I use '@typescript-eslint/explicit-function-return-type': 'error' eslint rule. But not sure if it will play well at work 🤔

[pmelab]

Thats a great discussion point. Explicit means a type error is found earlier, not potentially through three levels of generic functions that infer something.