-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathgraphql.txt
executable file
·142 lines (115 loc) · 5.58 KB
/
graphql.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
JL
- needed a way to give the clients the data they need
when they need it rather than calling multiple svcs and
integrate that data in their way, in redundant fashion
across all different clients.
- API became future-proof because the build api providing all data
and if the client didn't need all that, they didn't get all of that.
- Edge service: intermediary service between client and down stream service.
- - correlated to a client - so u have a clent specific edge svc for ios,
another for android, another for Roku...
- these edge services exist to transform data, to make them more accessible
to the use cases for a particular client.
- from performance perspective do u want ur client to go to different mss and do
the composition and do the scatter gather service orchestration in the client
memory?
Grapgql was designed to support 3 main use cases:
- read[query] - update[mutation] - subscription(read data over long period)
- this technology gives u the means u need to be able to ask for a particular
set of data and get only that data this critical in removing the cycle or breaking
the cycle of constantly standing up new edge services to adapt downstream service
to particular client.
- graphql layer is a great place to integrate down stream services with clients
and because u've got one Graphql endpoint, it also great place to put other things
like security
- WORKS WITH SCHEMA AND THAT MAKES IT INTEROSPECTABLE.
u can easily discover endpoints.
1 start with schema and then build the code behind the schema.
2 write types and code and the u generate schema from that
[schema centric approach is preferable]
- root type of all types is Query.
-----------
Graphql is a query lang for our API. The GraphQL service is transport agnostic but is
typically served over HTTP.
The query is nested, and when it is executed, can traverse related objects.
This allows us to make one HTTP request for two types of data. We don’t need
to make several round trips to drill down into multiple objects.
query is validated against a type system. Every GraphQL service defines types
in a GraphQL schema.
Design Principles of Graphql
Hierarchical
Fields are nested within other fields and the query is
shaped like the data that it returns.
Product centric
driven by the data needs of the client and the language
and runtime that support the client.
Strong typing
Client-specified queries
Introspective
The GraphQL language is able to query the GraphQL server’s type system.
---
History of Data Transport
- RPC
- Simple Object Access Protocol[SOAP]
used XML to encode a message and HTTP as a transport.
SOAP also used a type system and introduced the concept of resource-oriented
calls for data. SOAP offered fairly predictable results but caused frustration
because SOAP implementations were fairly complicated.
- REST
Drawbacks:
- overfetching
we’re getting a lot of data back that we don’t need.
- underfetching
The result is a slower user experience, and users with slower network
speeds or slower devices might not be able to view the content at all.
- Another common complaint about REST APIs is the lack of flexibility.
As the needs on the client change, you usually have to create new endpoints,
and those endpoints can begin to multiply quickly. To paraphrase Oprah,
“You get a route! You get a route! Every! Body! Gets! A! Route!” .
Larger apps typically utilize custom endpoints to minimize HTTP requests.
----
GraphQL clients handle tasks like network requests, data caching,
and injecting data into the user interface.
[leaders in the space are Relay and Apollo.]-
---
graph theory concepts:
The parentheses mean that these edge definitions are ordered pairs.
Whenever the edges are ordered pairs, we have a directed graph or digraph.
The degree of a node is equal to the number of edges that are attached to that node.
- Because each of the nodes had odd degrees, Euler found that crossing each bridge
without recrossing was impossible.
- Eulerian cycle. In this case, the starting node is the same as the ending node.
Each edge is visited only once, but the start and end node is repeated
--video--
Query : entrypoint
Mutation:
Nesting
Subscription
---
GET req maximum chars 2048
Schema <- client make a GET req to get the schema.
--
Pros:
- Flexibility
- Efficient Response(u only get what u ask for)
- No roundtrips(happen in the backend)
- Single endpoint
- Self documenting
Cons:
- Complexity(need to define schema)
- No Http caching(POST only).
- No standard Errors(facebook choice to make it transport agnostic not tied to http.
- Expensive queries backend (
Graphql over REST :
- Public ad-hoc API that u can't predict how it will be used.
- Enterprise API (a lot of entities will interact each will need different data)
- Well defined schema
REST over Graphql:
- specific and well-design use cases API
- Simple API that serves one client (webpage)
spec: A spec describes the capabilities and characteristics of a language.
We benefit from language specifications because they supply a common vocabulary and
best practices for the community’s use of the language.
The spec describes the language and grammar you should use when writing queries.
It also sets up a type system plus the execution and validation engines of that
type system.