Skip to content

Instantly share code, notes, and snippets.

@kaievns

kaievns/notes.md

Last active January 26, 2018 08:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kaievns/f9ab33b687370656af12d37808c807a2 to your computer and use it in GitHub Desktop.
Save kaievns/f9ab33b687370656af12d37808c807a2 to your computer and use it in GitHub Desktop.
Download ZIP
Apollo GraphQL experience notes
Raw
notes.md
  1. Overall sense of instability. Considering that there are basically two grown up implementations for react out there Relay and Apollo. Seing issues like those in apollo make me feel uneasy. References: apollographql/react-apollo#1286 apollographql/react-apollo#556 https://github.com/apollographql/apollo-test-utils/issues/39

there are multiple variations of each throught the apollo related packages. the most disturbing is lack of response or sense of community ownership. it gives an impression of one guy manning half of the leverages

  1. The bloatness. It's obviously subjective, so i'll just to describe where my head at with this.

I like what you've done on the server side. In node it's just a straight up plug and play express middleware. Or take the apollo chrome plugin. Easy done. In react frontend though, I'm forced to import 6 packages with significant added weight, before I can get anywhere. And then I'm basically aimlessly copypasting your code to bootstrap the thing.

I mean, don't get me wrong, I can clearly see you're trying to bring solid OO design into the system, kudos for that. But, all this effort to essentially POST a JSON blob to /graphql. I mean, it will take me 10 lines of code to replicate most of what i need from apollo client, and another 20 lines to have a bare bone version of react-apollo. It won't obviously be all that fancy, but it will do 90% of what i need. hence i'm having a lot of trouble justifying all this complexity to get the extra 10% of features.

I know you've done a lot of work slicing apollo 1 into pieces and making it more shallow. But in my view it's more of reshuffling of the problematic pieces around rather than building a solid point and shoot dev experience.

  1. Testing story is somewhat rudimentary. Me and my company we happen to write a lot of tests. I just love small shops that optimise for solid testing practices as way to reduce wasted time on debugging/support. Having a solid robust integration testing story is a must for me. Yet apollo 1 wasn't offering anying beyond random response mocks (which btw, didn't work half of the time). And apollo 2 completely screwed up the tests suport, and then went for months without aknowleding the issue.

I've spiked a small package to fill the void for me https://github.com/MadRabbit/graphql-mock it's far from perfect, but it might give you some ideas of what type of testing we do and expect to be supported. it's essentially sort of nock for graphql.

  1. TypeScript support, was a constant pain in the neck for us. this graphql<T1, T2, T3>() thing is a disaster when you have sandwitch like this
connect(
  graphqlFetchItem(
    graphqlMutateItem(
      OriginalComponent
    )
  )
)

and it seems as it just turned into graphql<T1, T2, T3, T4>(). I know you added the Query component, but i'm not very jazzed up about it. It really feels more like your own experiment into functional react children than a solution to the problem. Even though TypeScript is an a-hole when it comes to supporting HOC in decorators, I still would prefer a decorator-ish solution to the problem than using explicit components within the app. Because it makes it easier to reason about complex applications data flow, and pays off long term in reduced debugging/maintenance time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment