SlideShare a Scribd company logo
BUILD THE API
YOU WANT TO SEE
IN THE WORLD
I’m going to talk to you
about GraphQL.
Warning: I’m going to
say the word GraphQL
more than you’ve ever
heard it before.
This is a talk about the
problems GraphQL can
solve in the real world.
Why did I use GraphQL?
How we liberated an
application from the
grips of a 3rd party API.
...and found happiness
with GraphQL <3
What are some good use
cases if you’re thinking
about trying GraphQL?
1. GRAPHQL + ME
2. GRAPHQL + YOU
WHAT I’LL TALK ABOUT
I am a Software Engineer at
Condé Nast International in London.
I organise Node Girls.
I GraphQL.
@msmichellegar
BUT FIRST...
GRAPHQL 101
GraphQL is “a query
language for APIs”.
GraphQL is a language
for requesting remote
data.
GraphQL is a syntax for
asking for information
from a server.
REST vs GraphQL
With REST you have
multiple endpoints.
eg. /articles /galleries
GraphQL has a single
multi-purpose endpoint.
eg. /graphql
With REST the endpoint
gives you a predefined
set of data.
GraphQL gives you
exactly what you ask
for. No more or less.
There is a “schema” that
tells you all the fields
you can request (and
their types).
To request data you write
a “query” describing
what you want.
MY GRAPHQL
STORY
SOME CONTEXT
Build the API you want to see in the world
*GQ is not a magazine about GraphQL
Build the API you want to see in the world
WHAT THE APP
USED TO LOOK LIKE
API
An API for the
content
management
system (CMS)
that our editors
use to write
content.
API
REACT
SSR
Redux
Hapi
PROBLEMS
WE HAD
1. A lot of our
components were tied
very specifically to the
API response.
const Title = ({ apiResponse }) => (
<div>
<h1>{apiResponse.title}</h1>
</div>
);
Why is this bad?
If the API changes, you
have to update your
components.
const Title = ({ apiResponse }) => (
<div>
<h1>{apiResponse.title}</h1>
</div>
);
const Title = ({ apiResponse }) => (
<div>
<h1>{apiResponse.head}</h1>
</div>
);
It’s less readable. It’s
not clear what data
your component needs.
const Title = ({ apiResponse }) => (
<div>
<h1>{apiResponse.title}</h1>
</div>
);
Our components know
too much about their
context.
Context: where data
comes from, structure
it’s fetched in, all data
available in the app.
Ideally we’d have a few
components that know
context, while most
have no idea.
PRESENTATIONAL CONTAINER
const Title = ({
text
}) => (
<div>
<h1>{text}</h1>
</div>
);
const Article = (data) => (
<article>
<Title title={data.text} />
</article>
);
export default compose(
withArticleData
)(Article);
PRESENTATIONAL
Knows nothing
about context.
No state or
dependencies.
Just takes in
data and
displays it.
const Title = ({
text
}) => (
<div>
<h1>{text}</h1>
</div>
);
const Title = ({ text }) => (
<div>
<h1>{text}</h1>
</div>
);
CONTAINERKnows about
context.
Often generated
by HOC.
Provides data to
presentational
components.
const Article = (data) => (
<article>
<Title title={data.text} />
</article>
);
export default compose(
withArticleData
)(Article);
const Article = (data) => (
<article>
<Title title={data.text} />
<Byline author={data.author} />
</article>
);
export withArticleData(Article);
We did not enforce this
strictly enough! Our
components knew too
much :(
Ideally even container
components don’t know
about the 3rd party API
(more on this later).
Basically, our
components needed
refactoring.
2. We sent a lot of data
we weren’t using to the
client.
Build the API you want to see in the world
Why is this bad?
Confusing clutter! We
don’t need it, why is it
there?
It can affect
performance. The
browser is downloading
unnecessary stuff.
It can be a security
risk. What if the API
developer introduces a
sensitive field?
Moral of the story: we
should not be sending
all this data to the
client!
3. If we switched data
sources, we’d have to
completely rewrite our
entire application.
Pretty much everything
in our app was closely
tied to the API.
If we switched CMS,
we’d have to throw
away our app and
rewrite it.
API
APP
OUR
API
?
APP
OUR
Why is this bad?
Technology changes,
your app should be
resilient!
It is a business risk to
couple your application
to a third party service.
We needed to
consciously decouple!
4. The API was difficult
to work with: it had
some quirks that we
didn’t understand.
Disclaimer: this is the
case with ALL third
party APIs.
It was not built with
our specific use case in
mind (can you believe?)
Some problems we
experienced:
Field names did not
always make sense to
us.
There was SO MUCH
DATA. More than we
needed.
Build the API you want to see in the world
Some data was not in
the format we
required.
body: “## Miranda Kerr
Hochzeits-Make-up”
There was not always
documentation.
(Documentation is hard
when it is done by
humans)
Third party APIs will
never be perfect!
But we needed to work
with the API better in
our application.
5. We were fetching
data in complicated
ways from deep trees in
the API every time.
/article/meghan-markle
/article/meghan-markle
/api/article/meghan-markle
/api/article/meghan-markle/history/publish
/api/contributor/michelle-garrett
/api/category/fashion
/api/recommendations?id=”meghan-markle”
/api/article/recommendation1
/api/article/recommendation2
/article/meghan-markle
/api/article/meghan-markle
/api/article/meghan-markle/history/publish
/api/contributor/michelle-garrett
/api/category/fashion
/api/recommendations?id=”meghan-markle”
/api/article/recommendation1
/api/article/recommendation2
Why is this bad?
It was cognitive
overload trying to
remember where to get
which data.
We had to navigate
complex relationships
between objects.
We had to make
multiple requests in our
main application to get
the data we wanted.
If you make multiple
requests client-side,
it’s not performant.
It’s harder to debug.
/article/meghan-markle
/api/article/meghan-markle
/api/article/meghan-markle/history/publish
/api/contributor/michelle-garrett
/api/category/fashion
/api/recommendations?id=”meghan-markle”
/api/article/recommendation1
/api/article/recommendation2
It was a lot to deal
with.
CLEARLY WE HAD
ISSUES!
HOW WE SOLVED
THESE PROBLEMS
We had a spike, and
prototyped different
solutions to our
problems.
One was a refactor
based purely on domain
driven design.
...and the other was
GraphQL.
We chose GraphQL!
API
REACT
SSR
Redux
Hapi
API
REACT
SSR
Redux
Hapi
Business Logic
API
REACT
SRR
Hapi
Apollo
Client
API
REACT
SRR
Hapi
Apollo
Client
Business Logic
WHAT GRAPHQL
GAVE US
1. Instant
documentation
The GraphQL ecosystem
has tools that generate
documentation from
your schema.
GraphiQL
GraphQL Playground
Build the API you want to see in the world
Queries
you can
make
Arguments
to include
What data
you can
ask for
Our documentation is
now useful and stays up
to date with no effort.
We now know for sure
what data we can
request for our client
side application.
2. We no longer have to
fetch data with multiple
requests in our main
application.
/article/meghan-markle
/api/article/meghan-markle
/api/article/meghan-markle/history/publish
/api/contributor/michelle-garrett
/api/category/fashion
/api/recommendations?id=”meghan-markle”
/api/article/recommendation1
/api/article/recommendation2
Now we make
one query
Now we get data in a
clear, consistent way.
(We still have to make
the same requests, but
they now happen in the
GraphQL layer).
Our React application
doesn’t have to know
about it.
Our lives are much
easier now that we only
have to think about one
query.
3. It encouraged good
patterns of structuring
our app.
We started fetching only
the data we needed.
We stripped all business
logic out of our
components
(separation of concerns)
We used field names
that made sense, instead
of using what the API
gave us.
Our UI is no longer tied
to the API.
Disclaimer: We could’ve
done this WITHOUT
GraphQL
With more discipline, we
could have avoided some
of these problems.
There are programming
patterns that encourage
these principles.
Domain Driven Design
Hexagonal Architecture
GraphQL enforces these
patterns without
requiring developers to
police it themselves.
GraphQL allows you to
follow these patterns
without having to think
about it.
4. We have the insurance
that if we ever need to
change our data source,
most of our app will not be
affected.
Scenario: Condé Nast
might decide to switch
its CMS to Wordpress
API
REACT
APP
API
REACT
APP
Changing data sources
will only affect the
GraphQL layer which
shields the React app.
The impact is limited to
updating the functions
that resolve data for
each field in the schema.
The API we use might
completely be
rewritten but we are
resilient
We can now react more
easily to technology
changes. Our application
won’t be devastated.
WHY YOU MIGHT
USE GRAPHQL
1. You have a set of data
that needs to serve
multiple applications.
API
GraphQL is “product-
friendly”.
It has a lower barrier to
entry for new
consumers to the API.
Because it reduces the
burden on consumers to
perform logic.
API
API
Business Logic
API
API
Business Logic
It does not enforce a
specific way to
consume an API.
It gives consumers the
flexibility to request
data in the way they
want.
{
category(
slug: "beauty"
) {
articles (limit: 10) {
title
image {
url
alt
}
}
}
{
category(
slug: "beauty"
) {
images (limit: 10) {
url
alt
}
}
}
Your applications can
be totally different, but
seamlessly use the
same set of data.
2. You’re building an
application that uses
multiple data sources.
Scenario: Condé Nast
introduces an extra
data source: a shoes
API for a feed of shoes.
API API
You can build a
GraphQL layer to fetch
data from all your
sources.
Combine data from
anywhere, but only
interact with one
interface.
Note: GraphQL and
REST are not mutually
exclusive!
You can get data from
lots of places (including
REST APIs) and smoosh
it all together.
Possible data sources:
- REST APIs
- Other GraphQL APIs
- A database
- JSON in your file system
API
API
REACT
APP
Your resolver functions
will handle all the
complication behind
the scenes.
API
API
REACT
APP
Meanwhile on the
frontend, you’re living
the sweet GraphQL life.
3. You want to enforce
structure in your code
base.
GraphQL encourages
good habits.
It will help you
separate your concerns.
It will encourage you to
remove logic specific to
3rd party APIs from
your client application.
4. You’ve built your
REST API like a pseudo-
GraphQL API anyway.
Do you have endpoints
that fetch fields based
a query param?
/articles
/articles?
slug=meghan-markle
&fields=title|author|body
...it’s basically already
GraphQL.
Just make it
GraphQL!
5. Because it’s fun and
everyone else is doing
it* :)
5. Because it’s fun and
everyone else is doing
it* :)
*This isn’t the only reason you should choose a tool
I HAVE DELUXE STICKERS
@msmichellegar
THANK YOU!

