-
Notifications
You must be signed in to change notification settings - Fork 24
/
topics.txt
135 lines (92 loc) · 6.37 KB
/
topics.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
KAT The point about URLs having a limit could be good to mention. It bit us when we
worked with Magento's API and they wanted a ton of stuff posted as a form, and
the descriptions of products can get quite long... took me a while to work out
the browser was just cutting it off after ~2000 chars!
(https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers)
difference between public and private. Whoever has a token?
self ddosing - When A calls B and B secretly calls back to A, which causes them
both to slow down so much they both slow each other down MORE ANDE GUESS WHAT
EVERYTHING IS ON FUCKING FIRE
Three-way syncs, where A, B and C all have different god damn validation rules,
so something could be in A and B but not C, or B and C but not A, or...
Two different ID systems "syncing" with each other by for(everyone in the database) { GET /users/123 }
> Question 2: Are your microservices overly chatty?
> Each microservice should have a clearly defined purpose that it can execute with minimal communication with other services. If you see a service that has to send many back-and-forth requests to the same downstream services, that’s a red flag.
https://blog.newrelic.com/engineering/distributed-monolith-vs-microservices/
overloading specific fields with unexpected meaning, like "ID of ABC123F means
the resource is a special 'foo' type... oh wait also ABC456E also means this...
oops now theres another one. JUST ADD FUCKING type: 'foo' GAH
When I rant on about how graphql is forcing you to wait for D to finish loading
before you can show A remember to talk about Appollo specific @defer
https://www.apollographql.com/docs/react/features/defer-support.html
https://blog.apollographql.com/introducing-defer-in-apollo-server-f6797c4e9d6e
https://blog.apollographql.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07
brief mention of "if calling other peoples APIs use damn timeouts" but thats
explained more in surviving other peoples apis aint doing it twice
Firing a field into a black hole: at Ride we were sending is_foo cant remember
what and it was important we counted how many signed up with that field, but the
API was not saving it!!! you dont want production errors for extra fields (that
means if you deprecate and carefully remove one you get errors, or if a client
starts sending one a little bit before your API starts listening to it, etc) and
just generally means you have lock step deployments. Error in testing perhaps.
Logging those oddities is a good idea
Talk about specs later a bit more: - https://inspector.swagger.io/builder -
https://blog.apisyouwonthate.com/creating-api-specifications-from-bulls-t-f5a54c005135
whole caching thread https://twitter.com/philsturgeon/status/1050043229800976384
hypermedia cache pattern
https://tools.ietf.org/html/draft-kelly-json-hal-08#section-8.3
- API load testing and the best ways to monitor API Catchpoint.com - more of a
geo-monitor & requests performance tool Loader.io
* https://goreplay.org/ to re-play prod traffic into any server
* jmeter and friends
* https://gatling.io/
* https://artillery.io/
Simone Fumagalli [05:47] I usually return the resource just create/modfied but
some for `POST` return a `201` with the link to the new resource in the
`Location` header
Mika Tuupola [06:47] Same as @Simone Fumagalli except with `POST` I return `201`
and both the created resource and the `Location` header. (edited)
Adam Quaile [06:55] In some cases, I just use `204` with no content and assume
the client knows enough about the resource because it just created it
Felix Sandström [09:31] We’re also thinking about returning the modified
resource in our API, so this might be a good way to go then 
Phil Sturgeon [09:46] @felixsand you have to think, if you have server-computed
fields, are they mostly computed on save, or after save. because if you have no
fields being computed, what @adamquaile said is true, and the client already
knows enough because it just did the thing.
[09:47] if they’re created on save (potentially slow watch out!) then returning
the body, and if they’re computed later, well a Location is probably a fantastic
idea because by the time they go fetch it maybe the fields have been computed
[09:47] now obviously dont go mixing styles randomly around in different
resources!
[09:48] `Content-Location` on a POST is nice because if you’re using Cache
Control headers then it gets a cached response for that thing into the cache
server or client cache rather quickly, a chunk of JSON in the POST does not.
[09:49] PUT: no need to return anything because dog the whole body of that
document should have been in the payload so you _know_ what that is.
Content-Location can be used all the same for consistency.
[09:50] PATCH: Yeah if you just tweaked 1 thing then surely the client should
know, but unfortunately maybe another client tweaked another thing, and… well if
they follow that `Content-Location` maybe they’ll get an update
- DONT OVERLOAD FIELD MEANING TO GIVE SPECIAL FLAGS AND STATUSES single fields
with multiple meanings (location_uuid = nil = anywhere)
- Add ACL / scopes I would have preferred it to touch a bit more on the topic of
ACL and role based control through the API request itself.
- What can go wrong Use runscope as a proxy whilst you’re developing, and do it
in staging to see whats up. Honestly we’ve used it in production for a while
too, and had clients retry on the direct URL if runscope was unavailable. This
was never an issue but paranoia.
- Performance Make the most efficient HTTP calls you can. You might be making
HTTP calls with a network library built into the language, or one built by
somebody else. Either way, ensure it’s using HTTP/1.1 with keep alive on it, and
if possible use a HTTP/2 client library. HTTP/1.1 keep alive can knock 20% off
of repeated connections to the same host depending on how that connection is
maintained. HTTP/2 is baller and async is cool. If they dont use HTTP/2 you can
give yourself some with a proxy.
- GraphQL multiple mutations
https://medium.com/@__xuorig__/graphql-mutation-design-batch-updates-ca2452f92833
- Building which headers to worry about
https://www.fastly.com/blog/headers-we-dont-want
- SDKs - Relying on community to build SDKs is great until you make changes to
your API they dont like and decide to stop maintaining them
https://twitter.com/rdohms/status/1168079635554304000?s=12