1
00:00:00,100 --> 00:00:03,300
The API design centers on 
effective communication and it's

2
00:00:03,300 --> 00:00:05,700
not just communication between 
developers but it's 

3
00:00:05,700 --> 00:00:10,400
communication that combines 
product thinking, Business and 

4
00:00:10,400 --> 00:00:11,800
Technology. 
All in what? 

5
00:00:16,300 --> 00:00:19,600
Hey, everyone. 
My name is Henry Surya, we Robin

6
00:00:21,400 --> 00:00:25,000
And you're listening to the 
tekhelet Juno, the show will be 

7
00:00:25,000 --> 00:00:28,300
bringing you the greatest 
technical leaders practitioners 

8
00:00:28,500 --> 00:00:31,700
and thought leaders in the 
industry, who discuss about 

9
00:00:31,700 --> 00:00:35,500
their Journey ideas and 
practices that we all can learn 

10
00:00:35,500 --> 00:00:39,300
and apply to build a highly 
performing technical team and to

11
00:00:39,300 --> 00:00:41,500
make an impact in your personal 
work. 

12
00:00:42,300 --> 00:00:50,400
So let's dive into our Journal. 
Hello to all of you. 

13
00:00:50,400 --> 00:00:53,000
My listeners. 
I'm happy to be back here again 

14
00:00:53,100 --> 00:00:56,100
with another new episode of the 
tekhelet journal podcast. 

15
00:00:56,400 --> 00:00:59,300
Thank you for spending your time
with me today, listening to this

16
00:00:59,300 --> 00:01:01,500
episode. 
If this is your first time 

17
00:01:01,500 --> 00:01:04,099
listening to technology, you 
know, I would invite you to 

18
00:01:04,099 --> 00:01:07,500
subscribe and follow this show 
on your podcast app and social 

19
00:01:07,500 --> 00:01:11,500
media on LinkedIn, Twitter, and 
Instagram, and if you have been 

20
00:01:11,500 --> 00:01:14,700
regularly listening, and 
enjoying this podcast, and love 

21
00:01:14,700 --> 00:01:16,300
the type of content that I'm 
producing. 

22
00:01:16,900 --> 00:01:19,800
Will you support the show by 
subscribing as a patron at 

23
00:01:19,800 --> 00:01:23,200
technology, you know, dot Dev, 
slash Patron, and support my 

24
00:01:23,200 --> 00:01:25,200
journey to produce great 
episode. 

25
00:01:25,200 --> 00:01:30,000
Every week building, web apis 
has become ubiquitous whenever 

26
00:01:30,000 --> 00:01:33,500
we build Tech products, almost 
everything is nowadays available

27
00:01:33,500 --> 00:01:37,600
on the internet, and it's just 
one API call a way to integrate,

28
00:01:37,600 --> 00:01:40,500
disparate software systems in 
order to make them work 

29
00:01:40,500 --> 00:01:43,700
together, to perform a series of
tasks or activities. 

30
00:01:44,200 --> 00:01:47,500
Think about your mobile apps 
software as a Service electronic

31
00:01:47,500 --> 00:01:51,300
payments or even smart, home 
devices that you use frequently.

32
00:01:51,600 --> 00:01:54,600
They are all connected 
seamlessly through, apis, that 

33
00:01:54,600 --> 00:01:58,300
power the integration. 
And the importance of the apis 

34
00:01:58,300 --> 00:02:01,600
is not all about choosing the 
underlying Technologies or 

35
00:02:01,600 --> 00:02:05,700
protocols such as whether we 
should choose rest API, graphql,

36
00:02:05,700 --> 00:02:09,300
grp C and so on, there is 
something more beyond that. 

37
00:02:09,900 --> 00:02:13,000
My guest for today's episode is 
James higginbottom. 

38
00:02:13,600 --> 00:02:16,300
James is the author of 
principles of web API. 

39
00:02:16,500 --> 00:02:21,700
Design, and an executive API 
consultant in this episode James

40
00:02:21,700 --> 00:02:25,200
explained, why it is extremely 
important to design, apis, 

41
00:02:25,200 --> 00:02:29,400
properly and share the five key 
important principles of API 

42
00:02:29,400 --> 00:02:33,900
design such as not to design it.
In isolation importance, of API,

43
00:02:33,900 --> 00:02:38,300
documentation, Etc. 
James also recommended the API 

44
00:02:38,300 --> 00:02:42,000
design first approach, which is 
a rapid and lightweight outcome 

45
00:02:42,000 --> 00:02:46,200
based API design, process to 
design and deliver apis success.

46
00:02:46,400 --> 00:02:51,000
Really, including the addr 
process, aligned Define design, 

47
00:02:51,000 --> 00:02:55,200
refine establishing API 
boundaries, and how it relates 

48
00:02:55,200 --> 00:02:59,000
to domain-driven design or DDD 
towards the end. 

49
00:02:59,300 --> 00:03:02,300
James also shared some 
recommendation for API testing 

50
00:03:02,300 --> 00:03:06,100
strategies and also some API 
testing anti patterns that we 

51
00:03:06,100 --> 00:03:09,600
all should avoid. 
I really enjoyed my conversation

52
00:03:09,600 --> 00:03:12,500
with James understanding the 
importance of a good design 

53
00:03:12,500 --> 00:03:16,100
principles for building 
successful apis including his 

54
00:03:16,500 --> 00:03:19,200
First approach and the addr 
process. 

55
00:03:19,800 --> 00:03:22,900
And if you also find this 
episode useful, please share it 

56
00:03:22,900 --> 00:03:25,600
to someone, you know, who would 
also benefit from this. 

57
00:03:26,100 --> 00:03:29,300
And you can also leave a rating 
or review on your podcast app 

58
00:03:29,400 --> 00:03:33,100
and share comments on the social
media on what you enjoy from 

59
00:03:33,100 --> 00:03:35,500
this episode. 
I always love reading your 

60
00:03:35,500 --> 00:03:38,400
reviews and comments and they 
are one of the best ways to help

61
00:03:38,400 --> 00:03:40,700
me spread this podcast to more 
people. 

62
00:03:41,000 --> 00:03:44,300
And it is my hope that they can 
also benefit from this podcast. 

63
00:03:44,700 --> 00:03:46,300
So let's get our episode 
started. 

64
00:03:46,400 --> 00:03:48,700
It right, after our sponsor 
message. 

65
00:03:49,000 --> 00:03:50,900
Are you looking for a new cool 
swag? 

66
00:03:51,200 --> 00:03:53,800
Tackle, it Journal. 
Now offers you some swags that 

67
00:03:53,800 --> 00:03:57,600
you can purchase online. 
These wax are printed on demand 

68
00:03:57,700 --> 00:04:01,000
based on your preference and 
will be delivered safely to you 

69
00:04:01,100 --> 00:04:03,600
all over the world where 
shipping is available. 

70
00:04:04,000 --> 00:04:07,000
Check out all the cool tracks 
available by visiting package, 

71
00:04:07,000 --> 00:04:10,600
you know, dot, f / shop and 
don't forget to break yourself. 

72
00:04:10,700 --> 00:04:12,800
Once you receive any of those 
tracks. 

73
00:04:15,400 --> 00:04:16,300
Hello everyone. 
Welcome. 

74
00:04:16,399 --> 00:04:19,399
Back to another episode of the 
technology on our podcast today.

75
00:04:19,399 --> 00:04:21,700
I have with me, a guest named 
James higginbottom. 

76
00:04:21,899 --> 00:04:24,200
He's actually an expert in API 
design. 

77
00:04:24,300 --> 00:04:27,500
He has been a software developer
and architect for more than 25 

78
00:04:27,500 --> 00:04:30,000
years. 
So that's really a long time and

79
00:04:30,000 --> 00:04:34,000
mostly helping people to develop
deploy apis apps. 

80
00:04:34,300 --> 00:04:37,600
Also helping companies even to 
go through Transformations based

81
00:04:37,600 --> 00:04:40,800
on these API. 
So James just also published a 

82
00:04:40,800 --> 00:04:44,100
book titled principles of web 
API design. 

83
00:04:44,300 --> 00:04:46,200
It's something that you can look
for. 

84
00:04:46,400 --> 00:04:49,100
You need to build a web API for 
your applications, for your 

85
00:04:49,100 --> 00:04:51,900
team's or for your company. 
All this will be covered in this

86
00:04:51,900 --> 00:04:54,100
episode. 
So thank you so much for coming 

87
00:04:54,100 --> 00:04:56,500
to the show James looking 
forward for this composition. 

88
00:04:57,100 --> 00:04:57,900
Yeah. 
Thanks Henry. 

89
00:04:58,000 --> 00:04:59,500
I appreciate you. 
Having me and look forward to 

90
00:04:59,500 --> 00:05:01,500
our discussion. 
So James, maybe in the 

91
00:05:01,508 --> 00:05:04,100
beginning, you can introduce 
yourself for those who haven't 

92
00:05:04,100 --> 00:05:06,500
known you yet. 
And then maybe you can highlight

93
00:05:06,500 --> 00:05:08,800
starting points or major 
highlights in your career. 

94
00:05:09,500 --> 00:05:11,100
Yeah. 
So for those that are not 

95
00:05:11,100 --> 00:05:13,900
familiar, I've been Consulting 
for a number of years, ranging 

96
00:05:13,900 --> 00:05:16,200
from startups and software as a 
service company. 

97
00:05:16,400 --> 00:05:20,500
To Enterprise it. 
A lot of what I do is helping 

98
00:05:20,500 --> 00:05:26,200
organizations to establish grow 
and mature their API, programs, 

99
00:05:26,200 --> 00:05:29,300
as part of a larger digital 
transformation initiative. 

100
00:05:29,400 --> 00:05:33,600
Part of that is coming in and 
working and I 101 or team basis 

101
00:05:33,600 --> 00:05:36,900
to help organizations to grow 
their expertise. 

102
00:05:37,100 --> 00:05:39,800
And that also, oftentimes 
includes training. 

103
00:05:40,100 --> 00:05:44,600
So to doing live in person or 
remote workshops on API design 

104
00:05:44,600 --> 00:05:47,700
techniques interesting enough. 
I've got started in software 

105
00:05:47,700 --> 00:05:49,700
quite a few years ago. 
You're talking about turning 

106
00:05:49,700 --> 00:05:52,400
points in the career. 
My grandfather, gifted me. 

107
00:05:52,500 --> 00:05:56,400
A Commodore 64 computer when I 
was about eight years old. 

108
00:05:56,700 --> 00:05:59,300
He said, I want to get you this 
because I think computers are 

109
00:05:59,300 --> 00:06:02,300
going to be big someday, and I'd
like for my grandson to learn 

110
00:06:02,300 --> 00:06:04,900
how to use them. 
I took to it and turned it. 

111
00:06:04,900 --> 00:06:09,100
Into a career is been an 
absolute amazing opportunity to 

112
00:06:09,100 --> 00:06:12,600
go from kind of the early 
client-server days through 

113
00:06:12,600 --> 00:06:14,600
client networking. 
We were figuring out how to 

114
00:06:14,600 --> 00:06:18,200
network systems across Either a 
private Network or over the 

115
00:06:18,200 --> 00:06:21,500
internet and then eventually 
into web development and that's 

116
00:06:21,500 --> 00:06:25,800
also led into web API design and
helping organizations. 

117
00:06:25,800 --> 00:06:29,000
Think about how to treat their 
web apis, not just as a 

118
00:06:29,000 --> 00:06:32,100
technical asset. 
But really, as a product that's 

119
00:06:32,100 --> 00:06:35,100
owned and matures over time. 
Thanks for sharing your story. 

120
00:06:35,100 --> 00:06:37,100
Interesting enough. 
This is not the first time, I 

121
00:06:37,100 --> 00:06:38,800
guess actually shared about 
Commodore. 

122
00:06:39,300 --> 00:06:42,000
So it seems like that change a 
lot of people's career. 

123
00:06:42,300 --> 00:06:44,800
I personally haven't seen it. 
So, looking forward one day 

124
00:06:44,800 --> 00:06:47,200
maybe to see the real product. 
Of comodo, right. 

125
00:06:47,300 --> 00:06:49,000
Let's talk about your book 
itself. 

126
00:06:49,000 --> 00:06:52,400
Principles of web API design. 
What do you think are some of 

127
00:06:52,400 --> 00:06:55,400
the important things that led to
to writing this book? 

128
00:06:55,900 --> 00:07:00,200
A lot of this book comes from 
practical application that I've 

129
00:07:00,200 --> 00:07:02,900
spent with organizations and 
myself. 

130
00:07:02,900 --> 00:07:06,600
Personally, designing, apis. 
I come from kind of a blend. 

131
00:07:06,600 --> 00:07:09,500
As I mentioned, in my career of 
through the older School, way of

