theJC

import java.io.IOException;
import java.net.HttpURLConnection;
import java.util.Objects;
import java.util.function.BiConsumer;
import java.util.function.Function;
import java.util.function.Predicate;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

theJC

Dealing with slow resolvers in a subgraph

This post illustrates an issue our developers have run into when trying to convert their service from a traditional BFF into a federated subgraph.

It's unclear how to maintain the most optimal set of network waterfalls throughout the combined backend while keeping an idiomatic client-facing schema. Specifcially, if a resolver in a selection set to a subgraph is slow, it blocks the yielding of the subgraph response.

# router -> subgraph query
query MyQuery__subgraph__0 {
 stuff {

theJC

MacOS X + oh my zsh + powerline fonts + visual studio code (vscode) terminal settings

Thank you everybody, Your comments makes it better

Install oh my zsh

http://ohmyz.sh/

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"