More Related Content

PDF
Michelle Garrett - Build the API you want to see in the world (with GraphQL) ...
PDF
Michelle Garrett - Build the API you want to see in the world (with GraphQL) ...
PDF
Scaling Your Team With GraphQL: Why Relationships Matter
PDF
Serverless GraphQL for Product Developers
PDF
Introduction to GraphQL (or How I Learned to Stop Worrying about REST APIs)
PDF
React and GraphQL at Stripe
PPTX
Principles of REST API Design
PDF
GraphQL over REST at Reactathon 2018
Michelle Garrett - Build the API you want to see in the world (with GraphQL) ...
Michelle Garrett - Build the API you want to see in the world (with GraphQL) ...
Scaling Your Team With GraphQL: Why Relationships Matter
Serverless GraphQL for Product Developers
Introduction to GraphQL (or How I Learned to Stop Worrying about REST APIs)
React and GraphQL at Stripe
Principles of REST API Design
GraphQL over REST at Reactathon 2018

What's hot (17)

PDF
GraphQL across the stack: How everything fits together
PPTX
Using AppEngine for Mobile Apps
PDF
GraphQL as an alternative approach to REST (as presented at Java2Days/CodeMon...
PDF
Better APIs with GraphQL
PDF
Performance optimisation with GraphQL
PDF
GraphQL + relay
PDF
Graphql
PPT
Graphql presentation
PPTX
GraphQL Introduction
PDF
Why UI Developers Love GraphQL - Sashko Stubailo, Apollo/Meteor
PDF
What Makes a Great Open API?
PPTX
Leweb Ignite Talk on APIs
PDF
The 7 Deadly Sins of API Design
PDF
Introduction to GraphQL at API days
PDF
Intro to JavaScript for APEX Developers
PDF
GraphQL Europe Recap
PDF
Classifying Tech News with Sparkling Water
GraphQL across the stack: How everything fits together
Using AppEngine for Mobile Apps
GraphQL as an alternative approach to REST (as presented at Java2Days/CodeMon...
Better APIs with GraphQL
Performance optimisation with GraphQL
GraphQL + relay
Graphql
Graphql presentation
GraphQL Introduction
Why UI Developers Love GraphQL - Sashko Stubailo, Apollo/Meteor
What Makes a Great Open API?
Leweb Ignite Talk on APIs
The 7 Deadly Sins of API Design
Introduction to GraphQL at API days
Intro to JavaScript for APEX Developers
GraphQL Europe Recap
Classifying Tech News with Sparkling Water
Ad

Similar to Build the API you want to see in the world (20)

PDF
Andrea Baldon, Emanuele Di Saverio - GraphQL for Native Apps: the MyAXA case ...
PDF
apidays LIVE Paris - GraphQL meshes by Jens Neuse
PDF
GraphQL - A query language to empower your API consumers (NDC Sydney 2017)
PPTX
REST API Graph API GraphQL GraphiQL Presentation
PPTX
Web Dev 21-01-2024.pptx
PDF
GraphQL for Native Apps
PPTX
GraphQL research summary
PPTX
React Flux to GraphQL
PDF
Wrapping and securing REST APIs with GraphQL
PDF
How easy (or hard) it is to monitor your graph ql service performance
PDF
Professional JavaScript: AntiPatterns
PPTX
PHP and Platform Independance in the Cloud
PPT
BarCamp KL H20 Open Social Hackathon
PPTX
GraphQL-ify your APIs - Devoxx UK 2021
PDF
React Native +Redux + ES6 (Updated)
PDF
System design for Web Application
PPT
Google App Engine for Java
PDF
Apache spark with java 8
PPTX
Apache spark with java 8
PPT
The 90-Day Startup with Google AppEngine for Java
Andrea Baldon, Emanuele Di Saverio - GraphQL for Native Apps: the MyAXA case ...
apidays LIVE Paris - GraphQL meshes by Jens Neuse
GraphQL - A query language to empower your API consumers (NDC Sydney 2017)
REST API Graph API GraphQL GraphiQL Presentation
Web Dev 21-01-2024.pptx
GraphQL for Native Apps
GraphQL research summary
React Flux to GraphQL
Wrapping and securing REST APIs with GraphQL
How easy (or hard) it is to monitor your graph ql service performance
Professional JavaScript: AntiPatterns
PHP and Platform Independance in the Cloud
BarCamp KL H20 Open Social Hackathon
GraphQL-ify your APIs - Devoxx UK 2021
React Native +Redux + ES6 (Updated)
System design for Web Application
Google App Engine for Java
Apache spark with java 8
Apache spark with java 8
The 90-Day Startup with Google AppEngine for Java
Ad

Recently uploaded (20)

PPTX
FINAL REVIEW FOR COPD DIANOSIS FOR PULMONARY DISEASE.pptx
PDF
Mohammad Mahdi Farshadian CV - Prospective PhD Student 2026
DOCX
ASol_English-Language-Literature-Set-1-27-02-2023-converted.docx
PPTX
web development for engineering and engineering
PPTX
UNIT 4 Total Quality Management .pptx
PPTX
Recipes for Real Time Voice AI WebRTC, SLMs and Open Source Software.pptx
PPTX
Geodesy 1.pptx...............................................
PPTX
M Tech Sem 1 Civil Engineering Environmental Sciences.pptx
PPTX
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
PDF
keyrequirementskkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
PPTX
Foundation to blockchain - A guide to Blockchain Tech
PPTX
Sustainable Sites - Green Building Construction
PPTX
CYBER-CRIMES AND SECURITY A guide to understanding
PPTX
Construction Project Organization Group 2.pptx
PDF
Digital Logic Computer Design lecture notes
PDF
TFEC-4-2020-Design-Guide-for-Timber-Roof-Trusses.pdf
PDF
The CXO Playbook 2025 – Future-Ready Strategies for C-Suite Leaders Cerebrai...
PDF
Well-logging-methods_new................
PPTX
Engineering Ethics, Safety and Environment [Autosaved] (1).pptx
PDF
Automation-in-Manufacturing-Chapter-Introduction.pdf
FINAL REVIEW FOR COPD DIANOSIS FOR PULMONARY DISEASE.pptx
Mohammad Mahdi Farshadian CV - Prospective PhD Student 2026
ASol_English-Language-Literature-Set-1-27-02-2023-converted.docx
web development for engineering and engineering
UNIT 4 Total Quality Management .pptx
Recipes for Real Time Voice AI WebRTC, SLMs and Open Source Software.pptx
Geodesy 1.pptx...............................................
M Tech Sem 1 Civil Engineering Environmental Sciences.pptx
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
keyrequirementskkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Foundation to blockchain - A guide to Blockchain Tech
Sustainable Sites - Green Building Construction
CYBER-CRIMES AND SECURITY A guide to understanding
Construction Project Organization Group 2.pptx
Digital Logic Computer Design lecture notes
TFEC-4-2020-Design-Guide-for-Timber-Roof-Trusses.pdf
The CXO Playbook 2025 – Future-Ready Strategies for C-Suite Leaders Cerebrai...
Well-logging-methods_new................
Engineering Ethics, Safety and Environment [Autosaved] (1).pptx
Automation-in-Manufacturing-Chapter-Introduction.pdf

Build the API you want to see in the world

Editor's Notes

  • #2: Color palette: https://coolors.co/8ed0ad-d686a4-7f66a6-9f8fcf-634593
  • #3: Our components, analytics, metadata were all tied very specifically to the API response.
  • #4: Our components, analytics, metadata were all tied very specifically to the API response.
  • #5: Our components, analytics, metadata were all tied very specifically to the API response.
  • #6: Our components, analytics, metadata were all tied very specifically to the API response.
  • #7: Our components, analytics, metadata were all tied very specifically to the API response.
  • #8: Our components, analytics, metadata were all tied very specifically to the API response.
  • #9: Our components, analytics, metadata were all tied very specifically to the API response.
  • #13: Our components, analytics, metadata were all tied very specifically to the API response.
  • #14: Our components, analytics, metadata were all tied very specifically to the API response.
  • #15: Our components, analytics, metadata were all tied very specifically to the API response.
  • #16: Our components, analytics, metadata were all tied very specifically to the API response.
  • #17: Our components, analytics, metadata were all tied very specifically to the API response.
  • #18: Our components, analytics, metadata were all tied very specifically to the API response.
  • #19: Our components, analytics, metadata were all tied very specifically to the API response.
  • #20: Our components, analytics, metadata were all tied very specifically to the API response.
  • #21: Our components, analytics, metadata were all tied very specifically to the API response.
  • #22: Our components, analytics, metadata were all tied very specifically to the API response.
  • #29: React application (with SSR) Hapi.js server Data comes from the Copilot API (Copilot is the CMS that we use) Data stored in Redux
  • #30: React application (with SSR) Hapi.js server Data comes from the Copilot API (Copilot is the CMS that we use) Data stored in Redux
  • #32: Our components, analytics, metadata were all tied very specifically to the API response.
  • #34: Our components, analytics, metadata were all tied very specifically to the API response.
  • #35: Our components, analytics, metadata were all tied very specifically to the API response.
  • #38: Our components, analytics, metadata were all tied very specifically to the API response.
  • #40: Our components, analytics, metadata were all tied very specifically to the API response.
  • #41: Our components, analytics, metadata were all tied very specifically to the API response.
  • #42: Our components, analytics, metadata were all tied very specifically to the API response.
  • #43: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
  • #44: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
  • #46: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
  • #48: Our components, analytics, metadata were all tied very specifically to the API response.
  • #49: Our components, analytics, metadata were all tied very specifically to the API response.
  • #50: Our components, analytics, metadata were all tied very specifically to the API response.
  • #53: Our components, analytics, metadata were all tied very specifically to the API response.
  • #54: Our components, analytics, metadata were all tied very specifically to the API response.
  • #55: Our components, analytics, metadata were all tied very specifically to the API response.
  • #56: Our components, analytics, metadata were all tied very specifically to the API response.
  • #57: Our components, analytics, metadata were all tied very specifically to the API response.
  • #59: Our components, analytics, metadata were all tied very specifically to the API response.
  • #60: Our components, analytics, metadata were all tied very specifically to the API response.
  • #63: Our components, analytics, metadata were all tied very specifically to the API response.
  • #64: Our components, analytics, metadata were all tied very specifically to the API response.
  • #65: Our components, analytics, metadata were all tied very specifically to the API response.
  • #66: Our components, analytics, metadata were all tied very specifically to the API response.
  • #67: Field names did not make sense to us.
  • #68: Our components, analytics, metadata were all tied very specifically to the API response.
  • #69: Our components, analytics, metadata were all tied very specifically to the API response.
  • #70: Our components, analytics, metadata were all tied very specifically to the API response.
  • #71: Our components, analytics, metadata were all tied very specifically to the API response.
  • #72: Our components, analytics, metadata were all tied very specifically to the API response.
  • #74: Our components, analytics, metadata were all tied very specifically to the API response.
  • #75: Our components, analytics, metadata were all tied very specifically to the API response.
  • #76: Our components, analytics, metadata were all tied very specifically to the API response.
  • #77: Our components, analytics, metadata were all tied very specifically to the API response.
  • #78: Our components, analytics, metadata were all tied very specifically to the API response.
  • #79: Our components, analytics, metadata were all tied very specifically to the API response.
  • #80: Field names did not make sense to us.
  • #81: Our components, analytics, metadata were all tied very specifically to the API response.
  • #82: Our components, analytics, metadata were all tied very specifically to the API response.
  • #83: Our components, analytics, metadata were all tied very specifically to the API response.
  • #84: Our components, analytics, metadata were all tied very specifically to the API response.
  • #85: Our components, analytics, metadata were all tied very specifically to the API response.
  • #86: Our components, analytics, metadata were all tied very specifically to the API response.
  • #87: Our components, analytics, metadata were all tied very specifically to the API response.
  • #88: Our components, analytics, metadata were all tied very specifically to the API response.
  • #89: Our components, analytics, metadata were all tied very specifically to the API response.
  • #90: Our components, analytics, metadata were all tied very specifically to the API response.
  • #91: Our components, analytics, metadata were all tied very specifically to the API response.
  • #92: Field names did not make sense to us.
  • #94: Our components, analytics, metadata were all tied very specifically to the API response.
  • #95: Our components, analytics, metadata were all tied very specifically to the API response.
  • #96: Our components, analytics, metadata were all tied very specifically to the API response.
  • #97: Our components, analytics, metadata were all tied very specifically to the API response.
  • #98: React application (with SSR) Hapi.js server Data comes from the Copilot API (Copilot is the CMS that we use) Data stored in Redux
  • #99: React application (with SSR) Hapi.js server Data comes from the Copilot API (Copilot is the CMS that we use) Data stored in Redux
  • #100: We used Apollo server to create the schema We used Apollo client to helps us make the requests for data from our React app We moved all the business logic that was previously mixed in with components to the GraphQL “resolvers” We essentially added a GraphQL layer over the content/CMS API
  • #101: We used Apollo server to create the schema We used Apollo client to helps us make the requests for data from our React app We moved all the business logic that was previously mixed in with components to the GraphQL “resolvers” We essentially added a GraphQL layer over the content/CMS API
  • #103: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #104: Our components, analytics, metadata were all tied very specifically to the API response.
  • #105: Our components, analytics, metadata were all tied very specifically to the API response.
  • #106: This is what our scheme looks like. I’m using graphql playground which is a cool application that allows you to query graphql api. It’s similar to postman or insomnia by chrome. What’s cool about graphql playground. Is that you can also see the schema of the api. So it makes it super easy figuring out what u need.
  • #107: You can see the queries you can make
  • #108: You can see the queries you can make
  • #109: You can see the queries you can make
  • #110: Our components, analytics, metadata were all tied very specifically to the API response.
  • #111: Our components, analytics, metadata were all tied very specifically to the API response.
  • #112: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #113: If you remember our article example and the many request we had to make.
  • #114: We don't’ have to think about the stuff that’s going on behind the screens.
  • #115: Our components, analytics, metadata were all tied very specifically to the API response.
  • #116: Our components, analytics, metadata were all tied very specifically to the API response.
  • #117: Our components, analytics, metadata were all tied very specifically to the API response.
  • #118: Our components, analytics, metadata were all tied very specifically to the API response.
  • #119: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #120: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #121: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #122: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #123: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #124: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #125: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #126: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #127: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #128: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #129: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #130: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #131: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #134: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #135: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #136: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #137: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #139: Our components, analytics, metadata were all tied very specifically to the API response.
  • #141: Our components, analytics, metadata were all tied very specifically to the API response.
  • #142: Our components, analytics, metadata were all tied very specifically to the API response.
  • #143: Our components, analytics, metadata were all tied very specifically to the API response.
  • #148: Our components, analytics, metadata were all tied very specifically to the API response.
  • #149: Our components, analytics, metadata were all tied very specifically to the API response.
  • #152: Our components, analytics, metadata were all tied very specifically to the API response.
  • #153: Our components, analytics, metadata were all tied very specifically to the API response.
  • #154: -- we just need to update our GraphQL resolvers, while the interface of components stays the same.
  • #156: Our components, analytics, metadata were all tied very specifically to the API response.
  • #157: Our components, analytics, metadata were all tied very specifically to the API response.
  • #158: Our components, analytics, metadata were all tied very specifically to the API response.
  • #159: Our components, analytics, metadata were all tied very specifically to the API response.
  • #160: Our components, analytics, metadata were all tied very specifically to the API response.
  • #162: Our components, analytics, metadata were all tied very specifically to the API response.
  • #164: Our components, analytics, metadata were all tied very specifically to the API response.
  • #165: Our components, analytics, metadata were all tied very specifically to the API response.
  • #166: Our components, analytics, metadata were all tied very specifically to the API response.
  • #167: Our components, analytics, metadata were all tied very specifically to the API response.
  • #168: Our components, analytics, metadata were all tied very specifically to the API response.
  • #169: Our components, analytics, metadata were all tied very specifically to the API response.
  • #170: Our components, analytics, metadata were all tied very specifically to the API response.
  • #171: Our components, analytics, metadata were all tied very specifically to the API response.
  • #172: Our components, analytics, metadata were all tied very specifically to the API response.
  • #173: Our components, analytics, metadata were all tied very specifically to the API response.
  • #174: Our components, analytics, metadata were all tied very specifically to the API response.
  • #175: Our components, analytics, metadata were all tied very specifically to the API response.