132
00:07:09,500 --> 00:07:12,400
doing things where we used to 
build or design and build 

133
00:07:12,400 --> 00:07:14,500
everything up front, which we 
don't want to do. 

134
00:07:14,800 --> 00:07:16,200
We learned other techniques for 
it. 

135
00:07:16,800 --> 00:07:20,400
But I've also seen a lot of 
opportunity to think about API 

136
00:07:20,400 --> 00:07:22,400
design and new and interesting 
ways. 

137
00:07:22,800 --> 00:07:26,400
I've always referenced an old 
partner in co-author of mine. 

138
00:07:26,400 --> 00:07:29,500
Keep Casey who helped me put 
together a self published 

139
00:07:29,500 --> 00:07:31,700
version of what turned into this
book. 

140
00:07:31,700 --> 00:07:33,500
When we put it together years 
ago. 

141
00:07:33,700 --> 00:07:36,900
He always said that API design 
represents the effort required 

142
00:07:36,900 --> 00:07:39,800
to design the third user 
interface or referred to an API 

143
00:07:39,800 --> 00:07:41,300
design as the third user 
interface. 

144
00:07:41,500 --> 00:07:45,000
It's the UI for developers. 
What I've really taken from that

145
00:07:45,000 --> 00:07:47,100
is API design. 
Enters on effective 

146
00:07:47,100 --> 00:07:50,300
communication and it's not just 
communication between developers

147
00:07:50,300 --> 00:07:54,000
but it's communication that 
combines product thinking, 

148
00:07:54,300 --> 00:07:56,800
Business, and Technology 
all-in-one. 

149
00:07:56,900 --> 00:07:59,100
And so, it's always been a real 
interest to me. 

150
00:07:59,400 --> 00:08:02,500
So getting an opportunity to put
a full book together after 

151
00:08:02,500 --> 00:08:06,000
having years in the field 
working with teams, coaching 

152
00:08:06,000 --> 00:08:08,900
them API design and different 
techniques that you can use to 

153
00:08:08,900 --> 00:08:13,000
get there effectively and 
quickly without bogging down. 

154
00:08:13,000 --> 00:08:15,600
The delivery process was always 
been a passion of mine. 

155
00:08:15,700 --> 00:08:17,300
So that's been Focus of this 
book. 

156
00:08:18,000 --> 00:08:21,200
So first of all, why is it 
important to actually design? 

157
00:08:21,200 --> 00:08:23,200
An AP are. 
So you mentioned that your 

158
00:08:23,200 --> 00:08:25,000
co-author of the book told you 
about. 

159
00:08:25,100 --> 00:08:27,800
It is actually one third of the 
user interface. 

160
00:08:28,100 --> 00:08:30,900
Why is it so important to design
a pi properly? 

161
00:08:31,400 --> 00:08:34,200
I think it really does go to 
communication. 

162
00:08:34,400 --> 00:08:37,799
We don't often times think of 
our API design, as part of the 

163
00:08:37,799 --> 00:08:40,299
communication effort. 
We think of our documentation, 

164
00:08:40,299 --> 00:08:43,200
the web portals developer, 
portals marketing materials and 

165
00:08:43,200 --> 00:08:45,200
other things. 
But our design itself 

166
00:08:45,200 --> 00:08:48,100
communicates. 
The words that we choose the 

167
00:08:48,100 --> 00:08:51,400
patterns that we apply, they all
communicate to us. 

168
00:08:51,600 --> 00:08:55,600
And I think as developers we all
encounter or have encountered 

169
00:08:55,600 --> 00:08:58,800
web apis, or even just helper 
libraries in our favorite 

170
00:08:58,800 --> 00:09:01,500
programming languages. 
There were either a pleasure to 

171
00:09:01,500 --> 00:09:05,100
use or really difficult to use 
in really frustrated us. 

172
00:09:05,500 --> 00:09:09,300
So I think taking the time to 
consider your API design and 

173
00:09:09,300 --> 00:09:13,400
sintering it on an outside in 
thinking process thinking about 

174
00:09:13,400 --> 00:09:17,500
the outcomes that are desired. 
And we're trying to deliver with

175
00:09:17,500 --> 00:09:21,000
that API, really contributes to 
that effective communication, 

176
00:09:21,300 --> 00:09:24,900
and also enables great 
documentation as a result 

177
00:09:24,900 --> 00:09:27,200
because it makes it easier to 
document the API in the 

178
00:09:27,200 --> 00:09:30,100
communicate, how to do things. 
You don't spend as much time 

179
00:09:30,100 --> 00:09:33,900
saying, here are the little 
nuances or caveat sore things 

180
00:09:33,900 --> 00:09:36,600
that are kind of non-standard 
that I put in here. 

181
00:09:36,800 --> 00:09:40,400
Instead, the API design becomes 
very intuitive for the person, 

182
00:09:40,400 --> 00:09:43,200
trying to use it to build a 
solution to solve a problem to 

183
00:09:43,200 --> 00:09:45,500
automate something. 
So I think there's a lot of 

184
00:09:45,500 --> 00:09:47,800
important steps. 
Be placed in effort, centered 

185
00:09:47,800 --> 00:09:51,600
around API design first, and IMS
also assume when you say about 

186
00:09:51,600 --> 00:09:55,300
all these communications, it 
didn't just happen for a lot of 

187
00:09:55,400 --> 00:09:59,500
people who build apis, maybe 
also based on your consulting or

188
00:09:59,500 --> 00:10:01,600
expertise in people, doing this 
stuff. 

189
00:10:01,800 --> 00:10:05,000
So, why do you think those 
people do not actually empathize

190
00:10:05,000 --> 00:10:08,500
on getting the API or 
communicated with so many people

191
00:10:08,500 --> 00:10:12,500
who are connecting to it? 
I think four years API design 

192
00:10:12,500 --> 00:10:16,100
was really pushed to the 
technology teams over the years.

193
00:10:16,300 --> 00:10:18,700
we've had to make decisions 
about Frameworks and helper, 

194
00:10:18,700 --> 00:10:22,000
libraries even entire 
programming languages platforms,

195
00:10:22,100 --> 00:10:25,500
Cloud infrastructure, anything 
along the way, a lot of those 

196
00:10:25,500 --> 00:10:30,600
decisions tend to center around 
technologists, but as our 

197
00:10:30,600 --> 00:10:35,200
organizations start to think 
about how we expose web, apis to

198
00:10:35,200 --> 00:10:38,700
allow others to integrate with 
us, whether it's Corp to Corp, 

199
00:10:38,700 --> 00:10:41,900
just business-to-business kind 
of Integrations, or if it's more

200
00:10:41,900 --> 00:10:45,800
of allowing consumers to access 
the room data or to automate, 

201
00:10:46,200 --> 00:10:50,600
Oceans, whatever the case is. 
We really have to spend more 

202
00:10:50,600 --> 00:10:52,700
time. 
Emphasizing the API design. 

203
00:10:52,800 --> 00:10:55,200
So I think up to this point. 
It's just been kind of pushed 

204
00:10:55,200 --> 00:10:57,800
off to the side. 
And now, we're really seeing not

205
00:10:57,800 --> 00:11:02,200
only Tech leadership software, 
architect senior leaders, any 

206
00:11:02,200 --> 00:11:06,000
developer on a team, now, 
responsible for producing 

207
00:11:06,000 --> 00:11:10,000
delivering an API, either for 
internal use, or maybe external 

208
00:11:10,000 --> 00:11:11,900
use. 
But we're also seeing product 

209
00:11:11,900 --> 00:11:15,400
owners, get involved as well. 
So now, what we have is this 

210
00:11:15,400 --> 00:11:19,100
opportunity, Think about apis as
products and that is requiring 

211
00:11:19,100 --> 00:11:22,200
us to take a step back and to 
rethink the approaches. 

212
00:11:22,200 --> 00:11:26,200
We have to the way we approach 
apis from the design 

213
00:11:26,200 --> 00:11:28,200
perspective. 
From the coding perspective, 

214
00:11:28,400 --> 00:11:32,600
slow down and meet those parties
that have input subject matter 

215
00:11:32,600 --> 00:11:35,500
expertise to bring them along 
with us in the API design. 

216
00:11:35,500 --> 00:11:38,300
And not just to forge ahead with
the code. 

217
00:11:38,600 --> 00:11:41,300
But rather to take the 
opportunity to turn it into 

218
00:11:41,300 --> 00:11:45,000
something that centers around 
more product oriented 

219
00:11:45,000 --> 00:11:47,800
experience. 
So, you mentioned that product 

220
00:11:47,800 --> 00:11:49,800
owners, sometimes get to be 
involved. 

221
00:11:49,800 --> 00:11:54,000
But is this only for the case 
where you are building an API, 

222
00:11:54,000 --> 00:11:57,100
as a product or is it also 
applicable for people who build 

223
00:11:57,100 --> 00:11:59,800
like, back-end apis, where you 
just connect from your mobile 

224
00:11:59,800 --> 00:12:02,100
application as well. 
Maybe your web front-ends. 

225
00:12:02,400 --> 00:12:05,900
So any thought about that, we're
starting to see more and more 

226
00:12:05,900 --> 00:12:10,000
product owners get involved. 
Whether this is an API for a 

227
00:12:10,000 --> 00:12:13,300
software-as-a-service and apis, 
are product offering that an 

228
00:12:13,300 --> 00:12:15,700
organization is putting together
and releasing. 

229
00:12:16,200 --> 00:12:19,600
Or if it's just internally 
facing, it's still taking a bit 

230
00:12:19,600 --> 00:12:22,900
of time because I think from the
product owner perspective, their

231
00:12:22,900 --> 00:12:25,200
response beliefs and what 
they're held accountable for 

232
00:12:25,200 --> 00:12:29,700
tends to still be related to 
either a partner to partner 

233
00:12:29,700 --> 00:12:32,200
integration or a web or mobile 
app. 

234
00:12:32,200 --> 00:12:35,500
So we tend to still focus on the
wire frames in the features and 

235
00:12:35,500 --> 00:12:38,300
the function of the application,
but it's starting to become more

236
00:12:38,300 --> 00:12:41,200
and more apparent that through 
these digital transformation 

237
00:12:41,200 --> 00:12:44,200
efforts. 
Anything we do, whether it's 

238
00:12:44,200 --> 00:12:48,300
meant to have a human Ur face in
some way Voice Web mobile 

239
00:12:48,300 --> 00:12:51,300
whatever it is, or whether it's 
automation that there's an 

240
00:12:51,300 --> 00:12:54,800
opportunity to consider the API 
as part of the product offering.

241
00:12:55,100 --> 00:12:58,300
And so that's resulting in a lot
of product owners starting to go

242
00:12:58,300 --> 00:13:04,100
beyond their initial focus of 
just the product as its seeing 

243
00:13:04,100 --> 00:13:08,500
inexperienced and more of the 
holistic view from front to back

244
00:13:08,800 --> 00:13:12,500
and that includes the apis that 
help to power those Solutions 

245
00:13:12,500 --> 00:13:16,100
swell, so let's go to some 
principles that you at clean. 

246
00:13:16,400 --> 00:13:20,300
In the book, The First principle
is that you set API should never

247
00:13:20,300 --> 00:13:23,400
be designed in isolation. 
What do you mean by that? 

248
00:13:23,800 --> 00:13:25,900
That's really what I've been 
talking about here. 

249
00:13:26,000 --> 00:13:28,600
And that's why I've spent a good
deal of our interview so far, 

250
00:13:28,600 --> 00:13:33,300
discussing it because we have 
oftentimes required. 

251
00:13:33,400 --> 00:13:37,800
Our technical teams are delivery
teams to shape the apis 

252
00:13:37,800 --> 00:13:40,900
themselves. 
While there are quite a few 

253
00:13:40,900 --> 00:13:44,600
developers out there that have 
designed well-thought-out apis 

254
00:13:44,600 --> 00:13:46,100
before I think there's an 
opportunity. 

255
00:13:46,200 --> 00:13:49,700
Opportunity to expand our 
influence and to incorporate 

256
00:13:49,700 --> 00:13:52,700
other parts of our business in 
the process. 

257
00:13:52,700 --> 00:13:56,900
So in this case, we're going to 
have, as I said, subject matter 

258
00:13:56,900 --> 00:14:02,000
experts from product owners to 
perhaps even security teams or 

259
00:14:02,000 --> 00:14:05,300
the office of the sea. 
So that is looking at the 

260
00:14:05,300 --> 00:14:08,500
security aspects of an 
application and what kind of 

261
00:14:08,500 --> 00:14:11,900
security concerns the are with 
an API, you know, personally, 

262
00:14:11,900 --> 00:14:15,800
identifiable information and 
non-public information other 

