DEV Community: Rodrigo Figueroa

Simple and to the point stitching remote schema into local schema with Apollo Server

Rodrigo Figueroa — Thu, 23 May 2019 12:28:37 +0000

Cover photo by Two Paddles Axe and Leatherwork on Unsplash

Scenario: You have your first schema running on your Apollo server but a new GraphQL API shows up and you need to work with it in your client right away without too much orquestation.

This tutorial will try to get you from point A to point B as fast as possible. We will make a small API to solve our problem and for future reuse. You can use it right away but we will be explaining each piece step by step to get the inner workings.

A note:
Stitching local with remote schemas, I think, works perfectly in the situation where you are starting to stitch. Why? Because you have your first schema already up and running. If a GraphQL service shows up just append this new remote schema on top to start consuming it.

I'm telling you this because there is another way of working this out AFAIK but we would need to start another microservice to serve as a proxy to both of our APIs (local and remote schemas will be both remote now). I think this could work well when you have too many services but for a start let's just use our current server and enhance it with a new remote schema on top of it. It's faster, it's one less service to run, it works.

Right now supposedly we have this setup for our server.

const server = new ApolloServer({ typeDefs, resolvers });

server.listen().then(({ url }) => {
  console.log(`🚀 Server ready at ${url}`);
});

We are going to replace previous code with this module.

const { ApolloServer, makeExecutableSchema } = require('apollo-server')
const { HttpLink } = require('apollo-link-http')
const {
  introspectSchema,
  makeRemoteExecutableSchema,
  mergeSchemas,
} = require('graphql-tools')
const fetch = require('node-fetch')

async function startServer({
  localSchema: { resolvers, typeDefs },
  remoteSchema: { uri },
}) {
  const remoteHttpLink = new HttpLink({
    uri,
    fetch,
  })

  const remoteSchemaInstrospection = await introspectSchema(remoteHttpLink)

  const remoteSchemaExecutable = makeRemoteExecutableSchema({
    schema: remoteSchemaInstrospection,
    link: remoteHttpLink,
  })

  const localSchema = makeExecutableSchema({
    typeDefs,
    resolvers,
  })

  const mergedSchemas = mergeSchemas({
    schemas: [localSchema, remoteSchemaExecutable],
  })

  const server = new ApolloServer({ schema: mergedSchemas })

  return await server.listen()
}

module.exports = startServer

First we are going to make a request to our external GraphQL API. We pass to the config object our uri and a reference to the fetch library.

  const remoteHttpLink = new HttpLink({
    uri,
    fetch,
  })

We use the instrospectionSchema function to retrive the schema from our remote GraphQL service. Only argument is our previously defined HttpLink instance.

  const remoteSchemaInstrospection = await introspectSchema(remoteHttpLink)

We got our schema after introspection but now we are still missing making it executable. So it's a two step process. Being executable will enables us to later on merge it with our local one.

  const remoteSchemaExecutable = makeRemoteExecutableSchema({
    schema: remoteSchemaInstrospection,
    link: remoteHttpLink,
  })

Next we create our local schema using makeExecutableSchema passing a config object as argument with our typeDefs and resolvers just like the typical server config object we saw at the beginning.

const localSchema = makeExecutableSchema({
  typeDefs,
  resolvers,
})

Merge both schemas with mergeSchemas

const mergedSchemas = mergeSchemas({
  schemas: [localSchema, remoteSchemaExecutable],
})

Pass it to our server in its config object and start it invoking listen as usual.

const server = new ApolloServer({ schema: mergedSchemas })

return await server.listen()

We are done with the module breakdown 🙌. Now let's use it!

startServer has as argument one config object that has two properties:

localSchema Object with two keys. resolvers and typeDefs.
remoteSchema Object with one key.uri: string of our external GraphQL API.

startServer({
  localSchema: {
    resolvers,
    typeDefs,
  },
  remoteSchema: {
    uri: 'https://01uhb.sse.codesandbox.io/',
  },
}).then(({ url }) => {
  console.log(`🚀  => Server ready at ${url}`)
})

And that's it. Now our current server has both of our schemas available.

Play with it yourself. Here's a codesandbox with the GraphQL server and our module in action. We have two queries. hello is local and the goodbye query is being merge.

You can grab the external Graphql service here: https://codesandbox.io/s/apollo-server-01uhb

This is just the beginning. You have a lot to tweak and learn about stitching from here.

