Copy this bookmark:



bookmark detail

(17) The Past, Present, and Future of GraphQL Native - Nick Schrock @ GraphQL Europe - YouTube
* nick schrock, graphql co-creator, 2009-2017.
* "revenge of the monolith"
* original super-graph was 1:1 mapping to business/domain layer, from an assumed monolith (PHP/ent), driven by very backend team, delivered JSON/no client, no javascript/react, client was iOS native
* 1st open resource graphql was to JS ecosystem, but just due to relay, which was react+graphql glued together. leverage the react brand. very domain agnostic, JS focused, assumed microservices.
* JS/frontend loves it, backend hates it.
* see AirBNB, reconciling graphql & thrift. cultural problems. but ironically graphql type system can structure your clients.
* this context led to front-end developers sneaking a very small layer of graphql on top of unwitting/unconvinced backend developer micro-services
* micro-services: "those who don't learn from history will repeat it" ... "those who learn too much from history are doomed to overreact to it": history of software engineering is devs overreacting to horrific pain.
* SQL to NoSQL, data warehouse to data lake, templates to JSX
* micro-service is an over-correction. they are a tool, not a goal. goal is not "to move to micro-services". no, the goal is to "deliver business value".
* what separation are micro-services for? business logic verticals, repo verticals ("more git repos than engineers is insanity at large", "just use folders"), org boundaries (conway's law, but then reorgs lead to orphaned micro-services and repos), language choices (your org should bet on one, two, maybe three languages b/c code reuse is good), scaling constraints (this is a good reason).
* Attempting to decouple what is actually coupled is a terrible idea. Spreading business logic across systems. You'll end up with a distributed monolith.
* "Your affection for GraphQL is your subconscious telling you that it wants the good parts of your monolith back". You want a cohesive view of your business.
* future of GraphQL native: instead of zero-logic graphql, make a beefier graphql. talk to super-scalable store, talk to other micro-services, talk to capability-based services.
* very few graphql backends from scratch: we need fatter gateways. move cross-system business logic into the gateway. vertically-integrated toolkits. scaffolding/code layout. "rails for graphql".
* pivot graphql back to be a balance between back-end/front-end and not front-end only
july 2018 by sh
view in context