263
00:14:15,800 --> 00:14:16,900
bits. 
Of information. 

264
00:14:16,900 --> 00:14:19,600
We may not work with leaked. 
There are different subject 

265
00:14:19,600 --> 00:14:21,200
matter, experts that should be 
consulted. 

266
00:14:21,200 --> 00:14:23,500
When we think about the apis 
too, often. 

267
00:14:23,500 --> 00:14:27,700
We've released web apis out and 
either not secure them or didn't

268
00:14:27,700 --> 00:14:30,800
think about the design from 
those different perspectives 

269
00:14:30,800 --> 00:14:34,200
from security from product 
ownership, form, the user 

270
00:14:34,200 --> 00:14:36,200
experience, and developer 
experience. 

271
00:14:36,600 --> 00:14:40,300
So the first and foundational 
principle is, we should never be

272
00:14:40,300 --> 00:14:43,700
designing apis in isolation. 
We should be looking for those 

273
00:14:43,700 --> 00:14:45,400
other team members to come with 
us. 

274
00:14:45,700 --> 00:14:48,500
We also You have to kind of slow
down as developers and if 

275
00:14:48,500 --> 00:14:51,600
necessary educate team members 
that may not be as familiar with

276
00:14:51,600 --> 00:14:53,900
some of the technical details of
HTTP. 

277
00:14:53,900 --> 00:14:56,900
And other things, just kind of 
help meet them where they're at,

278
00:14:56,900 --> 00:14:59,700
and part rep with them and move 
forward with the API design, 

279
00:14:59,700 --> 00:15:02,500
with them involved, rather than 
just going off in a corner and 

280
00:15:02,500 --> 00:15:04,400
building something. 
Because there's a lot of 

281
00:15:04,400 --> 00:15:07,900
opportunity to make apis. 
Better to make them more secure 

282
00:15:08,200 --> 00:15:12,000
and to make them longer lasting.
Yeah, which I think also led to 

283
00:15:12,000 --> 00:15:15,500
the second principle, which is 
you mention about the design 

284
00:15:15,500 --> 00:15:17,600
should start. 
An outcome-based of Focus, 

285
00:15:17,600 --> 00:15:19,300
right? 
So when you gather all these 

286
00:15:19,300 --> 00:15:21,800
people around, I'm sure there's 
a common outcome that you want 

287
00:15:21,800 --> 00:15:23,900
to get out from this API. 
Is that correct? 

288
00:15:24,300 --> 00:15:28,200
There is when I mean by the 
outcome based focus is not just 

289
00:15:28,200 --> 00:15:32,100
what these team members are 
including or wanting to factor 

290
00:15:32,100 --> 00:15:35,900
into the API design, but there's
also the aspect of who's going 

291
00:15:35,900 --> 00:15:38,900
to be using the API and what 
they're trying to do. 

292
00:15:39,200 --> 00:15:43,200
So, part of what I do, is coach 
on a technique called jobs to be

293
00:15:43,200 --> 00:15:46,000
done, which started with 
Clayton. 

294
00:15:46,100 --> 00:15:49,100
Ensign who wrote Crossing Chasm 
and several other business 

295
00:15:49,100 --> 00:15:51,800
books, his perspective was 
whether you're building a 

296
00:15:51,800 --> 00:15:55,100
start-up or whether you have a 
large Global organization, 

297
00:15:55,300 --> 00:15:58,600
anything that you do service or 
product is solving a got to be 

298
00:15:58,600 --> 00:16:01,800
done and the best way to be 
successful at it in a find 

299
00:16:01,800 --> 00:16:06,600
something that is going to do 
well is to understand the 

300
00:16:06,608 --> 00:16:10,400
customer, listen to the voice of
the customer, understand their 

301
00:16:10,400 --> 00:16:14,800
problems and what their desired 
outcomes are if we take those 

302
00:16:14,800 --> 00:16:17,400
things into consideration. 
In the piece in the middle, is 

303
00:16:17,400 --> 00:16:19,600
the job to be done. 
If we understand what the 

304
00:16:19,600 --> 00:16:22,800
situation is and what they 
really want the situation to be 

305
00:16:23,200 --> 00:16:26,500
the in state, then what we put 
in the middle is that job to be 

306
00:16:26,500 --> 00:16:28,500
done. 
So when we think about our API 

307
00:16:28,500 --> 00:16:30,800
design, we want to think about 
the same thing. 

308
00:16:30,900 --> 00:16:34,000
There's a tool called job 
stories richer and similar to 

309
00:16:34,000 --> 00:16:37,000
user stories, but they start 
with the when which is that 

310
00:16:37,000 --> 00:16:41,300
situation, the I want to, which 
is the job to be done and the, 

311
00:16:41,308 --> 00:16:46,000
so I can the outcome that they 
desire, when I talk to teens of 

312
00:16:46,100 --> 00:16:48,400
The API designer when I'm 
designing my own apis. 

313
00:16:48,400 --> 00:16:51,600
That's where I like to start. 
That means that all those team 

314
00:16:51,600 --> 00:16:53,100
members that I mentioned from 
principle. 

315
00:16:53,100 --> 00:16:56,000
Number one, that are subject 
matter, experts and have input 

316
00:16:56,000 --> 00:16:58,200
to provide or going to be 
contributing to that 

317
00:16:58,200 --> 00:17:00,900
understanding. 
And I might require our product 

318
00:17:00,900 --> 00:17:03,800
owners to take a step back and 
start talking to the target 

319
00:17:03,800 --> 00:17:05,300
audience. 
Get feedback. 

320
00:17:05,300 --> 00:17:08,599
Just like we would any other 
product and use that to help 

321
00:17:08,599 --> 00:17:11,000
Drive literary kids. 
I needs to deliver and what that

322
00:17:11,000 --> 00:17:13,599
will kind of outcomes we can 
produce as result of using that 

323
00:17:13,599 --> 00:17:17,900
API either as a standalone or 
until a Raishin, with others is 

324
00:17:17,900 --> 00:17:20,800
very interesting. 
You use this concept that is 

325
00:17:20,800 --> 00:17:22,599
normally used for building 
products. 

326
00:17:22,599 --> 00:17:25,900
So like when we want to gather 
user stories or requirements, we

327
00:17:25,900 --> 00:17:28,600
use this jobs to be done 
framework, but you mentioned 

328
00:17:28,600 --> 00:17:31,500
that you actually use this to 
actually come up with the API 

329
00:17:31,500 --> 00:17:35,100
design, what you call Job story,
you mentioned, but when I want 

330
00:17:35,100 --> 00:17:37,400
to, so I can. 
So it's really interesting that 

331
00:17:37,400 --> 00:17:39,900
you actually bring all these the
best practice from product 

332
00:17:39,900 --> 00:17:42,800
development of product, 
specification, to actually web 

333
00:17:42,800 --> 00:17:45,800
API specification as well. 
The next one in your principal 

334
00:17:45,800 --> 00:17:49,400
is a Actually, you mentioned 
that you need to select API 

335
00:17:49,400 --> 00:17:51,300
design elements that matches the
knee. 

336
00:17:51,400 --> 00:17:53,400
So I'm not very sure about this 
principle. 

337
00:17:53,400 --> 00:17:55,600
Maybe you can help to explain 
about it. 

338
00:17:55,900 --> 00:17:59,300
Yeah, I think this really stems 
from the idea that there's been 

339
00:17:59,300 --> 00:18:00,700
a lot of discussion over the 
years. 

340
00:18:00,700 --> 00:18:04,200
Do I use a rest API style. 
Do I use graphql? 

341
00:18:04,600 --> 00:18:05,900
What about grp? 
See? 

342
00:18:06,100 --> 00:18:09,200
I've shared discussions in the 
past and spoken at conferences, 

343
00:18:09,200 --> 00:18:12,000
where I kind of dispel the myth 
that there's any one particular 

344
00:18:12,000 --> 00:18:15,000
API style that's best. 
So when we think about the 

345
00:18:15,000 --> 00:18:18,400
design elements of API, we need 
to think about how people are 

346
00:18:18,408 --> 00:18:21,100
going to be using the API. 
What's the context in which 

347
00:18:21,100 --> 00:18:23,600
they're going to be using it? 
Is it primarily from a web? 

348
00:18:23,600 --> 00:18:27,200
Browsing device? 
Phone tablet, laptop. 

349
00:18:27,200 --> 00:18:30,100
Whatnot. 
Is it a voice-based? 

350
00:18:30,400 --> 00:18:33,700
Is it that we're going to be 
integrating with other systems? 

351
00:18:33,700 --> 00:18:37,000
And so we need some events. 
So we might think of things like

352
00:18:37,000 --> 00:18:43,000
web hooks or server-sent events 
or websockets, maybe Kafka 

353
00:18:43,000 --> 00:18:45,500
streams. 
If you're sharing messages 

354
00:18:45,500 --> 00:18:49,600
within an Organization across 
teams across systems, all those 

355
00:18:49,600 --> 00:18:52,500
things need to come in together 
to match the needs of the 

356
00:18:52,500 --> 00:18:55,100
consumer. 
So as we're taking a product 

357
00:18:55,100 --> 00:18:58,500
based approach, part of what we 
need to be thinking about is not

358
00:18:58,500 --> 00:19:03,800
only what the API design should 
look like, but how or what a pi 

359
00:19:03,800 --> 00:19:06,500
style, or Styles, more than one 
style. 

360
00:19:06,900 --> 00:19:11,600
Should we apply to make it the 
best match for our consumers? 

361
00:19:11,900 --> 00:19:15,700
So just because an API producer 
a team that's designing and 

362
00:19:15,700 --> 00:19:18,200
building. 
AP, I fell in love with graphql.

363
00:19:18,200 --> 00:19:20,400
Love it. 
If Their audience that's going 

364
00:19:20,400 --> 00:19:22,700
to be using API is not familiar 
with it. 

365
00:19:22,700 --> 00:19:26,400
They have two choices, one. 
They proceed with graphql and 

366
00:19:26,400 --> 00:19:29,900
they invest in educating, the 
audience on how to transition to

367
00:19:29,908 --> 00:19:32,200
graphql for those. 
That may be more familiar with 

368
00:19:32,200 --> 00:19:37,300
rest or other styles or to set 
aside their desire as a provider

369
00:19:37,600 --> 00:19:40,000
as a single team and think about
holistically. 

370
00:19:40,100 --> 00:19:42,800
All of the different things are 
going to be consuming this API 

371
00:19:43,000 --> 00:19:45,700
and determine if a different 
style will be better match. 

372
00:19:46,100 --> 00:19:50,200
Or maybe it's offering Choice 
offering both rest and graphql 

373
00:19:50,200 --> 00:19:53,500
and maybe even some event 
capabilities with web hooks for 

374
00:19:53,500 --> 00:19:57,200
callbacks when event 
notification and reactive style 

375
00:19:57,200 --> 00:20:01,200
of interaction makes more sense.
So, it's just the idea that we 

376
00:20:01,200 --> 00:20:03,700
want to recognize that. 
There's no one single solution 

377
00:20:04,300 --> 00:20:06,900
that there's no one thing that 
is best. 

378
00:20:07,400 --> 00:20:11,600
But if we factor in our target 
audience, then we'll be able to 

379
00:20:11,600 --> 00:20:15,100
determine what the best fit is 
at least for today, and we can 

380
00:20:15,100 --> 00:20:17,800
continue to listen. 
To them and then offer new 

381
00:20:17,800 --> 00:20:22,700
Styles as the needs arise that 
keeps us from being a little too

382
00:20:22,700 --> 00:20:24,900
focused on ourselves and a 
little bit more focused on the 

383
00:20:24,900 --> 00:20:27,100
variety of developers around the
world. 

384
00:20:27,100 --> 00:20:30,100
That may be one in consumer API 
and would prefer to do it in the

385
00:20:30,100 --> 00:20:32,600
way that they would, like, 
rather than the way that you 

386
00:20:32,600 --> 00:20:35,600
might want to mandate. 
I know that you mentioned as no 

387
00:20:35,600 --> 00:20:39,300
best API styles of API 
Technologies, but for those 

388
00:20:39,300 --> 00:20:42,200
techies, who listen to this, I'm
sure they will have the same 

389
00:20:42,200 --> 00:20:43,500
question. 
Is it rest? 

390
00:20:43,500 --> 00:20:44,400
Is it job? 
You see? 

391
00:20:44,400 --> 00:20:47,300
How is it graphql, right? 
The new Oh, darling in the API 

392
00:20:47,300 --> 00:20:49,200
world. 
But from your view, maybe you 

393
00:20:49,200 --> 00:20:52,300
can give us some summary. 
When do you think we should 

394
00:20:52,300 --> 00:20:54,500
choose each of those popular 
Technologies? 