What if some types repeat between schemas?
What if I need to use the result type of one query in another one as an argument?

New challenges bring new ways to extend and work with combined schemas.
Hope this tut is a good first step into your stitching journey!

Clear my mind (and yours) about render props once and for all

Rodrigo Figueroa — Fri, 01 Mar 2019 15:27:18 +0000

Photo by Garrett Sears on Unsplash

I have seen lots of render props explanations out there in the wild but I was still not getting it 'cristal clear'. Sometimes you need to step in and figure it out by yourself. So this is my thinkering around it. Hope it serves you too.

You render your prop. That prop is a function that returns jsx.

Your render function is the one that returns the invocation of the function that got defined and passed as a prop which in turn returns the jsx that gets finally rendered.

<Hello
  render={() => (
      <p>El barto was here</p>
  )}
/>

class Hello extends Component {
  render() {
    return this.props.render();
  }
}

You abstract and simplify this by using the children prop as your function. children is what you make of it. This time it gets defined as a function and just like before it returns your jsx as well.

<Hello>
  {() => <p>El barto was here</p>}
</Hello>
/>

class Hello extends Component {
  render() {
    return this.props.children();
  }
}

Your render prop function arguments

They come from your component. From the invocation of the function in the render method. Pass as arguments to it data to use in the render of your component.
This is business as usual but since the definition is not per se in your component, but anywhere in your codebase where you are using it you can get lost. Just a fresh reminder, that helps.

<Hello>
  {(msg) => <p>{msg}</p>}
</Hello>
/>

class Hello extends Component {
  render() {
    return this.props.children("el barto was here");
  }
}

Your component props

They get passed to the component and used as usual. Nothing new here.

<Hello hide>
  {(msg) => <p>{msg}</p>}
</Hello>
/>

class Hello extends Component {
  render() {
    return !this.props.hide ? this.props.children("el barto was here") : null
  }
}

When to use it? For what?

When you get right the workings of the pattern you get to the next phase of 'still not getting it 100%' which is when to use this thing? We are almost there. We know how this thing works, we can get it when using a library that implements it. But you should use it too! We can implement it for ourselves but we are missing clarity as to when. For that we need the last piece of the puzzle right.

For this part I must say I got it thanks to Jared Palmer. With this video you get to implement a small Formik implementation that when done gives you a clear idea about the usefulness of the pattern. You get there by going through the process of turning a component that has no render prop to one that does.

Here's a companion codesandbox I made to play with the code while you are watching. Fork it, change it, finish it. The errors piece is missing. Hope this gives you a head start into really getting it once and for all. Best of luck! 🍀

Better Reusable Media Queries on Emotion

Rodrigo Figueroa — Wed, 20 Feb 2019 01:16:47 +0000

When wanting to use reusable media queries on Emotion you get in the official docs the following example:

/** @jsx jsx */
import { jsx, css } from '@emotion/core'

const breakpoints = [576, 768, 992, 1200]

const mq = breakpoints.map(
  bp => `@media (min-width: ${bp}px)`
)

render(
  <div>
    <div
      css={{
        color: 'green',
        [mq[0]]: {
          color: 'gray'
        },
        [mq[1]]: {
          color: 'hotpink'
        }
      }}
    >
      Some text!
    </div>
    <p
      css={css`
        color: green;
        ${mq[0]} {
          color: gray;
        }
        ${mq[1]} {
          color: hotpink;
        }
      `}
    >
      Some other text!
    </p>
  </div>
)

First you set your breakpoints in an array.

const breakpoints = [576, 768, 992, 1200]

Then you map those values to a string that will have the signature for each of your media queries. This is the piece of code that reusable media queries simplify for you.

const mq = breakpoints.map(
  bp => `@media (min-width: ${bp}px)`
)

Finally you can easily use that media query by just using the mq variable and grabbing the index you want to use.

${mq[0]} {
 color: gray;
}

This is fine but we can do better.

With this approach I found that when setting my media queries they didn't told me about the breakpoint being used. mq[0] is mobile, but what about mq[3]. Is it Ipad, a bigger mobile phone, or desktop?

I needed a way to be more declarative about it. Clearer as to what breakpoint am I using or needing to implement.

So long story short I leave you with the same previous example of reusable media queries but with a new implementation.

/** @jsx jsx */
import { jsx, css } from '@emotion/core'

const bp = {
  small: 500,
  large: 1200
};


const mq = n => {
  const bpArray = Object.keys(bp).map(key => [key, bp[key]]);

  const [result] = bpArray.reduce((acc, [name, size]) => {
    if (n === name) return [...acc, `@media (min-width: ${size}px)`];
    return acc;
  }, []);

  return result;
};



render(
  <div>
    <div
      css={{
        color: 'green',
        [mq('small')]: {
          color: 'gray'
        },
        [mq('large')]: {
          color: 'hotpink'
        }
      }}
    >
      Some text!
    </div>
    <p
      css={css`
        color: green;
        ${mq('small')} {
          color: gray;
        }
        ${mq('large')} {
          color: hotpink;
        }
      `}
    >
      Some other text!
    </p>
  </div>
)

We are now defining breakpoints with an object. We can name our breakpoints with a key and then set the value. It's a plain old object that will give us way better use than the previous array.

const bp = {
  small: 500,
  large: 1200
};

Also note that this time around we can be more flexible about the order too. It won't matter as compared with previous version where changing order in array would mess breakpoint you think you are using but you are not.

const bp = {
  small: 500,
  smaller: 300,
  large: 1200,
  iphone4: 320
};

Next we create a method that will turn the bp object into an array of tuples with name of breakpoint and value of width pairs. Then we will reduce it to get an array with one string that has the signature for the media query you passed as the n argument just like the Emotion docs previous example did.
We finally destructure that array string value into a result variable that we will return.

const mq = n => {
  const bpArray = Object.keys(bp).map(key => [key, bp[key]]);

  const [result] = bpArray.reduce((acc, [name, size]) => {
    if (n === name) return [...acc, `@media (min-width: ${size}px)`];
    return acc;
  }, []);

  return result;
};

So with this config we can now define and call breakpoints by name in a easy and concise way but also explicit about what we are changing.

        ${mq('small')} {
          color: gray;
        }
        ${mq('large')} {
          color: hotpink;
        }

React Day Berlin 2018 Notes - The New Hotness: An Exploration of React Exciting New Features -- Ken Wheeler

Rodrigo Figueroa — Wed, 19 Dec 2018 15:27:04 +0000

https://youtu.be/kPXJ5ERg9Wo?t=1216

Ken Wheeler gave us a spin and fresh look into all new in React these days from React 16.6 to 16.7-alpha.

React 16.6

React.memo

If you wanted to optimize class components you used React.pureComponent

But for functional components you didn't have that optimization.
Now if you wrap your functional component in React.memo it becomes a pure component.

React.lazy

The argument of React.lazy is a function that returns a component with the import.
The import directive tells your bundler to code split.

React.lazy wraps this in a supensifier. Now your code split is supensified.

If you throw a component in this example is going to wait to load first.

ContextType

To start get that context object at the top level

In a class component you can set the static contextType property and feed it that top level context object and now its available at this.context

React 16.7

Suspense

https://youtu.be/kPXJ5ERg9Wo?t=1663
A way to not show a spinner before certain amount of time (e.g 1 second) using maxDuration

Play with suspense with this lib by Jared Palmer.
http://github.com/palmerhq/the-platform

Hooks

A way to write function based components with class component capabilities.

New feature available in 16.7.0-alpha

Install with @next.

To play with it: Install create react app create-react-app appName & yarn add react@next react-dom@next, or open a code sandbox and update these packages to the latest ones.

There's different Hooks. We will look into these 4: useState, useEffect, useRef, useContext

useState

You are able to have state in your functions:

function MyComponent() {
   let [count, setCount] = useState(0);
   return [
    <p>{count}</p>
    <button onClick={() => {
      setCount(count => count + 1)
    }}>
      increment
    </button>
   ]
}

We have array destructuring let [count, setCount] = useState(0);
The useState(0) hook is returning an object with count as your value and setCount as the setter of the value. and the argument in useState(0) it's your initial state.

setCount works like setState

What's nice is that I can do it more than once.

function MyComponent() {
   let [count, setCount] = useState(0);
   let [enabled, setEnabled] = useState(false); // <-
   return [
    <p>{count}</p>
    <button onClick={() => {
      setCount(count => count + 1)
    }}>
      increment
    </button>
   ]
}

useReducer

https://youtu.be/kPXJ5ERg9Wo?t=2064
Also the state hook is convenient for another hook called useReducer which is a kind of build in Redux.