395
00:20:55,000 --> 00:20:59,800
I found that rest or just basing
a web API on HTTP. 

396
00:20:59,800 --> 00:21:03,100
Typically using the rest 
architectural style is a great 

397
00:21:03,100 --> 00:21:06,900
approach because the tooling 
exists in so many languages. 

398
00:21:06,900 --> 00:21:10,700
It's so easy. 
I can use a variety of developer

399
00:21:10,700 --> 00:21:14,000
tools to assist me in the 
development process in the 

400
00:21:14,000 --> 00:21:17,800
design processes in. 
Assuming the API and trying 

401
00:21:17,800 --> 00:21:20,800
things out. 
I just see that as a popular 

402
00:21:20,800 --> 00:21:23,900
option for a lot of 
organizations that said I'm 

403
00:21:23,900 --> 00:21:27,300
seeing some organization started
to go down and explore graphql, 

404
00:21:27,300 --> 00:21:29,500
a little bit. 
They're finding that it's a 

405
00:21:29,500 --> 00:21:32,900
really great fit for the 
response shaping aspect of it, 

406
00:21:32,900 --> 00:21:34,800
even though there's other 
aspects that tends to be where 

407
00:21:34,800 --> 00:21:38,300
people gravitate toward the idea
that I can craft a query, that 

408
00:21:38,300 --> 00:21:40,000
looks a lot like a database 
query. 

409
00:21:40,200 --> 00:21:43,000
I can be very specific about the
elements that I want. 

410
00:21:43,100 --> 00:21:46,300
So if you have a very deep 
resource structure, Where you 

411
00:21:46,300 --> 00:21:49,100
have lots of nested resources 
and you don't want to have to do

412
00:21:49,100 --> 00:21:52,000
query upon query, to go, deeper 
and deeper, and you don't want 

413
00:21:52,000 --> 00:21:55,400
to implement your own version of
that on top of rest. 

414
00:21:55,800 --> 00:21:59,000
Oftentimes the teams will choose
to use rest as a foundation 

415
00:21:59,100 --> 00:22:02,200
complement it with some graphql.
The maybe, if they need some 

416
00:22:02,200 --> 00:22:05,200
high-performance service to 
service communication, they'll 

417
00:22:05,200 --> 00:22:08,800
decide to go grp, see, speeds up
the development process with the

418
00:22:08,808 --> 00:22:12,000
code generation that's built in.
And also, some of the 

419
00:22:12,000 --> 00:22:15,400
performance improvements, the 
grp see takes advantages of from

420
00:22:15,400 --> 00:22:18,000
http. 
To some of the compression of 

421
00:22:18,000 --> 00:22:20,200
headers and other things that 
are built into it and the 

422
00:22:20,200 --> 00:22:22,900
bi-directional communication, it
gets teams a lot further. 

423
00:22:23,200 --> 00:22:26,100
So again, it's not one size fits
all but I do see the majority of

424
00:22:26,100 --> 00:22:29,100
apis that I work with tend to 
start with rest and then they 

425
00:22:29,100 --> 00:22:31,900
look at other styles to 
complement it and then we see 

426
00:22:31,900 --> 00:22:35,000
things like web sockets and 
webhooks used for venting quite 

427
00:22:35,000 --> 00:22:37,400
frequently. 
And I think you mentioned, also 

428
00:22:37,400 --> 00:22:40,300
when you explain about it, you 
can mix and match. 

429
00:22:40,400 --> 00:22:43,000
So not only choose just one 
style, but you can actually 

430
00:22:43,000 --> 00:22:46,100
start with, providing rest and 
maybe some job PC on top of Of 

431
00:22:46,100 --> 00:22:49,500
it, maybe graphql for those 
people who really wants to shape

432
00:22:49,500 --> 00:22:52,600
the response of the web API. 
So thanks for sharing that 

433
00:22:52,600 --> 00:22:54,400
summary. 
So let's move on to the next 

434
00:22:54,400 --> 00:22:57,400
principle, which is I think a 
very very interesting because 

435
00:22:57,400 --> 00:23:00,200
you mentioned also in the 
beginning that API documentation

436
00:23:00,500 --> 00:23:04,200
is probably the most important 
user interface for developers. 

437
00:23:04,300 --> 00:23:07,600
I've seen in my whole career. 
It's a documentation seems to 

438
00:23:07,600 --> 00:23:11,500
vary, some are really good. 
Some even has the capability for

439
00:23:11,500 --> 00:23:14,700
you to test it on the 
documentation itself, but some 

440
00:23:14,700 --> 00:23:16,800
are just like, okay, what? 
The end points where the 

441
00:23:16,800 --> 00:23:19,100
parameters and all that. 
So maybe you can explain a 

442
00:23:19,100 --> 00:23:20,400
little bit. 
Why do you think the 

443
00:23:20,400 --> 00:23:22,400
documentation is the most 
important UI? 

444
00:23:22,700 --> 00:23:24,800
You mentioned it as the UI for 
developers. 

445
00:23:25,400 --> 00:23:28,600
The reason being is there's 
different paths that we all take

446
00:23:28,600 --> 00:23:31,800
to work with an API. 
So as a developer that's looking

447
00:23:31,800 --> 00:23:34,900
at a brand new API. 
The reference documentation is 

448
00:23:34,900 --> 00:23:37,300
very important. 
I think all of us know whether 

449
00:23:37,300 --> 00:23:40,000
it's a helper library for our 
favorite programming language, 

450
00:23:40,200 --> 00:23:43,800
or whether it's a web API is 
allowing us to take advantage of

451
00:23:43,800 --> 00:23:45,400
a software as a service 
solution. 

452
00:23:45,400 --> 00:23:48,600
Or It is the reference 
documentation, is where we spend

453
00:23:48,600 --> 00:23:52,200
the bulk of our time. 
However, there's additional 

454
00:23:52,200 --> 00:23:55,700
documentation on top, that's 
really important getting started

455
00:23:55,700 --> 00:23:58,500
guides that help frame up and 
position. 

456
00:23:58,600 --> 00:24:02,800
The API is to what it does, what
it's capable of doing cookbooks 

457
00:24:02,800 --> 00:24:06,400
or, or step-by-step guides that 
show you how to do common, tasks

458
00:24:06,700 --> 00:24:10,100
are really important as well. 
So we sometimes forget, 

459
00:24:10,100 --> 00:24:12,900
particularly when we're 
designing our own API that, just

460
00:24:12,900 --> 00:24:15,900
because we've spent a lot of 
time thinking about it design. 

461
00:24:16,100 --> 00:24:20,400
It implementing it deploying. 
It troubleshooting getting it 

462
00:24:20,400 --> 00:24:23,300
ready and push it into 
production and we've Managed IT 

463
00:24:23,300 --> 00:24:26,000
production for some time and we 
have people successfully using, 

464
00:24:26,000 --> 00:24:29,400
it doesn't necessarily mean that
next developer then encounters. 

465
00:24:29,400 --> 00:24:32,900
Your apis going to know exactly 
what your apis meant to do. 

466
00:24:33,200 --> 00:24:36,000
What you've designed it for. 
What it's good at. 

467
00:24:36,200 --> 00:24:39,100
Maybe what it doesn't focus on 
or that you would recommend 

468
00:24:39,100 --> 00:24:42,800
complementary apis to pick up 
where you leave off and how to 

469
00:24:42,800 --> 00:24:45,800
get started. 
Those type of aspects cannot be 

470
00:24:46,000 --> 00:24:49,300
be underemphasized when we think
about an API. 

471
00:24:49,400 --> 00:24:52,200
And the last thing we want to do
is developers is document. 

472
00:24:52,300 --> 00:24:55,400
I don't know why a lot of us 
have developed this habit that 

473
00:24:55,400 --> 00:24:58,700
done is when the code is done, 
and the tests are passing, and I

474
00:24:58,708 --> 00:25:02,300
can get a pushed out to a cloud 
resource in its up and running. 

475
00:25:02,600 --> 00:25:05,800
But if you don't document it, 
then those developers that are 

476
00:25:05,800 --> 00:25:08,700
trying to understand how to use 
it or get very frustrated, just 

477
00:25:08,700 --> 00:25:11,300
like you probably get frustrated
with a particular website, 

478
00:25:11,300 --> 00:25:14,000
that's poorly designed or, you 
know, a word processor 

479
00:25:14,000 --> 00:25:15,800
spreadsheet. 
This is not super intuitive. 

480
00:25:16,000 --> 00:25:18,700
A mail app that just doesn't 
work the way you want it to 

481
00:25:18,700 --> 00:25:20,500
work. 
I think all of us have probably 

482
00:25:20,500 --> 00:25:25,100
used over the last 18, 24 
months, a variety of video chat 

483
00:25:25,100 --> 00:25:28,700
and collaborative messaging 
platforms from slack, two teams 

484
00:25:28,700 --> 00:25:30,900
to WebEx to everything else 
that's out there. 

485
00:25:31,100 --> 00:25:33,400
And we have our preferences for 
what we like to use in what we 

486
00:25:33,400 --> 00:25:38,600
don't that user experience or 
that frustration that we have is

487
00:25:38,600 --> 00:25:42,800
oftentimes for web apis rooted 
in great or terrible lacking API

488
00:25:42,800 --> 00:25:45,800
documentation. 
So taking the time to document 

489
00:25:45,900 --> 00:25:48,600
Even if it means asking for 
outside help getting a technical

490
00:25:48,600 --> 00:25:49,800
writer. 
That's really good. 

491
00:25:49,800 --> 00:25:53,300
At asking you the right 
questions and getting the copy 

492
00:25:53,500 --> 00:25:55,200
so that people can understand 
it. 

493
00:25:55,200 --> 00:26:01,100
And it's approachable will make 
your API very popular because it

494
00:26:01,100 --> 00:26:04,300
stops the frustration cycle. 
And it helps people get things 

495
00:26:04,300 --> 00:26:06,200
done. 
Some of the most popular web 

496
00:26:06,200 --> 00:26:08,100
apis. 
We know of the software service 

497
00:26:08,100 --> 00:26:10,700
apis that we know of, that's 
what they did. 

498
00:26:10,900 --> 00:26:13,600
So even if you're building an 
internal API, you want other 

499
00:26:13,600 --> 00:26:15,900
people to use your API 
internally, right? 

500
00:26:16,000 --> 00:26:18,700
Little bit of documentation. 
If you're not standing up a 

501
00:26:18,700 --> 00:26:22,100
whole portal, just take the open
API spec or whatever it is. 

502
00:26:22,100 --> 00:26:24,600
You're using to capture your 
documentation, spend a little 

503
00:26:24,600 --> 00:26:28,400
time, put a few examples or walk
people through some basic use 

504
00:26:28,400 --> 00:26:31,900
cases or usage examples. 
Help people get started. 

505
00:26:31,900 --> 00:26:34,100
I have some empathy for the 
people that are seeing your API 

506
00:26:34,100 --> 00:26:36,400
for the first time. 
Maybe they're having a bad day 

507
00:26:36,400 --> 00:26:38,100
and now they have to get 
something done. 

508
00:26:38,100 --> 00:26:39,600
And this API is going to help 
them. 

509
00:26:39,900 --> 00:26:41,500
Give them a good day. 
Not a bad day. 

510
00:26:41,800 --> 00:26:45,000
So spend some time documenting 
or get some help if you need to 

511
00:26:45,200 --> 00:26:47,600
get an assist. 
From somebody contract somebody 

512
00:26:47,600 --> 00:26:50,200
and get somebody else in your 
organization, might be better at

513
00:26:50,200 --> 00:26:53,600
it to give you some tips. 
Whatever it is and really focus 

514
00:26:53,600 --> 00:26:55,900
on the documentation they can 
occur over time. 

515
00:26:55,900 --> 00:26:58,000
It doesn't have to all be done 
immediately. 

516
00:26:58,500 --> 00:27:00,700
But over time you should be 
improving as a start. 

517
00:27:00,700 --> 00:27:03,500
Simple, grow it, improve it. 
Don't let it be. 

518
00:27:03,500 --> 00:27:05,700
The last thing on your to-do 
list when you release a new 

519
00:27:05,700 --> 00:27:09,200
version of the API or make an 
improvement constantly look for 

520
00:27:09,200 --> 00:27:11,800
ways to improve it. 
Take feedback from 

521
00:27:11,800 --> 00:27:14,300
troubleshooting sessions, or 
support sessions with developers

522
00:27:14,300 --> 00:27:15,800
trying to use your API, take 
what? 

523
00:27:16,000 --> 00:27:18,400
Struggling with back and try to 
improve the documentation and 

524
00:27:18,400 --> 00:27:21,400
just continue to do that. 
It'll go a long way to making a 

525
00:27:21,400 --> 00:27:25,200
successful web API. 
Yeah, so from my experience as 