If you use Redux you are probably used to this style of reducer:

useReducer accepts your reducer as first argument, and initial state as second argument.
On destructuring dispatch is your setter.

There you have it. Build in Redux.

There are some gotchas on Hooks. When you call set with useState that doesn't merge
https://youtu.be/kPXJ5ERg9Wo?t=2129

useEffect

It's a way to do side effects inside your functional components. It's tecnically a replacement for componentDidMount, componentDidUpdate and componentWillUnmount but it's more than that.

In the following code console.log it's going to get called when the component mounts or updates

function MyComponent() {
  useEffect(() => {
    console.log('mount/update')
  });

  return (
    <p>Hey!</p>
  )
}

Inside the function you are passing as argument to useEffect, if you return a function, that is your unmount.
So if you subscribe to a subscription this is where you unsubscribe.

function MyComponent() {
  useEffect(() => {
    console.log('mount/update');
    return () => console.log('unmount')
  });

  return (
    <p>Hey!</p>
  )
}

The second argument you pass to useEffect it's called dependencies. If any of those dependencies change, the function (that is your first argument) will run. If it doesn't change, it won't run.
It will run at least one with or without this second argument but if you added it will act as a trigger to re run it.

useRef

Probably you are going to be using it a lot.
It's not just the ref on the component. You can use ref to get a reference to any value.

The tipical ref use case: define useRef and pass it as a ref to the input.

function MyComponent() {
  const myRef = useRef(null)
  return(
    <input ref={myRef}>
  )
}

Then you can do what you need, with it. e.g focus it.

useContext

You have a provider higher up in the tree, then you create a context. After that you can feed that same level context object and get the latest value out of it.

function MyComponent() {
  const { name } = useContext(MyContext)
  return (
    <p>{name}</p>
  )
}

Rules of hooks

Only call hooks at the top level. You don't want to wrap them in if's or any conditional logic. You call it at the top level of the function
Only call hooks from React functions (components or custom hooks)

Custom Hooks

Custom hooks are just functions with hooks in them.

Here you can use useEffect and useState in the same function.

function useMounted() {
  let [mounted, setMount] = useState(false);
  useEffect(() => {
    setMount(true);
    return () => {
      setMount(false)
    }
  })
  return mounted
}

You can return or not, do whatever you want.

To use it:

function App() {
  let mounted = useMounted();
  return mounted ? <p>suh dude</p> : null;
}

Why hooks are dope

Clases were tricky to optimize. This hook style opens the door for optimizations.
Less code on both write and compile sides.
More readable, better organization
The organization of your values and where they update it's better.

Demo time

https://youtu.be/kPXJ5ERg9Wo?t=2544
Really cool drum machine demo with a complete tour of the codebase. You will find out about the hook pattern to return components themselfs from hooks and more.

Resources

To see more examples of hooks checkout http://github.com/rehooks

Refetching in React Native with 1 line of code

Rodrigo Figueroa — Tue, 09 Oct 2018 14:15:03 +0000

Coming from a Vue.js background I have experienced components that unmont every time you navigate to another route/component. So as you can see using lifecycle methods like mounted or created was a common pattern to rerun logic if needed. You may need this e.g. in a news feed if you get back to the feed from a feed item screen and you need to show the newest feed from your API.

So back to React Native I found myself in this new scenario where components do not mount/unmount from screen to screen. So what to do? Turns out that the solution was in the navigation.

I am using React Navigation which enables you to emits events to screen components that subscribe to them. With that functionality you can use the event that best suit you. You get willFocus, didFocus, willBlur, and didBlur.

In my particular use case I needed to refetch when coming back from the previous screen. When the user pressed that back button I needed to reflect the changes so I used willFocus to fetch right away, before the render started.

I thought of using willBlur on the feed item screen before returning to the main feed saving the fetch response on store but willFocus worked just fine.

Going to the point, to solve refetch that one liner you need is:

this.props.navigation.addListener( "willFocus", e => this.fetch())

You can call this listener on a new property of your class or in a lifecycle method.

How you fetch as always is up to you but with React Navigation and listeners your refetching is plain and simple.

There are other use cases where solutions like Relay’s QueryRenderer will be what you need. This could involve more complex scenarios such as needing foreground/background fetching, but for now and for me this was all I needed. Hope it helps you too. Happy refetching.