526
00:27:25,200 --> 00:27:28,800
well, it's not just the tooling 
actually to build these API 

527
00:27:28,800 --> 00:27:32,400
documentation becoming more 
varied and becomes easy as well.

528
00:27:32,400 --> 00:27:35,200
So like you mentioned open EPS 
specification, what used to be 

529
00:27:35,200 --> 00:27:39,100
known, Swagger, I think, and 
also tools like Postman, so they

530
00:27:39,100 --> 00:27:42,500
evolve into building ecosystem 
or building tools for people, 

531
00:27:42,500 --> 00:27:45,800
collaborating building API or 
using other people's API. 

532
00:27:45,900 --> 00:27:47,500
Why? 
So I think look for tools as 

533
00:27:47,500 --> 00:27:48,900
well? 
Not just like building by 

534
00:27:48,900 --> 00:27:51,100
yourself. 
I think that's also a key here. 

535
00:27:51,200 --> 00:27:53,500
Absolutely. 
Yeah, the last principle that 

536
00:27:53,500 --> 00:27:55,500
you mention in the book is 
actually this is very 

537
00:27:55,500 --> 00:27:58,200
interesting. 
Definitely, you mentioned, apis 

538
00:27:58,200 --> 00:28:00,200
are forever, but it tends to 
stick. 

539
00:28:00,300 --> 00:28:04,500
So you need to plan accordingly.
Yeah, I think many of us, in the

540
00:28:04,500 --> 00:28:07,800
API, space is dealt with web, 
apis, can understand this one. 

541
00:28:07,800 --> 00:28:12,200
And I know that Verner vogel's 
from his days at AWS, really 

542
00:28:12,300 --> 00:28:14,600
kind of solidified. 
This one through various posts 

543
00:28:14,600 --> 00:28:18,400
that he's made over the years. 
Regarding the challenges and the

544
00:28:18,400 --> 00:28:21,500
opportunities and the successes 
that AWS has had with their 

545
00:28:21,500 --> 00:28:25,500
apis, that as really codified, 
the idea that apis are forever. 

546
00:28:25,500 --> 00:28:30,100
I mean, if you think of the S3 
API from AWS just that API 

547
00:28:30,100 --> 00:28:32,700
alone, imagine if you woke up 
tomorrow and they broke 

548
00:28:32,700 --> 00:28:36,300
something. 
They changed in API signature. 

549
00:28:36,300 --> 00:28:39,300
They renamed something. 
They drop an operation that you 

550
00:28:39,300 --> 00:28:41,700
needed and that you were 
dependent on you woke up and 

551
00:28:41,700 --> 00:28:45,400
things just stopped working. 
We just can't do that when we 

552
00:28:45,400 --> 00:28:47,900
think about Web apis. 
We can't just think about a code

553
00:28:47,900 --> 00:28:50,900
base that we can refactor and 
change things with and as long 

554
00:28:50,900 --> 00:28:52,400
as it all starts to compile and 
work again. 

555
00:28:52,400 --> 00:28:54,400
We're okay. 
We're talking about distributed 

556
00:28:54,400 --> 00:28:58,400
systems many systems of which 
are outside the control of other

557
00:28:58,400 --> 00:29:01,000
people using it. 
So those that are consuming your

558
00:29:01,000 --> 00:29:03,900
web API are out of control of 
what you do is the provider and 

559
00:29:03,900 --> 00:29:05,700
vice versa. 
In that case. 

560
00:29:05,700 --> 00:29:09,500
We have to have a strategy for 
how we manage versioning how we 

561
00:29:09,500 --> 00:29:12,600
approach it being sure that 
we're not breaking people and 

562
00:29:12,600 --> 00:29:15,100
also making sure that we're not 
creating brand new versions of 

563
00:29:15,100 --> 00:29:17,700
apis. 
Every week, or every month, it's

564
00:29:17,700 --> 00:29:20,600
great to enhance an API with non
breaking changes. 

565
00:29:20,600 --> 00:29:23,900
You'll additive changes those 
types of things are great. 

566
00:29:24,200 --> 00:29:26,400
But removing things renaming 
things. 

567
00:29:26,400 --> 00:29:28,500
Those things that would break 
someone who's using that 

568
00:29:28,500 --> 00:29:31,700
operation or using that 
particular field in a response 

569
00:29:31,900 --> 00:29:34,800
or using a particular feature 
that this part of your web API. 

570
00:29:34,800 --> 00:29:37,600
And you just decide one day on 
tired of maintaining it, or I'm 

571
00:29:37,600 --> 00:29:38,600
tired of the way. 
I named this. 

572
00:29:38,600 --> 00:29:41,800
I'm going to refactor the code 
that refactoring ends up 

573
00:29:41,800 --> 00:29:45,400
changing your web API because 
you haven't separated the let it

574
00:29:45,400 --> 00:29:47,000
get caught. 
Tracked from your implementation

575
00:29:47,000 --> 00:29:48,700
details. 
And so you're unable to make it 

576
00:29:48,700 --> 00:29:50,800
still work the way it was 
designed even though you've 

577
00:29:50,800 --> 00:29:53,400
changed things internally. 
If you start to introduce 

578
00:29:53,400 --> 00:29:57,100
breaking changes, then you're 
going to introduce opportunities

579
00:29:57,100 --> 00:29:59,000
for customer Charter. 
So, if yours a 

580
00:29:59,008 --> 00:30:02,200
software-as-a-service, you have 
a web API and people are 

581
00:30:02,200 --> 00:30:04,900
integrating with your web API to
automate or integrate your 

582
00:30:04,900 --> 00:30:06,400
software as a service 
capabilities. 

583
00:30:06,400 --> 00:30:09,700
With other things that they use 
other software as a service has 

584
00:30:09,700 --> 00:30:12,200
and they're doing things to help
them and automate their lives 

585
00:30:12,500 --> 00:30:15,700
and you make a change. 
They now have to go make a coat.

586
00:30:15,900 --> 00:30:17,200
X. 
Well, they now have an 

587
00:30:17,200 --> 00:30:20,000
opportunity or a question. 
A choice ahead of them. 

588
00:30:20,400 --> 00:30:23,700
Do I make the code change? 
Or do I go find someone else? 

589
00:30:23,700 --> 00:30:26,400
Who treats customers that are 
integrating with their web API 

590
00:30:26,500 --> 00:30:29,400
with more respect and prevent 
breaking changes from coming in 

591
00:30:29,400 --> 00:30:31,800
and then me waking up to a bunch
of problems. 

592
00:30:32,400 --> 00:30:36,100
So the way that we treat our 
apis, the way we version and the

593
00:30:36,100 --> 00:30:39,900
way we manage change is really 
important and we have to plan 

594
00:30:39,900 --> 00:30:42,900
for that their strategies that 
outline in the book for that and

595
00:30:42,900 --> 00:30:45,700
different techniques you can 
think about than a Ford you 

596
00:30:45,800 --> 00:30:49,000
Unity's to make breaking changes
before you're committed to those

597
00:30:49,000 --> 00:30:52,600
designs before this designs 
become Frozen where you can only

598
00:30:52,600 --> 00:30:54,900
add new things, but you can't go
back and change those things. 

599
00:30:54,900 --> 00:30:57,200
You've already put out there. 
There's ways to do it. 

600
00:30:57,200 --> 00:31:00,400
But keeping that in mind is 
absolutely important too often. 

601
00:31:00,400 --> 00:31:02,200
We just plunge headlong into the
code. 

602
00:31:02,400 --> 00:31:03,900
We think we've got it all 
figured out. 

603
00:31:03,900 --> 00:31:05,700
We put it out there. 
It doesn't work. 

604
00:31:05,700 --> 00:31:09,000
Or doesn't meet the needs or 
expectations yet, people start 

605
00:31:09,000 --> 00:31:12,000
using the API in different ways.
And then we want to break it to 

606
00:31:12,000 --> 00:31:14,600
introduce the right way of doing
things because we don't like the

607
00:31:14,600 --> 00:31:17,400
way it turned out. 
End up causing too many problems

608
00:31:17,400 --> 00:31:21,200
and we want to avoid that. 
So I myself personally have 

609
00:31:21,200 --> 00:31:23,200
experienced. 
For example, there's an API 

610
00:31:23,200 --> 00:31:25,400
deprecation announcement or 
emails. 

611
00:31:25,400 --> 00:31:28,100
You have to move to the new API 
by this. 

612
00:31:28,400 --> 00:31:31,400
So personally I find sometimes 
it's very annoying because what 

613
00:31:31,400 --> 00:31:34,000
is working? 
Well in Michael Bay's, suddenly 

614
00:31:34,000 --> 00:31:36,600
you have to change because of 
this, I think it's very 

615
00:31:36,600 --> 00:31:40,300
important that you have this 
mindset that API that you design

616
00:31:40,300 --> 00:31:42,000
and publish them to stay 
forever. 

617
00:31:42,000 --> 00:31:45,400
I don't change it too often 
which brings us to a good 

618
00:31:45,400 --> 00:31:47,300
Segway. 
To the next discussion, you 

619
00:31:47,300 --> 00:31:51,800
mentioned API design first 
approach for many this doesn't 

620
00:31:51,800 --> 00:31:54,500
come intuitive because normally 
they will just start from 

621
00:31:54,500 --> 00:31:57,500
product requirements code and 
showcase, especially when you 

622
00:31:57,500 --> 00:31:59,800
integrate with the body between 
services. 

623
00:32:00,000 --> 00:32:02,200
So you mentioned here that 
important Concepts that I 

624
00:32:02,208 --> 00:32:03,500
learned throughout my career as 
well. 

625
00:32:03,500 --> 00:32:06,500
That API design first approach 
tend to be the best practice 

626
00:32:06,500 --> 00:32:08,500
here. 
So maybe you can elaborate on. 

627
00:32:08,500 --> 00:32:10,400
Why do you think it's the most 
important thing? 

628
00:32:11,000 --> 00:32:14,900
I think, when we think about 
building software, we went from 

629
00:32:14,900 --> 00:32:17,800
sitting down and Something about
a design and spending a little 

630
00:32:17,800 --> 00:32:21,600
time designing out our software.
Now granted a few decades ago. 

631
00:32:21,600 --> 00:32:24,800
We spent too much time there and
not enough time actually 

632
00:32:24,800 --> 00:32:27,700
producing or delivering. 
I think the pendulum swung the 

633
00:32:27,700 --> 00:32:30,600
other way where we said we'll 
code is most important thing. 

634
00:32:30,900 --> 00:32:34,300
Our code is our documentation. 
We can just kind of evolved our 

635
00:32:34,300 --> 00:32:36,900
design as we go and figure 
things out. 

636
00:32:37,000 --> 00:32:39,000
Yeah, we can do that in small 
bursts. 

637
00:32:39,000 --> 00:32:40,900
The small increments inside our 
code base. 

638
00:32:41,100 --> 00:32:44,300
Many of you listening may have 
experienced success in that way,

639
00:32:44,300 --> 00:32:47,300
and I don't discount that. 
But you also have to recognize 

640
00:32:47,300 --> 00:32:49,300
as we said with all these 
different principles that we 

641
00:32:49,300 --> 00:32:52,900
can't design in isolation that 
we have to think outcome-based. 

642
00:32:53,300 --> 00:32:56,200
Do we have to think about how 
are consumers, want to interact 

643
00:32:56,200 --> 00:32:58,700
with our apis, how we're going 
to document them and that once 

644
00:32:58,700 --> 00:33:00,700
they're out there and we have 
the first integration with our 

645
00:33:00,700 --> 00:33:02,100
API. 
It's out there forever. 

646
00:33:02,300 --> 00:33:06,200
We don't want to be tasked with 
having to keep up with your API 

647
00:33:06,200 --> 00:33:08,700
changes because you keep 
changing your mind on how your 

648
00:33:08,700 --> 00:33:10,700
design should look. 
And I've got to keep up with it 

649
00:33:10,700 --> 00:33:13,500
because you're deprecating a 
version and forcing me to write 

650
00:33:13,500 --> 00:33:15,700
more code and adjust my code to 
make things work. 

651
00:33:16,100 --> 00:33:19,400
So, there needs to be a balance 
between what we do with upfront 

652
00:33:19,400 --> 00:33:23,100
design, and how we deliver the 
book, outlines an API design 

653
00:33:23,100 --> 00:33:25,700
first approached, the idea that 
we need to spend a little 

654
00:33:25,700 --> 00:33:29,000
thought in incorporate this 
input from other team members 

655
00:33:29,400 --> 00:33:32,000
and to think about an 
outcome-based focus of what our 

656
00:33:32,000 --> 00:33:34,700
API is going to do. 
If we spend a little time doing 

657
00:33:34,700 --> 00:33:38,500
that, then we don't have to 
experience what many of us have 

658
00:33:38,500 --> 00:33:40,300
experienced. 
And I know I have is writing 

659
00:33:40,300 --> 00:33:43,200
code that never makes it into 
production because we completely

660
00:33:43,200 --> 00:33:44,800
missed it. 
We met too many assumptions that

661
00:33:44,800 --> 00:33:47,300
were incorrect. 
They're weak jump too fast to 

662
00:33:47,300 --> 00:33:50,600
write the code and we didn't ask
any clarifying questions. 

663
00:33:50,900 --> 00:33:54,000
So, what we delivered missed the
mark and now we have a few days 

664
00:33:54,000 --> 00:33:57,500
to a couple of weeks to try to 
make something work to fix the 

665
00:33:57,500 --> 00:34:00,000
things we need to fix. 
And so we, then start saying, 

666
00:34:00,000 --> 00:34:02,000
well, that's going back on the 
technical backlog. 

667
00:34:02,000 --> 00:34:04,200
Well, that's going on the 
backlog while fix it on the next

668
00:34:04,200 --> 00:34:06,000
version. 
I've experienced that way too 

669
00:34:06,000 --> 00:34:07,200
many times. 
It was frustrating. 

670
00:34:07,200 --> 00:34:10,699
So finding that balance with web
apis in particular because they 

671
00:34:10,699 --> 00:34:14,000
are forever principle. 
Number five, apis are forever to

672
00:34:14,000 --> 00:34:17,100
think about. 
How do we A lightweight. 

673
00:34:17,100 --> 00:34:21,300
Rapid API design first approach 
that will get us closer to the 

674
00:34:21,300 --> 00:34:25,300
right Mark, prevent us from 
writing or designing an API. 

675
00:34:25,300 --> 00:34:30,400
That's incorrectly or misaligned
with what really is needed and 

676
00:34:30,400 --> 00:34:33,199
still get feedback quickly. 
So that we're not doing this 

677
00:34:33,199 --> 00:34:36,400
totally in isolation in our own 
corners and it's too costly or 

678
00:34:36,400 --> 00:34:39,600
too late to make those changes. 
So that's what the aligned 

679
00:34:39,600 --> 00:34:42,900
Define design refine or addr 
processes all about. 

680
00:34:43,300 --> 00:34:47,800
Yeah, so maybe you can go and 
explain He's a DDR process. 

681
00:34:48,199 --> 00:34:50,600
It's a line defined design. 
Refine. 

682
00:34:51,000 --> 00:34:54,699
The aligned is how do we ensure 
that? 

683
00:34:54,699 --> 00:34:57,700
The API that we design is 
alignment? 

684
00:34:57,700 --> 00:35:00,400
With the outcomes that are 
desired by the developers are 

685
00:35:00,408 --> 00:35:03,500
going to using the API by the 
end users that will be 

686
00:35:03,500 --> 00:35:06,900
indirectly using that API maybe 
through a web or mobile app or 

687
00:35:06,900 --> 00:35:10,800
anything else gaining alignment 
by starting with the job 

688
00:35:10,800 --> 00:35:13,700
stories. 
Detailing those job stories out 

689
00:35:13,700 --> 00:35:15,700
to the next level where we have 
step-by-step. 

690
00:35:15,800 --> 00:35:18,900
We understand the stepwise 
process is involved to achieve 

691
00:35:18,900 --> 00:35:20,500
the outcomes that we found in 
the job. 

692
00:35:20,500 --> 00:35:23,700
Stories. 
And then defining our API, by 

693
00:35:23,700 --> 00:35:27,800
looking at those finding our API
boundaries and the API 

694
00:35:27,800 --> 00:35:30,600
operations were going to need 
independent of any one 

695
00:35:30,600 --> 00:35:33,700
particular API style. 
So I had mentioned earlier that,

696
00:35:33,700 --> 00:35:36,600
you know, we can mix and match 
things, rest, and graph, qmg, 

697
00:35:36,600 --> 00:35:39,500
our PC. 
So if we align first and 

698
00:35:39,500 --> 00:35:42,000
foremost to make sure that all 
of our assumptions are dealt 

699
00:35:42,000 --> 00:35:45,500
with that were not writing code,
that has assumptions built into 

700
00:35:45,500 --> 00:35:47,400
that. 
Are incorrect or not designing 

701
00:35:47,400 --> 00:35:50,300
an API, like why's it have 
incorrect assumptions when we 

702
00:35:50,300 --> 00:35:52,300
understand what the needs are 
with the outcomes. 

703
00:35:52,300 --> 00:35:55,700
Are we break those down to the 
next level, understand, step by 

704
00:35:55,700 --> 00:35:56,900
step? 
What we need to do. 

705
00:35:57,300 --> 00:36:00,800
Then the API design will evolve 
along with it. 

706
00:36:01,000 --> 00:36:02,500
So we go through the Align 
phase. 

707
00:36:02,500 --> 00:36:06,400
We going to Define where we turn
that step-by-step process into 

708
00:36:06,400 --> 00:36:09,500
apis that have operations to 
fulfill those step-by-step 

709
00:36:09,500 --> 00:36:11,800
processes that produce those 
outcomes. 

710
00:36:11,800 --> 00:36:15,400
We found in the alliance phase 
and then we apply one or more 

711
00:36:15,400 --> 00:36:17,900
apis. 
Styles to design the API. 

712
00:36:17,900 --> 00:36:20,600
So we might apply a rest 
approach for the majority of our

713
00:36:20,600 --> 00:36:22,800
operations, maybe offer a 
graphql. 

714
00:36:23,200 --> 00:36:27,800
All using the output of the 
Define phase an API profile that

715
00:36:27,800 --> 00:36:30,600
defines with the API supposed to
do a high-level protocol 

716
00:36:30,600 --> 00:36:33,300
agnostic. 
And in, once we designed it now,

717
00:36:33,300 --> 00:36:36,400
we have this high level design 
that we can quickly. 

718
00:36:36,400 --> 00:36:39,500
Push into an open API, spec or 
graphql. 

719
00:36:39,500 --> 00:36:42,600
Sdl, schema definition language 
or a gr. 

720
00:36:42,600 --> 00:36:45,500
PC IDL, interface definition 
language. 

721
00:36:45,700 --> 00:36:48,300
We can capture it. 
And then socialize, we can use 

722
00:36:48,300 --> 00:36:51,100
those artifacts to socialize it.
We can generate mock 

723
00:36:51,100 --> 00:36:55,000
implementations of our API using
tools that can take in one of 

724
00:36:55,000 --> 00:36:58,200
those definitions and create 
like an in-memory mock 

725
00:36:58,200 --> 00:37:01,200
implementation of it, just so 
that you can kind of try it out 

726
00:37:01,200 --> 00:37:04,000
without it really being 
completely coated up yet. 

727
00:37:04,000 --> 00:37:06,400
Now allows us to refine the 
design. 

728
00:37:06,600 --> 00:37:09,800
I go back and rework that. 
So the aligned Define design 

729
00:37:09,800 --> 00:37:13,500
refine is the four major phases.
We go through, there's different

730
00:37:13,500 --> 00:37:15,600
steps outlined in the book that 
take you step-by-step. 

731
00:37:15,800 --> 00:37:18,300
Up how to go through the Align 
phase and make sure that 

732
00:37:18,300 --> 00:37:21,400
everybody is in alignment, from 
business product, owners to the 

733
00:37:21,400 --> 00:37:24,500
tech teams. 
And then how to define the API, 

734
00:37:24,500 --> 00:37:27,100
find those boundaries, find 
those operations, then, apply 

735
00:37:27,100 --> 00:37:29,500
the apis Styles. 
You want to create the design 

736
00:37:29,700 --> 00:37:32,700
and then to circle around gain 
feedback and do that in a rapid 

737
00:37:32,700 --> 00:37:35,800
fashion. 
So you spend a little bit more 

738
00:37:35,800 --> 00:37:38,600
time up front, but you save a 
lot of time on the back end 

739
00:37:38,600 --> 00:37:41,300
where it's more costly to change
code and it can be very 

740
00:37:41,300 --> 00:37:44,100
frustrating to have to take some
well written code. 

741
00:37:44,100 --> 00:37:46,700
Well, designed code. 
And make Um last minute changes 

742
00:37:46,700 --> 00:37:49,700
in really mess it all up because
we misunderstood something the 

743
00:37:49,700 --> 00:37:53,200
beginning of tries to encourage 
communication throughout its 

744
00:37:53,200 --> 00:37:57,500
really applying the agile. 
Manifesto principles right into 

745
00:37:57,500 --> 00:38:00,500
this design process without it 
being too front-loaded or too, 

746
00:38:00,500 --> 00:38:02,600
heavy weight. 
So that's what the book outlines

747
00:38:02,600 --> 00:38:04,100
and that's what I really 
recommend. 

748
00:38:04,300 --> 00:38:07,100
It allows us to have that design
first approach so we can talk 

749
00:38:07,100 --> 00:38:09,500
about the design. 
Look at how we would integrate 

750
00:38:09,500 --> 00:38:10,800
with it. 
Make sure it's going to hit the 

751
00:38:10,800 --> 00:38:12,200
mark and we haven't missed 
anything. 

752
00:38:12,400 --> 00:38:15,300
And then we can go write our 
code and do what we do best 

753
00:38:15,300 --> 00:38:16,800
there. 
In the different delivery 

754
00:38:16,800 --> 00:38:19,700
phases. 
So I also find this kind of 

755
00:38:19,700 --> 00:38:23,300
approach very useful whenever 
you build both apis 

756
00:38:23,400 --> 00:38:26,600
independently, and also starting
from scratch, for example, so 

757
00:38:26,600 --> 00:38:29,900
especially the Tema dispersed 
geographically, for example, 

758
00:38:29,900 --> 00:38:32,400
different time zones, but you 
need to collaborate through the 

759
00:38:32,400 --> 00:38:35,300
apis for those services. 
Having gone through all these 

760
00:38:35,300 --> 00:38:38,900
aligned defined design even 
providing mocks testing for 

761
00:38:38,900 --> 00:38:41,100
people to integrate with the AP 
art. 

762
00:38:41,100 --> 00:38:43,700
So it's speed up the development
so that they can all do in 

763
00:38:43,700 --> 00:38:47,500
parallel at certain point, you 
Because it in a staging or maybe

764
00:38:47,500 --> 00:38:49,900
some kind of testing phase where
you can ensure that. 

765
00:38:49,900 --> 00:38:52,700
Okay, actually, these two 
Services can talk to each other.

766
00:38:52,900 --> 00:38:54,900
Thanks for sharing this addr 
concept. 

767
00:38:54,900 --> 00:38:56,900
I think it's really useful. 
Another thing. 

768
00:38:56,900 --> 00:39:00,200
I pick up when you mention about
this addr is you mentioned about

769
00:39:00,200 --> 00:39:02,800
API boundaries. 
What do you mean by API 

770
00:39:02,800 --> 00:39:04,900
boundaries? 
Is it something that is related 

771
00:39:04,900 --> 00:39:07,200
to bounded contacts and all 
these DDD? 

772
00:39:07,800 --> 00:39:10,000
It is here. 
So people that were looking at 

773
00:39:10,000 --> 00:39:13,900
the add or processing techniques
that we train on will recognize 

774
00:39:13,900 --> 00:39:17,700
some of them from the DDD. 
Base what I wanted to do. 

775
00:39:17,700 --> 00:39:21,500
And what I have tried to prevent
is isolating those that are not 

776
00:39:21,500 --> 00:39:24,600
familiar with DD or that are 
only practicing some of the 

777
00:39:24,600 --> 00:39:26,600
techniques and preventing them 
from being able to take 

778
00:39:26,600 --> 00:39:29,800
advantage of this process. 
So it is designed to be able to 

779
00:39:29,800 --> 00:39:32,000
incorporate many of the concepts
of tdd. 

780
00:39:32,300 --> 00:39:34,800
We use event storming and 
courage of in storming during 

781
00:39:34,800 --> 00:39:37,100
the Align phase to try the 
surface things. 

782
00:39:37,100 --> 00:39:39,300
If it's a domain that's a little
bit newer. 

783
00:39:39,300 --> 00:39:42,100
For some people bringing in 
subject matter experts from the 

784
00:39:42,100 --> 00:39:44,700
domain and having collaborative 
sessions to explore and 

785
00:39:44,700 --> 00:39:47,400
understand it. 
It is really valuable, as well 

786
00:39:47,400 --> 00:39:51,100
as what you mentioned, what the 
API boundaries, the idea is that

787
00:39:51,100 --> 00:39:54,100
I've seen a few apis over the 
years that may have hundreds and

788
00:39:54,100 --> 00:39:57,300
hundreds of operations. 
Those are just so unwieldy to 

789
00:39:57,300 --> 00:40:01,100
understand and get started with.
So unless you just really 

790
00:40:01,100 --> 00:40:05,500
surround all that, really large 
API with a lot of copious 

791
00:40:05,500 --> 00:40:08,400
documentation that guides the 
reader to where they need to be.

792
00:40:08,700 --> 00:40:11,000
Unless you do that. 
Then it's really hard to get 

793
00:40:11,000 --> 00:40:13,400
started is really not 
approachable to have to take on 

794
00:40:13,400 --> 00:40:14,800
an API. 
That's really large. 

795
00:40:15,200 --> 00:40:18,600
So the Is to bring in boundaries
where we can segment parts of 

796
00:40:18,600 --> 00:40:20,600
the API. 
That doesn't necessarily mean 

797
00:40:20,600 --> 00:40:22,700
that you have more than one API 
product. 

798
00:40:22,700 --> 00:40:25,700
It means that you're finding 
different apis or different 

799
00:40:25,700 --> 00:40:30,000
operations that are cohesive. 
So I go back to the fundamentals

800
00:40:30,000 --> 00:40:32,000
of software development, High 
cohesion. 

801
00:40:32,000 --> 00:40:35,600
Loose coupling loose coupling 
says we don't want to tie into 

802
00:40:35,600 --> 00:40:39,000
the internals of our systems 
into the implementation very 

803
00:40:39,000 --> 00:40:40,100
much. 
Like encapsulation. 

804
00:40:40,100 --> 00:40:44,100
We want to hide the internal 
details from the external API. 

805
00:40:44,100 --> 00:40:48,200
We want to loosely well in just 
couple to the API itself not to 

806
00:40:48,200 --> 00:40:49,900
the internal implementation 
details. 

807
00:40:50,100 --> 00:40:54,200
Hi could weejun is about having 
related functionality grouped 

808
00:40:54,200 --> 00:40:56,700
together in the same code base, 
rather than scattered all over 

809
00:40:56,700 --> 00:40:59,200
the code base, where it's 
hopping between module two 

810
00:40:59,200 --> 00:41:02,800
module, what we call Spaghetti 
code or big ball of mud were 

811
00:41:02,800 --> 00:41:04,200
things. 
You just all over the place and 

812
00:41:04,200 --> 00:41:06,100
there's no Rhyme or Reason for 
it. 

813
00:41:06,100 --> 00:41:08,700
All those techniques that it 
exists in PD are really 

814
00:41:08,700 --> 00:41:12,700
beneficial whether the team is 
early in their DD Journey, 

815
00:41:12,700 --> 00:41:14,400
whether they're not on a journey
at all. 

816
00:41:14,400 --> 00:41:15,500
Only. 
Just want to design. 

817
00:41:15,700 --> 00:41:19,100
Only great software or whether 
they're DDD the experts, taking 

818
00:41:19,100 --> 00:41:22,400
the time to evaluate where those
boundaries are for your apis 

819
00:41:22,700 --> 00:41:26,200
will enable you to be more 
efficient and decompose a very 

820
00:41:26,200 --> 00:41:30,100
largely scoped product or 
surface area of H operations 

821
00:41:30,100 --> 00:41:33,200
into smaller, bounded areas that
are more digestible and easier 

822
00:41:33,200 --> 00:41:37,100
to manage and easier to 
decompose for delivery by the 

823
00:41:37,100 --> 00:41:39,400
API provider. 
So we bring out some of those DD

824
00:41:39,400 --> 00:41:42,400
Concepts in throughout the 
process, but if you're not 

825
00:41:42,400 --> 00:41:44,700
practicing DDD, no need to be 
concerned. 

826
00:41:44,700 --> 00:41:47,000
It doesn't require it. 
TD for you to be able to take 

827
00:41:47,000 --> 00:41:49,400
advantage of it. 
Maybe for those people who are 

828
00:41:49,400 --> 00:41:52,200
interested in the DDD if we can 
go just slightly deeper. 

829
00:41:52,400 --> 00:41:55,500
He's a pi resource like the term
resource from rest here 

830
00:41:55,500 --> 00:41:58,300
correspond, very closely with 
the entities. 

831
00:41:58,800 --> 00:42:01,900
They do. 
What we typically do though is 

832
00:42:01,900 --> 00:42:05,100
we try to get teams to look at 
the Aggregates. 

833
00:42:05,500 --> 00:42:09,600
The Aggregates tend to be where 
the operations and commands and 

834
00:42:09,600 --> 00:42:11,900
queries that you send in tend to
Cluster around. 

835
00:42:11,900 --> 00:42:15,500
They tend to focus more on 
transactional boundaries and the

836
00:42:15,700 --> 00:42:17,800
Nation of multiple entities 
together. 

837
00:42:18,200 --> 00:42:21,000
So the resources typically 
represent the entities, but the 

838
00:42:21,000 --> 00:42:24,000
apis tend to scope to the 
aggregate. 

839
00:42:24,000 --> 00:42:27,800
So we use events storming as a 
great way to find that we can 

840
00:42:27,800 --> 00:42:31,600
lay out a particular process. 
Start with our events and the 

841
00:42:31,600 --> 00:42:34,200
start to expand and find the 
commands that generate those 

842
00:42:34,200 --> 00:42:37,300
events and then identify 
Aggregates and detail out the 

843
00:42:37,300 --> 00:42:39,300
event storming process. 
Often times. 

844
00:42:39,300 --> 00:42:42,400
Those Aggregates are really good
hints of where API boundaries 

845
00:42:42,400 --> 00:42:45,500
are at, we can look at what 
we've discovered. 

846
00:42:45,600 --> 00:42:47,400
And then reassess. 
So we can always make some 

847
00:42:47,400 --> 00:42:50,800
changes so that we have better 
cohesion if we've identified 

848
00:42:50,800 --> 00:42:53,400
multiple Aggregates, but maybe 
they belong together in a web 

849
00:42:53,400 --> 00:42:56,600
API because we have to keep in 
mind a lot of web apis because 

850
00:42:56,600 --> 00:43:00,000
they're going over a network 
must be more coarse grained than

851
00:43:00,000 --> 00:43:03,800
our DDD code bases that tend to 
be more granular and can operate

852
00:43:03,800 --> 00:43:06,600
in process. 
So when you go to a distributed 

853
00:43:06,600 --> 00:43:11,000
architecture where we have web 
apis, we don't want to have too 

854
00:43:11,000 --> 00:43:13,300
much Network. 
Traffic won't be too chatty. 

855
00:43:13,800 --> 00:43:16,700
So we have to start looking at 
how What are we interacting over

856
00:43:16,700 --> 00:43:19,800
the network, which is different 
architectural style, than how we

857
00:43:19,800 --> 00:43:24,100
might, architect a standalone 
code base, and process that may 

858
00:43:24,100 --> 00:43:26,900
expose that API. 
And how we coded up internally 

859
00:43:27,300 --> 00:43:31,100
looking at DDD. 
We really want to focus first on

860
00:43:31,107 --> 00:43:34,900
the Aggregates and then allow 
that aggregate to help Drive the

861
00:43:34,900 --> 00:43:37,900
API operations. 
And then behind the scenes, we 

862
00:43:37,900 --> 00:43:40,400
continue to apply d. 
D d, Ed smaller and smaller 

863
00:43:40,400 --> 00:43:42,500
levels as we realized the API 
during delivery. 

864
00:43:43,300 --> 00:43:45,200
That's why explaining all this 
and clarifying. 

865
00:43:45,300 --> 00:43:48,800
How How does these two concepts 
actually help each other all 

866
00:43:48,800 --> 00:43:51,600
aligned with each other? 
So thanks for sharing that maybe

867
00:43:51,600 --> 00:43:54,600
the last point about API. 
So you kind of like design, your

868
00:43:54,600 --> 00:43:56,800
kind of like develop it, you 
kind of like put the 

869
00:43:56,800 --> 00:44:00,000
documentation but how about the 
testing strategies? 

870
00:44:00,200 --> 00:44:02,700
Because at the end of the day 
people just want to integrate 

871
00:44:02,700 --> 00:44:04,400
with your EPA. 
First, of course, they will need

872
00:44:04,400 --> 00:44:06,000
to go through the testing 
strategies. 

873
00:44:06,300 --> 00:44:08,900
Maybe you can elaborate some of 
the testing strategies that you 

874
00:44:08,900 --> 00:44:11,100
commonly see throughout your 
Consulting. 

875
00:44:11,500 --> 00:44:13,500
Yeah. 
Yeah, one of the anti patterns 

876
00:44:13,500 --> 00:44:17,800
that I see is that teams just In
off with building apis because 

877
00:44:17,800 --> 00:44:20,400
they're often times have a front
end to them. 

878
00:44:20,700 --> 00:44:24,500
They'll use their UI testing 
sweets, whether it's selenium or

879
00:44:24,500 --> 00:44:28,600
something like it to drive front
end test Suites to build those 

880
00:44:28,600 --> 00:44:32,100
and they'll assume that their 
apis tested because they tested 

881
00:44:32,100 --> 00:44:35,300
their friend. 
You are the problem with that is

882
00:44:35,300 --> 00:44:39,600
that often times our front-end 
application whether its web 

883
00:44:39,600 --> 00:44:42,900
interface or mobile or whatnot, 
they're doing front and 

884
00:44:42,900 --> 00:44:44,500
validation client, side 
validation. 

885
00:44:44,500 --> 00:44:47,700
So a row Aeneas request. 
We'll never make it to the back 

886
00:44:47,700 --> 00:44:50,200
end server because on our client
is catchy and time. 

887
00:44:50,400 --> 00:44:53,300
So you're testing the client 
that it's validating the input 

888
00:44:53,300 --> 00:44:55,200
before it goes to the server, 
but you're not really getting a 

889
00:44:55,207 --> 00:44:59,000
chance to test the server. 
So just relying strictly on UI 

890
00:44:59,000 --> 00:45:02,400
based testing to exercise. 
Our API is just not sufficient 

891
00:45:02,400 --> 00:45:04,100
enough. 
It's a good start the 

892
00:45:04,100 --> 00:45:06,400
integration from front and the 
back end making sure 

893
00:45:06,400 --> 00:45:08,900
everything's working but it's 
not the complete story. 

894
00:45:09,200 --> 00:45:12,200
So the other things that I 
recommend is one is looking at 

895
00:45:12,200 --> 00:45:14,400
Contract testing. 
This can be automated. 

896
00:45:14,400 --> 00:45:15,500
There's a lot of tools out 
there. 

897
00:45:15,600 --> 00:45:18,500
Now we're starting to merge that
you, if you capture your API 

898
00:45:18,500 --> 00:45:22,300
contractor, you had scription 
and say, open API spec what you 

899
00:45:22,300 --> 00:45:24,700
speak of swagger. 
As you mentioned earlier, if we 

900
00:45:24,700 --> 00:45:27,700
use that, there are some tools 
that will read that description 

901
00:45:27,700 --> 00:45:31,900
which is machine readable and 
we'll turn it into a starting 

902
00:45:31,900 --> 00:45:33,700
point for a suite of automated 
tests. 

903
00:45:33,700 --> 00:45:36,100
There's some commercial tools 
like that is, if you open 

904
00:45:36,100 --> 00:45:38,600
source, libraries and others 
that can help make sure that the

905
00:45:38,600 --> 00:45:41,200
API is doing what it says. 
It will do that. 

906
00:45:41,200 --> 00:45:43,600
Your code matches. 
What the spec says. 

907
00:45:43,600 --> 00:45:45,400
That's captured an opening 
Prospect. 

908
00:45:45,700 --> 00:45:47,900
The other thing you could do is 
integration or acceptance. 

909
00:45:47,900 --> 00:45:50,500
Testing. 
I prefer to really just focus on

910
00:45:50,500 --> 00:45:53,800
acceptance testing which takes 
the job stories and the activity

911
00:45:53,800 --> 00:45:58,000
steps from our line, phase of 
the addr process and turns those

912
00:45:58,000 --> 00:46:01,500
into executable code. 
So those that are familiar with 

913
00:46:01,500 --> 00:46:05,600
behavior, driven design bdd 
things, a cucumber Frameworks 

914
00:46:05,600 --> 00:46:09,900
like that are probably familiar 
with the wind and and so one 

915
00:46:09,900 --> 00:46:13,400
kind of those types of formats. 
You can likewise take the work 

916
00:46:13,400 --> 00:46:15,400
that you did upfront during the 
design the alive. 

917
00:46:15,600 --> 00:46:18,800
Unfazed and turn that into 
acceptance tests that can verify

918
00:46:18,800 --> 00:46:21,600
that all your apis. 
When combined together can 

919
00:46:21,600 --> 00:46:25,600
produce the outcomes that you 
initially defined in the job 

920
00:46:25,600 --> 00:46:29,200
stories during the Align phase. 
So you're taking all the work 

921
00:46:29,200 --> 00:46:31,800
that you do upfront and that's 
going to in turn drive your 

922
00:46:31,800 --> 00:46:35,000
testing to make sure that your 
API delivers on what you 

923
00:46:35,000 --> 00:46:38,200
initially identified in the 
aligned phase is what the API 

924
00:46:38,200 --> 00:46:41,500
needs to do. 
So doing acceptance, testing 

925
00:46:41,500 --> 00:46:43,800
around our API in that way is 
really valuable. 

926
00:46:44,000 --> 00:46:46,400
Some teams will do it with you. 
Seeing tools, like you mentioned

927
00:46:46,400 --> 00:46:49,100
in like Postman and others that 
have collections that are built 

928
00:46:49,100 --> 00:46:52,700
up that exercise each step and 
maybe script the transition from

929
00:46:52,700 --> 00:46:55,400
one call to the next pulling 
data along the way. 

930
00:46:55,400 --> 00:46:58,300
So the output of one called 
turns into the input of the next

931
00:46:58,300 --> 00:47:01,800
call, so they can make those 
orchestrated calls and make sure

932
00:47:01,800 --> 00:47:05,300
that things end up in the final 
outcome state that we want, or 

933
00:47:05,300 --> 00:47:08,900
they might write it by hand or 
some combination to do that. 

934
00:47:09,100 --> 00:47:11,800
So those are just kind of the 
high level ideas I have there 

935
00:47:11,800 --> 00:47:14,600
but there's more that's going to
detail about the book, but it's 

936
00:47:14,600 --> 00:47:16,800
really important to make sure. 
Have a solid testing strategy. 

937
00:47:16,800 --> 00:47:19,700
And if you do this design first 
approach, then you have all the 

938
00:47:19,700 --> 00:47:21,700
artifacts. 
You need to help inform you of 

939
00:47:21,700 --> 00:47:23,300
what kind of test you need to 
write. 

940
00:47:23,400 --> 00:47:25,900
You just need the right them. 
So it really makes a lot of 

941
00:47:25,900 --> 00:47:27,500
sense to build a pull all that 
together. 

942
00:47:28,000 --> 00:47:30,700
Thanks for sharing some and 
Tibetans like, you know, testing

943
00:47:30,700 --> 00:47:33,300
from just the UI. 
So I think here also it's 

944
00:47:33,300 --> 00:47:36,500
applicable to apply the test 
pyramid principle right? 

945
00:47:36,600 --> 00:47:39,600
Where you don't just have all 
the UI based testing, but you 

946
00:47:39,600 --> 00:47:43,100
have lesser integration or 
acceptance test part of the you 

947
00:47:43,100 --> 00:47:45,100
iPod. 
Thanks for sharing that so 

948
00:47:45,100 --> 00:47:46,600
James. 
He's been really great to talk 

949
00:47:46,600 --> 00:47:48,700
about all these apis. 
I learned a lot all these 

950
00:47:48,700 --> 00:47:51,600
principles and the tools and 
also the concept that you 

951
00:47:51,600 --> 00:47:54,000
mentioned. 
But like job stories, addr. 

952
00:47:54,100 --> 00:47:56,200
Unfortunately, we have to end 
this conversation. 

953
00:47:56,300 --> 00:47:58,500
But before I end this 
conversation, normally I would 

954
00:47:58,500 --> 00:48:01,400
ask all my guests to share the 
three technical leadership 

955
00:48:01,400 --> 00:48:03,400
wisdom. 
So this is mainly for you to 

956
00:48:03,400 --> 00:48:06,700
actually advise other people 
based on your experience or your

957
00:48:06,700 --> 00:48:08,700
knowledge. 
So what will be your three 

958
00:48:08,700 --> 00:48:11,000
technical leadership wisdom. 
Yeah. 

959
00:48:11,000 --> 00:48:13,500
I think the first one and it's 
one that I try to really 

960
00:48:13,500 --> 00:48:16,800
incorporate into my workshops is
Be curious not only of new 

961
00:48:16,800 --> 00:48:20,000
technology, but of our software 
development history. 

962
00:48:20,400 --> 00:48:23,500
I think we tend to always strive
to see the new and interesting 

963
00:48:23,500 --> 00:48:26,400
and that shiny new things. 
But if we go backwards a little 

964
00:48:26,400 --> 00:48:29,000
bit sometimes and look at what 
people have done in the past and

965
00:48:29,000 --> 00:48:31,100
learn from those that came 
before us. 

966
00:48:31,500 --> 00:48:34,300
There are a lot of lessons, we 
can learn that we can then 

967
00:48:34,400 --> 00:48:37,400
apply, as we move forward with 
software development. 

968
00:48:37,400 --> 00:48:39,500
There's a lot of wisdom out 
there and sometimes we just 

969
00:48:39,500 --> 00:48:42,300
ignore it because we feel like, 
it's maybe two older or not 

970
00:48:42,300 --> 00:48:45,300
relevant today, but a lot of it 
still is relevant even though 

971
00:48:45,500 --> 00:48:47,800
Though, maybe the technologies 
have changed. 

972
00:48:47,800 --> 00:48:50,200
We're doing were distributed 
computing than we used to. 

973
00:48:50,400 --> 00:48:52,500
There's a lot of history out 
there that I think people should

974
00:48:52,500 --> 00:48:55,100
be students of and so I try to 
incorporate that to my workshops

975
00:48:55,100 --> 00:48:57,400
a little bit as I go just so 
that people can gain that 

976
00:48:57,400 --> 00:49:00,000
Insight if they haven't been 
exposed to it previously. 

977
00:49:00,500 --> 00:49:04,600
The second thing is to always 
evaluate new technologies and 

978
00:49:04,600 --> 00:49:07,600
light of what we've learned from
that history, oftentimes will 

979
00:49:07,600 --> 00:49:10,400
see new things, come up 
development team puts them 

980
00:49:10,400 --> 00:49:12,700
together and you open source 
project, put something together 

981
00:49:12,700 --> 00:49:15,400
and they think to the first one 
to have ever done it in reality.

982
00:49:15,500 --> 00:49:17,700
Have it. 
In fact, when story is that, 

983
00:49:17,700 --> 00:49:20,500
I've had a client that ended up 
re-implementing a message, 

984
00:49:20,500 --> 00:49:23,600
broker over HTTP. 
So they effectively got pretty 

985
00:49:23,600 --> 00:49:27,000
close to AWS has sqs, and they 
didn't even know it. 

986
00:49:27,100 --> 00:49:29,400
They didn't know those 
Technologies existed, you know, 

987
00:49:29,400 --> 00:49:31,800
it's no fault of theirs. 
All of them on that team had 

988
00:49:31,800 --> 00:49:35,300
never really had a need for 
message-oriented middleware or 

989
00:49:35,300 --> 00:49:38,000
traditional message. 
Brokers think rabbitmq, things 

990
00:49:38,000 --> 00:49:40,200
like that. 
They just never encountered it. 

991
00:49:40,300 --> 00:49:42,400
And so they ended up 
re-implementing the same thing 

992
00:49:42,400 --> 00:49:44,800
themselves, but it was a little 
less reliable. 

993
00:49:44,800 --> 00:49:48,000
So we I evaluated that and 
consider how we could learn from

994
00:49:48,000 --> 00:49:50,200
technology has been around, will
be the best fit for them. 

995
00:49:50,300 --> 00:49:53,300
The third thing I would say is 
passing what you learn to the 

996
00:49:53,300 --> 00:49:55,400
Next Generation. 
I think there's been several 

997
00:49:55,400 --> 00:49:57,700
studies that have indicated that
a half-life of a developer in 

998
00:49:57,700 --> 00:49:59,900
our industry tends to be around 
five years. 

999
00:50:00,100 --> 00:50:03,200
So that means that we're not 
really always doing a great job 

1000
00:50:03,200 --> 00:50:07,100
of helping the newer generation 
become more familiar, not only 

1001
00:50:07,100 --> 00:50:10,200
with our history and knowing how
to evaluate new technologies, 

1002
00:50:10,500 --> 00:50:13,600
but just the wisdom that we've 
gained in learning how to code. 

1003
00:50:13,900 --> 00:50:17,700
So software development can be A
very solitary role at times. 

1004
00:50:17,700 --> 00:50:20,500
We can put our headphones on and
get into that zone and really 

1005
00:50:20,500 --> 00:50:21,900
have a good time. 
Writing code. 

1006
00:50:21,900 --> 00:50:24,400
That might be our passion and I 
enjoy that as well. 

1007
00:50:24,400 --> 00:50:28,800
But it's important to step out 
and help others, and listen, and

1008
00:50:28,800 --> 00:50:32,300
learn from others as well. 
So passing on what you learned 

1009
00:50:32,300 --> 00:50:33,400
and then learning from other 
people. 

1010
00:50:33,800 --> 00:50:36,300
That's the third one. 
Thanks also for spending your 

1011
00:50:36,300 --> 00:50:38,400
time. 
He had to pass on what you know 

1012
00:50:38,400 --> 00:50:41,400
to all those software developers
who are still learning or maybe 

1013
00:50:41,400 --> 00:50:44,500
developing web apis. 
So, thanks games again, for 

1014
00:50:44,500 --> 00:50:47,700
people who want to To follow you
online or get to know more about

1015
00:50:47,700 --> 00:50:49,100
your work. 
Where can they find you? 

1016
00:50:49,500 --> 00:50:51,700
My company website? 
You can reach me in find 

1017
00:50:51,700 --> 00:50:54,200
articles that I've written. 
Another insights is at launch. 

1018
00:50:54,200 --> 00:51:01,300
Any.com., That's Lau in ch a in 
why.com., That's my consultancy.

1019
00:51:01,700 --> 00:51:05,000
I also have a newsletter called 
API developer weekly. 

1020
00:51:05,000 --> 00:51:07,200
So you go to API developer 
weekly.com. 

1021
00:51:07,500 --> 00:51:10,300
It's a weekly hand curated 
newsletter, where I focus on a 

1022
00:51:10,308 --> 00:51:14,800
lot of API related articles and 
non API articles whenever I find

1023
00:51:14,800 --> 00:51:15,700
something interesting. 
Doing. 

1024
00:51:15,700 --> 00:51:17,000
So I just send it out once a 
week. 

1025
00:51:17,200 --> 00:51:19,500
It'll keep you up to date on 
what's Happening and interesting

1026
00:51:19,500 --> 00:51:22,700
developments case, studies other
things to get written by other 

1027
00:51:22,700 --> 00:51:24,600
people. 
I share that out every week. 

1028
00:51:25,000 --> 00:51:26,800
So make sure to put that in the 
show notes. 

1029
00:51:26,800 --> 00:51:27,800
So, thanks again. 
James. 

1030
00:51:27,900 --> 00:51:30,000
I wish you good luck with all 
the consultancy and helping 

1031
00:51:30,000 --> 00:51:32,700
people to build a proper API. 
Thanks Henry. 

1032
00:51:32,700 --> 00:51:37,700
Appreciate it. 
Thank you for listening to this 

1033
00:51:37,700 --> 00:51:40,300
episode and for staying right 
till the end. 

1034
00:51:40,500 --> 00:51:43,400
If you highly enjoyed, please 
share it with your friends and 

1035
00:51:43,400 --> 00:51:46,800
colleagues who you think would 
also benefit from listening to 

1036
00:51:46,800 --> 00:51:49,000
this episode. 
And if you're new to the 

1037
00:51:49,000 --> 00:51:52,400
podcast, make sure to subscribe 
and leave me your valuable 

1038
00:51:52,400 --> 00:51:55,700
review and feedback. 
It really, really helps me a lot

1039
00:51:55,800 --> 00:51:58,300
in order to grow these podcasts 
better. 

1040
00:51:58,800 --> 00:52:02,100
You can also find the full show 
notes of this conversation on 

1041
00:52:02,100 --> 00:52:05,300
the episode page at technology. 
No, the death website. 

1042
00:52:05,600 --> 00:52:08,900
Including the full transcript 
interesting quotes, and links to

1043
00:52:08,900 --> 00:52:11,800
the resources and mentions from 
the conversation. 

1044
00:52:12,200 --> 00:52:15,100
And lastly make sure to 
subscribe to the show's mailing 

1045
00:52:15,100 --> 00:52:18,300
list on technology. 
No, the deaf to get notified for

1046
00:52:18,300 --> 00:52:21,100
any future episodes. 
Stay tuned for the next 

1047
00:52:21,100 --> 00:52:23,600
technique Journal episode. 
And until then. 

1048
00:52:23,800 --> 00:52:24,400
Goodbye.