Max Stoiber!

1
00:00:00,000 --> 00:00:07,480
321. Welcome everybody to the last tech podcast. My name is
2
00:00:07,480 --> 00:00:11,760
Eve and I'm so happy to have on the show today the co founder
3
00:00:11,760 --> 00:00:15,680
and CEO of Stellate. Please welcome to this show Max
4
00:00:15,680 --> 00:00:17,880
Stoiber. Max, thanks so much for being here.
5
00:00:18,240 --> 00:00:20,040
Thank you for having them excited for this conversation
6
00:00:20,040 --> 00:00:20,400
today.
7
00:00:20,600 --> 00:00:26,120
Yeah, me too. So Max, you've had this amazing career, you've
8
00:00:26,120 --> 00:00:30,600
created really popular open source projects. Spectrum was a
9
00:00:30,600 --> 00:00:34,880
company that was required acquired by GitHub, right? And
10
00:00:34,880 --> 00:00:38,960
then you worked at Gatsby for a little bit, but now you're
11
00:00:38,960 --> 00:00:42,640
working at this amazing company Stellate. Tell me a little bit
12
00:00:42,640 --> 00:00:45,080
more about how that all came to be.
13
00:00:47,120 --> 00:00:50,200
How much time do you have? Can I keep going here for two hours?
14
00:00:50,320 --> 00:00:54,280
No, I'll give you the long and short version. I found my love
15
00:00:54,280 --> 00:00:58,680
for building products and building sort of things that
16
00:00:58,680 --> 00:01:02,160
people can use very early on in life. And so I ended up making a
17
00:01:02,160 --> 00:01:04,800
career out of really in the first in the front end world and
18
00:01:04,800 --> 00:01:07,000
then in the full stack JavaScript, TypeScript world,
19
00:01:07,880 --> 00:01:11,040
building products, but also building lots of open source
20
00:01:11,040 --> 00:01:13,560
projects like style components and reg boilerplate. I ended up
21
00:01:13,560 --> 00:01:16,480
joining the react community really early on back in 2015,
22
00:01:16,480 --> 00:01:19,720
maybe 16, shortly after its release. And as we all know,
23
00:01:19,760 --> 00:01:23,040
react was sort of a an island without a lot of the stuff around
24
00:01:23,040 --> 00:01:25,440
it being released. And so the community had to step in and a
25
00:01:25,440 --> 00:01:28,040
lot of that stuff. I was a part of ended up being a part of
26
00:01:28,120 --> 00:01:30,640
out of necessity because I loved react, and I wanted to use it and
27
00:01:30,640 --> 00:01:34,240
I needed to close all those gaps. And through that ended up really
28
00:01:34,240 --> 00:01:37,240
loving the broader developer space I worked on spectrum,
29
00:01:37,520 --> 00:01:39,640
co-founded spectrum where we were building sort of a modern
30
00:01:39,640 --> 00:01:42,920
take on community forums for open source projects that
31
00:01:42,920 --> 00:01:45,720
eventually got acquired by GitHub and turned into GitHub
32
00:01:45,720 --> 00:01:49,560
discussions, which I'm sure many of you folks have used, then
33
00:01:49,560 --> 00:01:53,760
worked at Gatsby, because, again, love developer experience
34
00:01:53,760 --> 00:01:56,760
love working on things that help people build faster and build
35
00:01:56,760 --> 00:02:00,320
better. And then now co-founded stellate and so it really came
36
00:02:00,320 --> 00:02:02,280
to be because at spectrum, we were using GraphQL for
37
00:02:02,280 --> 00:02:06,000
everything and loving it. And we were loving GraphQL. And we
38
00:02:06,000 --> 00:02:08,800
had huge scaling problems due to other parts of our stack. And
39
00:02:08,880 --> 00:02:12,240
as we grew, I realized if I can just put a cache in front of my
40
00:02:12,240 --> 00:02:14,680
API, that's going to solve a lot of our scaling problems because
41
00:02:14,680 --> 00:02:17,840
we have super public and super read heavy traffic and data. And
42
00:02:17,840 --> 00:02:20,560
so that could alleviate a lot of the load, but nothing existed.
43
00:02:20,720 --> 00:02:22,600
And I looked at that problem. And I went, that's kind of weird
44
00:02:22,600 --> 00:02:25,440
because GraphQL clients do this in the browser. Why can't
45
00:02:25,440 --> 00:02:27,840
somebody just do this either on the server or ideally at the
46
00:02:27,840 --> 00:02:30,200
CDN level, right, especially the normalized caching, which is a
47
00:02:30,200 --> 00:02:32,600
lot of the powerfulness of GraphQL clients, but it didn't
48
00:02:32,600 --> 00:02:35,000
exist. And then, you know, later after GitHub acquired spectrum
49
00:02:35,000 --> 00:02:37,640
and even two years or two, three years of that, nobody built it.
50
00:02:37,640 --> 00:02:39,840
And I was like, that's kind of ridiculous. And I met Tim and
51
00:02:39,840 --> 00:02:41,880
Tim had actually built a prototype, my co-founder Tim had
52
00:02:41,880 --> 00:02:44,120
built a prototype of it. And I was like, we should turn this,
53
00:02:44,160 --> 00:02:45,920
we got to turn this into a product, like people are going
54
00:02:45,920 --> 00:02:48,520
to need this. And so for the last three, more than three years
55
00:02:48,520 --> 00:02:50,880
now at this point, we've really been in the GraphQL space
56
00:02:50,880 --> 00:02:53,160
building, first the edge caching and now expanding into
57
00:02:53,360 --> 00:02:55,400
graphical metrics and graphical security, just trying to help
58
00:02:55,400 --> 00:02:58,440
people sort of with problems that they might face by being in
59
00:02:58,440 --> 00:03:00,840
front of any GraphQL API that you can think of. That's really
60
00:03:00,840 --> 00:03:01,280
what we do.
61
00:03:02,040 --> 00:03:02,720
Totally.
62
00:03:03,120 --> 00:03:05,560
That's really been a very short summary of my journey. There's
63
00:03:05,560 --> 00:03:08,040
lots of nuances and, you know, twists and turns, but that's the
64
00:03:08,040 --> 00:03:10,480
Instagram version of it. Instagram story version of my
65
00:03:10,480 --> 00:03:11,600
journey over the last years.
66
00:03:11,600 --> 00:03:15,440
I love it. And yeah, I think as you said, GraphQL is so, those
67
00:03:15,440 --> 00:03:18,760
are the perennial questions that people have when they're
68
00:03:18,760 --> 00:03:21,880
actually rolling it out, right? It's like caching, security,
69
00:03:21,920 --> 00:03:25,680
metrics, how do we look at how this GraphQL API is actually
70
00:03:25,680 --> 00:03:30,000
working? So I know that you're just making everyone's lives way
71
00:03:30,000 --> 00:03:34,560
easier. So that's really cool. So you chose GraphQL as a
72
00:03:34,560 --> 00:03:38,000
technology after using it and feeling like it was a great
73
00:03:38,000 --> 00:03:43,840
thing. And we've been around in the GraphQL trenches for a long
74
00:03:43,840 --> 00:03:47,120
time. And I think, from my perspective, correct me if I'm
75
00:03:47,120 --> 00:03:51,120
wrong, it started out, all these React developers loved it. It
76
00:03:51,120 --> 00:03:54,440
was this thing that everyone needed and wanted so much. And
77
00:03:54,440 --> 00:03:59,760
then it seems like the user of a GraphQL app has changed a lot
78
00:04:00,560 --> 00:04:03,880
from this like front end person who's trying to load data into
79
00:04:03,880 --> 00:04:07,360
their components to someone trying to really read it and
80
00:04:07,360 --> 00:04:13,120
trying to really wrangle data for the back end. So how do you
81
00:04:13,120 --> 00:04:16,480
think that GraphQL, the perception of GraphQL has
82
00:04:16,480 --> 00:04:17,560
changed over time?
83
00:04:19,800 --> 00:04:22,160
That's a great question. I think GraphQL was released back in
84
00:04:22,160 --> 00:04:25,160
2015, 16 as well. I want to say it's like almost 10 years old at
85
00:04:25,160 --> 00:04:28,840
this point. And Facebook really invented it as, because they
86
00:04:28,840 --> 00:04:31,840
needed a central intermediary layer between their many, many
87
00:04:31,840 --> 00:04:34,080
clients, right? Their mobile apps, their web apps, their TV
88
00:04:34,080 --> 00:04:36,760
apps, their whatever other apps they have, and their many, many
89
00:04:36,760 --> 00:04:40,120
microservices and data sources in the back end. And they sort
90
00:04:40,120 --> 00:04:42,280
of invented this new language and this new tool chain so that
91
00:04:42,280 --> 00:04:44,360
they could work across all these different microservices written
92
00:04:44,360 --> 00:04:46,680
in different languages, sort of connect them all together into
93
00:04:46,680 --> 00:04:50,600
a central schema and centralized data access plane. And then they
94
00:04:50,600 --> 00:04:53,480
released it. And then classic Facebook open source style, they
95
00:04:53,480 --> 00:04:55,920
just released it and gave it to people and didn't say much about
96
00:04:55,920 --> 00:04:59,040
it. They sort of gave a talk and then let everybody just do
97
00:04:59,040 --> 00:05:01,560
whatever they wanted. And inevitably, people looked at it.
98
00:05:01,920 --> 00:05:04,880
And at the time, back in 2015, 2016, even though that might
99
00:05:04,880 --> 00:05:08,000
seem a little bit ridiculous now, it was almost the only way to
100
00:05:08,000 --> 00:05:11,360
build a fully type safe API with flow or TypeScript back then.
101
00:05:11,360 --> 00:05:14,960
Like there really, there was no TRPC, there was no, you know,
102
00:05:14,960 --> 00:05:17,600
full react, nevermind, react server components. There was no
103
00:05:17,600 --> 00:05:20,640
way to access data in a type safe way. And so GraphQL enabled
104
00:05:20,640 --> 00:05:23,440
that. And so lots of people adopted it for that reason,
105
00:05:23,440 --> 00:05:25,680
because they were like, oh, I finally, I can build a type safe
106
00:05:25,680 --> 00:05:30,160
API. But for just building a type safe API, it's a pretty
107
00:05:30,160 --> 00:05:32,160
heavy solution. Like it's a whole new language, it's a whole
108
00:05:32,160 --> 00:05:34,160
new tool chain, you need a whole new client, a whole new
109
00:05:34,160 --> 00:05:36,560
server, it requires you to rethink how you access data.
110
00:05:36,560 --> 00:05:39,280
Like it's a really pretty heavy thing for just getting types
111
00:05:39,280 --> 00:05:42,480
for an API, right? Or even if you're in react server
112
00:05:42,480 --> 00:05:44,640
components world now, just getting types from a database
113
00:05:44,640 --> 00:05:47,920
queries, right? Like that is a whole new layer that you're
114
00:05:47,920 --> 00:05:51,280
introducing to solve a much simpler problem. And so over
115
00:05:51,280 --> 00:05:54,160
time, as people realized, oh, actually, GraphQL is kind of
116
00:05:54,160 --> 00:05:56,880
heavy, and it's kind of complicated, and you really just
117
00:05:56,880 --> 00:05:59,360
want types from API, better solutions for that emerge,
118
00:05:59,360 --> 00:06:02,960
right? TRPC came out, now react server components are sort of
119
00:06:02,960 --> 00:06:04,640
there, and they're likely going to simplify a lot of those
120
00:06:04,640 --> 00:06:08,560
use cases even further. And really, that problem of, I want
121
00:06:08,560 --> 00:06:11,440
sort of type safe data access on the clients got solved in
122
00:06:11,440 --> 00:06:13,680
much simpler ways and rightfully so because GraphQL is a very
123
00:06:13,680 --> 00:06:16,720
heavy solution for that. But funny enough, I think through
124
00:06:16,720 --> 00:06:20,720
that, GraphQL sort of got a bad rep because people tried it
125
00:06:20,720 --> 00:06:22,560
and they were like, oh, it's so heavy, so I'm never going to
126
00:06:22,560 --> 00:06:24,960
touch it, right? Like it's a heavy, it's a heavy solution.
127
00:06:24,960 --> 00:06:28,720
It's not at all what I needed. I really wanted something else,
128
00:06:28,720 --> 00:06:32,640
and so I'm never going to go touch it again. But interestingly,
129
00:06:32,640 --> 00:06:34,480
when you think about the problems that GraphQL solves,
130
00:06:34,480 --> 00:06:37,040
which you can also talk about, there really is no other
131
00:06:37,040 --> 00:06:40,160
solution, right? Once you are at a scale where you run to
132
00:06:40,160 --> 00:06:42,000
these problems, where you have many engineers, many
133
00:06:42,000 --> 00:06:45,600
microservices, many clients, what are you going to do? Like
134
00:06:45,600 --> 00:06:48,320
you can build a REST API, right? And you can add an open API
135
00:06:48,320 --> 00:06:50,640
spec to it, but you're going to run into overfetching, you're
136
00:06:50,640 --> 00:06:52,080
going to run into performance problems, you're going to run
137
00:06:52,080 --> 00:06:54,400
into maintenance problems. You can build BFS, but then you
138
00:06:54,400 --> 00:06:56,480
have duplication across the board, you end up having huge
139
00:06:56,480 --> 00:06:58,640
maintenance issues across all these different companies that
140
00:06:58,640 --> 00:07:01,840
have tried it. GraphQL is honestly the only solution that
141
00:07:01,840 --> 00:07:05,360
actually solves the problems. And so that's why at the
142
00:07:05,360 --> 00:07:07,760
enterprise scale, when you're talking to these really large
143
00:07:07,760 --> 00:07:10,080
organizations that have many, many hundreds or thousands of
144
00:07:10,080 --> 00:07:13,360
engineers, GraphQL is finding a ton of adoption because there's
145
00:07:13,360 --> 00:07:15,840
no other option, right? And so over the last three years,
146
00:07:15,840 --> 00:07:18,320
GraphQL has gone from, I don't know, 10% of the Fortune 500 to
147
00:07:18,320 --> 00:07:20,800
like 30%, I think, and they're estimating that it's going to be
148
00:07:20,800 --> 00:07:23,760
70% in another few years because there is no other, like
149
00:07:23,760 --> 00:07:26,160
you literally don't have a choice. Either you have a bad
150
00:07:26,160 --> 00:07:28,720
data access setup or use GraphQL. Those are the two options,
151
00:07:28,720 --> 00:07:30,720
and of course people then end up choosing GraphQL. But the
152
00:07:30,720 --> 00:07:33,280
popular perception hasn't kept up with that reality, right? And
153
00:07:33,280 --> 00:07:35,440
so when you talk to all these indie hackers and startup
154
00:07:35,440 --> 00:07:37,920
people and sort of early stage developers, they look at
155
00:07:37,920 --> 00:07:39,680
GraphQL and they go, oh, that was such a heavy solution.
156
00:07:39,680 --> 00:07:41,840
That's like 10 years old. I don't care about it anymore.
157
00:07:41,840 --> 00:07:44,880
You know, like that's old. I don't need it. And it's true.
158
00:07:44,880 --> 00:07:47,840
They don't need it. But then inferring from that, that other
159
00:07:47,840 --> 00:07:50,800
people don't need it, I think is the mistake that many people
160
00:07:50,800 --> 00:07:52,800
make that's sort of unfortunate because eventually they end up
161
00:07:52,800 --> 00:07:54,880
shooting themselves in the foot by not using it once they are
162
00:07:54,880 --> 00:07:59,600
working at a company that is at that scale. And so I think I'm
163
00:07:59,600 --> 00:08:02,480
hoping that we can sort of shift the discourse a little bit
164
00:08:02,480 --> 00:08:05,520
from GraphQL is a heavy solution for getting types of data
165
00:08:05,520 --> 00:08:09,680
access on the client to pay what actually is GraphQL needed
166
00:08:09,680 --> 00:08:12,240
for, right? Who actually is adopting GraphQL today and why
167
00:08:12,240 --> 00:08:14,720
are they adopting it? Coming with that curiosity is really
168
00:08:14,720 --> 00:08:18,720
what I'm trying to go for. So I hope listeners, if you're
169
00:08:18,720 --> 00:08:20,960
working at a company that's running into sort of scaling
170
00:08:20,960 --> 00:08:24,000
problems, consider GraphQL. It will solve a lot of those for
171
00:08:24,000 --> 00:08:24,500
you.
172
00:08:25,280 --> 00:08:27,920
Yeah. So you alluded to, I couldn't agree more by the way,
173
00:08:27,920 --> 00:08:30,720
but you alluded to this a little bit. What are the types of
174
00:08:30,720 --> 00:08:33,840
problems that people find themselves running into after
175
00:08:33,840 --> 00:08:37,920
they get past the startup phase where they might think this is
176
00:08:37,920 --> 00:08:40,560
too much right now, but then they're like, oh no, we actually
177
00:08:40,560 --> 00:08:41,200
do need this.
178
00:08:42,960 --> 00:08:45,920
Yeah. I think what's interesting about GraphQL before I talk
179
00:08:45,920 --> 00:08:47,440
about the specific problems that we hear about pretty
180
00:08:47,440 --> 00:08:50,800
frequently, what's interesting about GraphQL is that it doesn't
181
00:08:50,800 --> 00:08:54,320
obviously solve all these problems. Many of them just kind
182
00:08:54,320 --> 00:08:57,360
of disappear, right? When once you start using GraphQL,
183
00:08:57,360 --> 00:08:59,920
because it completely changes the way you access data, a lot
184
00:08:59,920 --> 00:09:01,600
of these problems aren't necessarily solved in a very
185
00:09:01,600 --> 00:09:03,600
direct way. They just kind of don't exist anymore. Like
186
00:09:03,600 --> 00:09:05,760
they're no longer problems that you have to deal with because
187
00:09:05,760 --> 00:09:08,640
it just works very differently. And so that solves them, but
188
00:09:08,640 --> 00:09:10,160
it's sort of hard to realize because you have to have been
189
00:09:10,160 --> 00:09:12,240
there before in order to understand that it solved the
190
00:09:12,240 --> 00:09:15,040
problems that just kind of quietly disappeared after you
191
00:09:15,040 --> 00:09:18,240
started using GraphQL. And I think also for context, a lot of
192
00:09:18,240 --> 00:09:20,560
this is informed from having just spoken with hundreds,
193
00:09:20,560 --> 00:09:22,800
maybe thousands of companies at this point about their APIs,
194
00:09:22,800 --> 00:09:24,640
and especially ones using GraphQL, right? That's part of
195
00:09:24,640 --> 00:09:28,400
a big part of my job is talking to all these companies. And so
196
00:09:28,400 --> 00:09:31,760
I've recently been trying to sort of discern what are the
197
00:09:31,760 --> 00:09:34,000
patterns between all these companies that have adopted
198
00:09:34,000 --> 00:09:36,720
GraphQL to solve their problems or make them go away, and what
199
00:09:36,720 --> 00:09:39,360
are those problems? And I've sort of landed on four first
200
00:09:39,360 --> 00:09:42,880
framings that I think are threads that we've heard of
201
00:09:42,880 --> 00:09:45,520
quite frequently. The first one is around mobile apps. Often
202
00:09:45,520 --> 00:09:49,120
companies complain about mobile apps breaking after API changes
203
00:09:49,120 --> 00:09:53,280
because GraphQL only returns the fields that the clients
204
00:09:53,280 --> 00:09:57,120
explicitly request. You can add new capabilities by adding new
205
00:09:57,120 --> 00:10:00,320
fields or types, right? And it does not ever impact existing
206
00:10:00,320 --> 00:10:03,040
clients. Existing clients keep working the exact same way. You
207
00:10:03,040 --> 00:10:05,200
never have to worry about breaking them or making them
208
00:10:05,200 --> 00:10:07,200
really in performing because you keep adding data to adjacent
209
00:10:07,200 --> 00:10:09,200
endpoints and the clients are just waiting on all of it. And
210
00:10:09,200 --> 00:10:11,120
so over time, you end up with a huge performance problem, right?
211
00:10:11,120 --> 00:10:14,480
You don't run into any of those issues. And you can monitor
212
00:10:14,480 --> 00:10:16,400
because the client specifies exactly here are the fields
213
00:10:16,400 --> 00:10:18,560
that I need, you can monitor which fields the client
214
00:10:18,560 --> 00:10:21,120
actually uses. And so is there something that's either unused
215
00:10:21,120 --> 00:10:23,520
or that's still used that's been deprecated? You can go talk
216
00:10:23,520 --> 00:10:26,080
to that client and you can be like, hey, iOS team, you're
217
00:10:26,080 --> 00:10:28,640
still using this field that we deprecated a year and a half
218
00:10:28,640 --> 00:10:31,120
ago that we're trying to replace with this other field.
219
00:10:31,120 --> 00:10:33,120
Can you please migrate over? Or you can even write a code
220
00:10:33,120 --> 00:10:35,440
mode to do the migration for them, right? Like a lot of that
221
00:10:35,440 --> 00:10:38,160
stuff just isn't possible with any other API. And so often
222
00:10:38,160 --> 00:10:40,800
companies talk about, hey, our mobile apps break every now and
223
00:10:40,800 --> 00:10:42,640
then because of API changes and we want to prevent that. We
224
00:10:42,640 --> 00:10:45,840
want to make the changes safer to make. It's a common thread
225
00:10:45,840 --> 00:10:48,320
that we hear with companies wanting to develop GraphQL.
226
00:10:48,320 --> 00:10:52,240
Yeah, that's amazing. I think that insight wasn't always
227
00:10:52,240 --> 00:10:57,200
there either. So the ability to actually see the metrics for
228
00:10:57,200 --> 00:11:00,400
particular fields and see, hey, this actually old client is
229
00:11:00,400 --> 00:11:03,920
trying to grab this wrong field. And I think we have so
230
00:11:03,920 --> 00:11:09,280
much better GraphQL tooling today than we ever did. So have
231
00:11:09,280 --> 00:11:10,080
you seen that as well?
232
00:11:10,080 --> 00:11:12,800
Yeah, for sure. I mean, GraphQL tooling, particularly in the
233
00:11:12,800 --> 00:11:15,200
last few years has evolved dramatically and gotten much,
234
00:11:15,200 --> 00:11:17,920
much better and much, much simpler. It's also interesting
235
00:11:17,920 --> 00:11:22,080
because I think a lot of people sort of miss... If you haven't
236
00:11:22,080 --> 00:11:24,160
experienced these problems before, it's sort of hard to
237
00:11:24,160 --> 00:11:26,400
visualize what they're like, right? And so recently when I
238
00:11:26,400 --> 00:11:28,400
talked about this, somebody responded to me and was like,
239
00:11:28,400 --> 00:11:30,640
well, Max, but I mean, my REST API can also just add a new
240
00:11:30,640 --> 00:11:33,760
field, right? And it's like, yeah, you can, but the client
241
00:11:33,760 --> 00:11:36,400
doesn't specify which fields it actually uses, right? So
242
00:11:36,400 --> 00:11:38,320
then you're just fetching everything and your client has
243
00:11:38,320 --> 00:11:40,640
to download all this data. And so if you multiply that by every
244
00:11:40,640 --> 00:11:42,720
single change that you're making, you end up having
245
00:11:42,720 --> 00:11:47,360
JSON endpoints that return a thousand keys each within this
246
00:11:47,360 --> 00:11:49,680
object within them and you're fetching megabytes of data and
247
00:11:49,680 --> 00:11:51,360
suddenly your mobile app is really slow and everybody
248
00:11:51,360 --> 00:11:54,320
complains about it, right? And so this is one of those things
249
00:11:54,320 --> 00:11:57,440
where GraphQL doesn't directly solve this problem, right?
250
00:11:57,440 --> 00:12:00,240
Nobody would advertise GraphQL as like, hey, your mobile apps
251
00:12:00,240 --> 00:12:04,320
are breaking, go use GraphQL. It's not a very direct solution
252
00:12:04,320 --> 00:12:06,960
to the problem, but because GraphQL works so differently
253
00:12:06,960 --> 00:12:09,520
where the client has to select the fields that it actually
254
00:12:09,520 --> 00:12:12,320
uses, you end up not running into any maintenance issues.
255
00:12:12,320 --> 00:12:16,880
Over time, as you evolve. And so it's a great example of
256
00:12:16,880 --> 00:12:19,280
a problem that just kind of goes away because GraphQL works
257
00:12:19,280 --> 00:12:21,840
very differently, but not necessarily one that it solves
258
00:12:21,840 --> 00:12:24,160
very explicitly, you know, like you're never going to go to
259
00:12:24,160 --> 00:12:26,480
graphql.com and you're going to see, or graphql.org and you're
260
00:12:26,480 --> 00:12:28,880
going to see, you know, your mobile apps are breaking, go use
261
00:12:28,880 --> 00:12:31,920
GraphQL, right? That doesn't make any sense. That connection
262
00:12:31,920 --> 00:12:35,280
isn't there. Another common one that I've just alluded to also
263
00:12:35,280 --> 00:12:37,280
that people talk about is just slow performance, right? Slow
264
00:12:37,280 --> 00:12:40,480
loading times, because with traditional REST APIs, you end
265
00:12:40,480 --> 00:12:43,200
up having request waterfalls or you end up over fetching
266
00:12:43,200 --> 00:12:46,640
significantly, right? You sort of famously Facebook, that's
267
00:12:46,640 --> 00:12:48,400
one of the big reasons why they invented GraphQL in the first
268
00:12:48,400 --> 00:12:51,200
place is because their client, if you loaded the feed page,
269
00:12:51,200 --> 00:12:55,040
had to make 30 nested waterfowl-y requests. And the
270
00:12:55,040 --> 00:12:57,520
problem with making that from the client is that you're
271
00:12:57,520 --> 00:12:59,520
always incurring the additional network latency of going from
272
00:12:59,520 --> 00:13:01,600
the client to the origin, right? And when you're, particularly
273
00:13:01,600 --> 00:13:03,600
in your global company, that can have really large impact if
274
00:13:03,600 --> 00:13:06,080
you have users elsewhere from, pretty far away from your data
275
00:13:06,080 --> 00:13:10,640
centers. People solve this problem. Other companies have
276
00:13:10,640 --> 00:13:12,640
solved this problem with BFFs, like SoundCloud very famously
277
00:13:12,640 --> 00:13:15,200
used the BFF pattern. Finally, now SoundCloud has now actually
278
00:13:15,200 --> 00:13:17,680
switched to GraphQL because it turns out when you do BFFs,
279
00:13:17,680 --> 00:13:19,680
which is backend for frontends where you have sort of a
280
00:13:19,680 --> 00:13:22,080
dedicated service that has, you know, view specific end points
281
00:13:22,080 --> 00:13:24,880
where you have slash get events page and that returns just
282
00:13:24,880 --> 00:13:27,440
exactly the data that the events page needs. That solves
283
00:13:27,440 --> 00:13:29,920
the request waterfalls and the over fetching because you're
284
00:13:29,920 --> 00:13:33,200
only returning the data that that client actually needs. But
285
00:13:33,200 --> 00:13:35,440
you're introducing immense duplication because you need one
286
00:13:35,440 --> 00:13:38,000
of those end points for each page on each client. And so
287
00:13:38,000 --> 00:13:40,320
you just end up having the companies that use this pattern
288
00:13:40,320 --> 00:13:42,880
end up having hundreds, if not thousands of end points and it
289
00:13:42,880 --> 00:13:44,800
becomes a maintenance issue because if you just try to make
290
00:13:44,800 --> 00:13:47,600
a change, we try to enforce a new performance SLA or new
291
00:13:47,600 --> 00:13:51,520
security thing, it ends up being a nightmare for any
292
00:13:51,520 --> 00:13:55,520
changes that you make. And so performance is often one that
293
00:13:55,520 --> 00:13:58,000
people now solve with GraphQL because again, you don't really
294
00:13:58,000 --> 00:14:00,240
have a different solution. Like you can go with BFFs, but then
295
00:14:00,240 --> 00:14:02,000
you're just introducing other problems that you didn't have
296
00:14:02,000 --> 00:14:05,040
before. So that's another common problem that we hear about.
297
00:14:05,040 --> 00:14:09,120
Totally. Yeah, I think that speaks to the communication help
298
00:14:09,120 --> 00:14:12,880
that GraphQL gives you to among the team, the schema, the
299
00:14:12,880 --> 00:14:19,040
insights to like what is actually in this API is such a
300
00:14:19,040 --> 00:14:22,400
tricky thing. I feel like with REST APIs, no matter how great
301
00:14:22,400 --> 00:14:26,080
your REST documentation is, it feels like GraphQL is a little
302
00:14:26,080 --> 00:14:30,720
you have better visibility into what those actual fields
303
00:14:30,720 --> 00:14:33,520
actually are. So I feel like that helps a lot too.
304
00:14:33,520 --> 00:14:35,920
Totally. And in fact, that's another one of the common
305
00:14:35,920 --> 00:14:38,560
problems that we hear about is sort of like, I don't know
306
00:14:38,560 --> 00:14:40,880
which endpoints even exist and where to get the data that I
307
00:14:40,880 --> 00:14:43,760
need from my REST API because I have hundreds of REST endpoints
308
00:14:43,760 --> 00:14:46,160
and I don't have visibility into what gets returned from
309
00:14:46,160 --> 00:14:48,560
where. And again, this is one of those problems that just kind
310
00:14:48,560 --> 00:14:51,280
of goes away with GraphQL because with GraphQL, you have
311
00:14:51,280 --> 00:14:53,840
to have a schema. And I think people in the rest of the world
312
00:14:53,840 --> 00:14:56,400
don't understand in order for you to return any piece of
313
00:14:56,400 --> 00:14:58,800
data, it has to be in the schema. You cannot return data
314
00:14:58,800 --> 00:15:02,560
that isn't in the schema. And so then inherently, discovery is
315
00:15:02,560 --> 00:15:04,800
not an issue anymore because all of the data has to be in the
316
00:15:04,800 --> 00:15:08,160
central schema. You can find it in GraphiQL. But it doesn't
317
00:15:08,160 --> 00:15:10,480
again, you wouldn't go to GraphQL.org and expect that to be
318
00:15:10,480 --> 00:15:13,360
a tagline that's like, oh, you can't find your REST endpoints,
319
00:15:13,360 --> 00:15:15,680
go use GraphQL. Again, that doesn't make any... The problem
320
00:15:15,680 --> 00:15:17,600
just kind of goes away inherently because of how
321
00:15:17,600 --> 00:15:20,160
GraphQL works. It just has that central schema. It has that
322
00:15:20,160 --> 00:15:22,400
central definition of what data exists and how to access it.
323
00:15:22,400 --> 00:15:25,920
And that solves that entire class of problems just kind of
324
00:15:25,920 --> 00:15:28,000
goes away, right? You never have to worry about discovery,
325
00:15:28,960 --> 00:15:31,680
which is sort of a bit of a misnomer too, because at some
326
00:15:31,680 --> 00:15:33,760
scale, if you have hundreds of thousands of types in your
327
00:15:33,760 --> 00:15:36,160
schema, then yes, you will also have a hard time finding what
328
00:15:36,160 --> 00:15:37,680
you're looking for. But then you just have a large data
329
00:15:37,680 --> 00:15:40,720
model and it's just inherent to your data model. But
330
00:15:40,720 --> 00:15:42,560
fundamentally, GraphQL solves that problem for a lot of
331
00:15:42,560 --> 00:15:45,920
companies because it just enforces the usage of a central
332
00:15:45,920 --> 00:15:48,880
schema, right? And so you don't have to worry about the
333
00:15:48,880 --> 00:15:50,960
discovery or the maintenance of it, right? The other part too
334
00:15:50,960 --> 00:15:57,040
is because GraphQL has this field selection thing, any update
335
00:15:57,040 --> 00:15:59,360
that you make to any type, like say you change the way that
336
00:15:59,360 --> 00:16:03,280
you store users, you only have to update one database query
337
00:16:03,280 --> 00:16:06,080
in your user object type and nothing else has to worry about
338
00:16:06,080 --> 00:16:08,800
this underlying change, right? Everything else stays the same
339
00:16:08,800 --> 00:16:11,920
because GraphQL is another layer that abstracts between your
340
00:16:11,920 --> 00:16:14,400
database and your clients, where often if you have REST
341
00:16:14,400 --> 00:16:16,400
APIs and this will just pass through what the database
342
00:16:16,400 --> 00:16:19,120
returns, suddenly you end up having maintenance issues up
343
00:16:19,120 --> 00:16:20,880
and down a stack. Whenever you make a change, you suddenly
344
00:16:20,880 --> 00:16:22,880
have to propagate that change all the way through front to
345
00:16:22,880 --> 00:16:27,440
back. And that's being really, really painful. Yeah. And then
346
00:16:27,440 --> 00:16:29,440
just to close off the loop here, the fourth issue that we
347
00:16:29,440 --> 00:16:31,760
hear or the fourth problem that we hear a lot about that goes
348
00:16:31,760 --> 00:16:35,120
away with GraphQL is security and performance often and
349
00:16:35,120 --> 00:16:40,560
specifically keeping on top of them because GraphQL is a
350
00:16:40,560 --> 00:16:43,840
central data access layer, you can enforce security and
351
00:16:43,840 --> 00:16:46,240
performance at a very fine grained level and sort of
352
00:16:46,240 --> 00:16:48,240
distribute responsibility between the teams that are
353
00:16:48,240 --> 00:16:52,160
actually responsible for it. And one of the things actually
354
00:16:52,160 --> 00:16:56,160
that I'm... This is a story that sits with me really very
355
00:16:56,160 --> 00:16:59,840
strongly, which is we were using GraphQL at Spectrum and we
356
00:16:59,840 --> 00:17:02,000
were three co-founders essentially for a year and a
357
00:17:02,000 --> 00:17:03,840
half sitting in our bedrooms hacking away a product and
358
00:17:03,840 --> 00:17:06,160
just trying to ship as fast as possible, trying to figure out
359
00:17:06,160 --> 00:17:07,840
what do people need and then once we found what people
360
00:17:07,840 --> 00:17:10,160
needed, making it better and sort of shipping all the
361
00:17:10,160 --> 00:17:14,400
improvements that people wanted. And in that world, we
362
00:17:14,400 --> 00:17:16,720
didn't pay particularly much attention to security. Now, I
363
00:17:16,720 --> 00:17:18,480
don't want to say that we weren't mindful of security
364
00:17:18,480 --> 00:17:21,200
broadly, but it's not like we're a three-person startup.
365
00:17:21,200 --> 00:17:23,120
We didn't have a security team. We didn't have a security
366
00:17:23,120 --> 00:17:25,920
posture. We didn't have SOC 2. None of those
367
00:17:25,920 --> 00:17:28,320
things really had crossed our mind yet. Now, when GitHub
368
00:17:28,320 --> 00:17:30,800
acquired us, because they acquired the IP and the
369
00:17:30,800 --> 00:17:34,320
company, they essentially take on... Whenever a company
370
00:17:34,320 --> 00:17:36,800
gets acquired, you take on the liability of that company,
371
00:17:36,800 --> 00:17:39,040
right? So say GitHub acquired Spectrum and then Spectrum had
372
00:17:39,040 --> 00:17:41,520
a major security issue, GitHub would be on the hook for that
373
00:17:41,520 --> 00:17:43,360
security issue. And so whenever companies acquire other
374
00:17:43,360 --> 00:17:47,840
companies, they do security checks and GitHub pays eight
375
00:17:48,400 --> 00:17:50,560
pen testers in one of the world's best pen testing
376
00:17:50,560 --> 00:17:53,920
agencies to try and hack Spectrum for an entire week. And
377
00:17:53,920 --> 00:17:57,520
I was scared shitless that whole week because, again, we had
378
00:17:57,520 --> 00:18:00,800
spent zero time explicitly thinking about security, right?
379
00:18:00,800 --> 00:18:02,640
And we knew that this could make or break the deal. If
380
00:18:02,640 --> 00:18:04,560
there was a major security hole that we couldn't close very
381
00:18:04,560 --> 00:18:07,440
quickly, then GitHub wouldn't buy us because they wouldn't
382
00:18:07,440 --> 00:18:10,480
want to take on that liability. And I'm extremely proud to
383
00:18:10,480 --> 00:18:12,960
say that they came back and they had not found a single
384
00:18:12,960 --> 00:18:14,960
major security vulnerability. In fact, they'd only found one
385
00:18:14,960 --> 00:18:17,200
medium one that was sort of a bit of bullshit, but whatever.
386
00:18:18,240 --> 00:18:21,840
And I largely actually credit GraphQL for that because we
387
00:18:21,840 --> 00:18:24,720
were using GraphQL as our central data access layer. The
388
00:18:24,720 --> 00:18:26,640
only thing we had done from a security perspective, outside
389
00:18:26,640 --> 00:18:28,240
of, of course, two factor authentication and all that
390
00:18:28,240 --> 00:18:31,600
general stuff, was we just had one access control check in
391
00:18:31,600 --> 00:18:35,200
every resolver. Right. And so when you tried to create a
392
00:18:35,200 --> 00:18:37,200
channel, for example, we had an access control check that
393
00:18:37,200 --> 00:18:39,760
just made sure that you were an admin or a moderator of the
394
00:18:39,760 --> 00:18:42,720
overlying community. When you tried to create the thread, we
395
00:18:42,720 --> 00:18:44,160
tried to make sure that you're a member in the community and
396
00:18:44,160 --> 00:18:46,560
you had permission to do so. So every resolver had an access
397
00:18:46,560 --> 00:18:48,640
control check. And even though not all of those access
398
00:18:48,640 --> 00:18:51,280
control checks were perfect, like there was some things where
399
00:18:51,280 --> 00:18:53,840
like you could change the description of a community when
400
00:18:53,840 --> 00:18:56,160
you were the moderator of a sub channel, even if you weren't
401
00:18:56,160 --> 00:18:58,080
a moderator of the community. Not all of them were a hundred
402
00:18:58,080 --> 00:19:00,560
percent perfect, but they were good enough to where there were
403
00:19:00,560 --> 00:19:02,720
no major security issues in any of those access control
404
00:19:02,720 --> 00:19:04,880
checks. And so then broadly, because that was the only
405
00:19:04,880 --> 00:19:06,880
plane where you could actually access the data that we had,
406
00:19:07,600 --> 00:19:09,280
we didn't have any major security issues, right? Because
407
00:19:10,080 --> 00:19:12,640
nothing else really mattered. And so that really showed to me
408
00:19:12,640 --> 00:19:15,120
the power of having the central layer. Yes, it's an additional
409
00:19:15,120 --> 00:19:18,320
abstraction that can be heavy for simple use cases, but it
410
00:19:18,320 --> 00:19:20,640
also just removes all these problems entirely. You never have
411
00:19:20,640 --> 00:19:23,520
to think about security where with REST APIs, I've seen some
412
00:19:23,520 --> 00:19:26,080
REST APIs where people just do random database queries in
413
00:19:26,080 --> 00:19:28,480
random end points and then return some data. And there is
414
00:19:28,480 --> 00:19:30,800
very little guarantee that any of it is secure or has the
415
00:19:30,800 --> 00:19:32,960
right access control checks. And so that's another one of the
416
00:19:32,960 --> 00:19:35,280
big problems that just kind of disappears when you're using
417
00:19:35,280 --> 00:19:38,400
GraphQL. Not because, you know, again, there won't ever be a
418
00:19:38,400 --> 00:19:40,720
tagline on graphql.org that's like, you have security issues,
419
00:19:40,720 --> 00:19:43,040
go use GraphQL. That doesn't make any sense, right? But
420
00:19:44,240 --> 00:19:46,800
when you use GraphQL, because of the way it works, those,
421
00:19:46,800 --> 00:19:49,520
that class of security issues just disappears. Like you just
422
00:19:49,520 --> 00:19:51,440
never really have to worry about it. It's just not a thing
423
00:19:51,440 --> 00:19:53,680
anymore. And so that's another one of the big problems that we
424
00:19:53,680 --> 00:19:56,400
hear about. So just to summarize so that people can sort of keep
425
00:19:56,400 --> 00:19:58,240
track of the four problems that we hear about the most when
426
00:19:58,240 --> 00:20:00,640
people talk about adopting GraphQL or mobile apps breaking
427
00:20:00,640 --> 00:20:03,760
after API changes. It's really slow loading times because of
428
00:20:03,760 --> 00:20:06,560
request for all the files and or overfetching. And so there's
429
00:20:06,560 --> 00:20:09,280
difficult maintenance and discovery because you have these
430
00:20:09,280 --> 00:20:10,960
many, many, many REST end points and you don't know what
431
00:20:10,960 --> 00:20:13,360
data is where. And then security and performance being this
432
00:20:13,360 --> 00:20:16,480
game of whack-a-mole to enforce as you're sort of growing and
433
00:20:16,480 --> 00:20:18,160
trying to keep everything secure and performant.
434
00:20:18,160 --> 00:20:22,960
Yeah. I love that breakdown. And I also love that story, even
435
00:20:22,960 --> 00:20:26,160
though I'm sure that was the most stressful week ever to have
436
00:20:26,160 --> 00:20:29,440
that going on, but I love the outcome of that. Cause yeah, I
437
00:20:29,440 --> 00:20:34,240
feel like a misconception I hear so often about GraphQL is, oh,
438
00:20:34,240 --> 00:20:37,360
we're just going to open up all of our data to a query. That's
439
00:20:37,360 --> 00:20:41,440
going to take down our whole API. It's going to, what if we
440
00:20:41,440 --> 00:20:46,640
have these malicious actors? But I do feel like having one extra
441
00:20:46,640 --> 00:20:50,640
layer in there that manages security actually has the
442
00:20:50,640 --> 00:20:57,920
opposite effect where it really helps to secure the data source
443
00:20:57,920 --> 00:21:02,000
much, much better. So when you think about security at Steli,
444
00:21:02,000 --> 00:21:05,520
what are some of the things that you have in mind? I know that
445
00:21:05,520 --> 00:21:12,640
you have the SOC 2 and all of those. It's a very compelling
446
00:21:12,640 --> 00:21:19,200
reason to use GraphQL. Yeah. So the way we think about all the
447
00:21:19,200 --> 00:21:21,920
products that we build at Steli is that we've built a team
448
00:21:21,920 --> 00:21:24,560
of GraphQL experts, right? We've maintained some of the most
449
00:21:24,560 --> 00:21:27,280
popular GraphQL clients of GraphQL. We have the person that
450
00:21:27,280 --> 00:21:29,440
architected the Contentful GraphQL API. We have all these
451
00:21:29,440 --> 00:21:31,920
people that love GraphQL, obviously, because who goes to
452
00:21:31,920 --> 00:21:34,240
work at a GraphQL company? Somebody that loves GraphQL,
453
00:21:34,240 --> 00:21:36,880
right? Like inherently we were bound to attract those people.
454
00:21:36,880 --> 00:21:40,640
And so we try to build products that take advantage of our
455
00:21:40,640 --> 00:21:44,000
expertise and experience with GraphQL to provide value that
456
00:21:44,000 --> 00:21:46,560
otherwise wouldn't be possible, right? And that applies through
457
00:21:46,560 --> 00:21:50,000
our whole product suite. So for example, our API caching that
458
00:21:50,000 --> 00:21:52,480
we do for GraphQL, you could look at it and you could go,
459
00:21:52,480 --> 00:21:54,480
cool, it's GraphQL edge caching. Makes sense, right? Like you
460
00:21:54,480 --> 00:21:56,640
can cache an API at the edge. But truthfully, because GraphQL
461
00:21:56,640 --> 00:22:00,800
is field selection, we can actually build better API caching
462
00:22:00,800 --> 00:22:03,440
based on GraphQL than you could for any other API, because we
463
00:22:03,440 --> 00:22:05,840
can do something called partial query caching, where even if
464
00:22:05,840 --> 00:22:08,480
only a part of the query is cacheable, we can extract that
465
00:22:08,480 --> 00:22:11,680
part if we have the data in the cache and only send the rest of
466
00:22:11,680 --> 00:22:13,760
the queries to the origin to fetch the data that we need,
467
00:22:13,760 --> 00:22:15,760
right? And so you can significantly reduce load on
468
00:22:15,760 --> 00:22:18,640
the origin infrastructure by caching a lot more data than
469
00:22:18,640 --> 00:22:21,840
you could with any other API cache, right? And so yes, it's
470
00:22:21,840 --> 00:22:24,880
a GraphQL edge cache. It only works for GraphQL. And because
471
00:22:24,880 --> 00:22:27,600
of how GraphQL works, it's actually more powerful than any
472
00:22:27,600 --> 00:22:30,640
other API cache on the planet, right? Enabled by GraphQL. And
473
00:22:30,640 --> 00:22:33,920
the same thing is true for our security products. We've built
474
00:22:33,920 --> 00:22:37,840
sort of three main things on the security front. One is very
475
00:22:37,840 --> 00:22:40,320
general security filters, because there are, because
476
00:22:40,320 --> 00:22:43,360
GraphQL is very flexible on purpose. There are some ways
477
00:22:43,360 --> 00:22:45,520
that malicious actors can abuse that flexibility to try and
478
00:22:45,520 --> 00:22:48,160
de-dosier systems. They can make really deeply nested queries.
479
00:22:48,160 --> 00:22:50,240
They can use lots of aliases to fetch a lot of repetitive
480
00:22:50,240 --> 00:22:53,760
data. They can try and figure out what your scheme is like
481
00:22:53,760 --> 00:22:56,640
through error handling and sort of like the suggestions that
482
00:22:56,640 --> 00:22:59,280
come back. And so we've shipped some basic security filters to
483
00:22:59,280 --> 00:23:03,360
protect against these common GraphQL vulnerabilities that
484
00:23:03,360 --> 00:23:06,640
people try to abuse. Then we ship the rate limiting. So we
485
00:23:06,640 --> 00:23:08,880
now do sort of rate limiting that understands GraphQL. And
486
00:23:08,880 --> 00:23:10,880
so we can, on a per type or field level, you can be like,
487
00:23:10,880 --> 00:23:13,520
hey, I don't want the add to cart mutation to be called more
488
00:23:13,520 --> 00:23:16,240
than three times in 10 seconds, because otherwise I'm pretty
489
00:23:16,240 --> 00:23:18,240
sure that's a bot that's hammering the button and trying
490
00:23:18,240 --> 00:23:21,520
to buy the shoe that we dropped, right? And then also we
491
00:23:21,520 --> 00:23:24,080
ship persistent operations, which is a way of sort of allow
492
00:23:24,080 --> 00:23:27,520
listing only the queries and mutations that your client
493
00:23:27,520 --> 00:23:30,080
actually sends itself. And so no malicious actor can send
494
00:23:30,080 --> 00:23:32,720
any others. But again, all of these solutions, they're very
495
00:23:32,720 --> 00:23:34,480
GraphQL specific, right? You couldn't take them and apply
496
00:23:34,480 --> 00:23:36,400
them to anything else because that doesn't make any sense,
497
00:23:36,400 --> 00:23:38,880
right? Persistent operations, security filters, those things
498
00:23:38,880 --> 00:23:41,040
only make sense in the context of GraphQL and to take
499
00:23:41,040 --> 00:23:44,240
advantage of GraphQL's unique nature to provide value. And so
500
00:23:44,240 --> 00:23:46,400
that's generally how we think about building products is
501
00:23:46,400 --> 00:23:50,320
where, as a CDN that sits in front of GraphQL APIs, where
502
00:23:50,320 --> 00:23:52,720
can we take the experience and the expertise that we have
503
00:23:52,720 --> 00:23:55,600
with GraphQL and apply it to provide value to companies in
504
00:23:55,600 --> 00:23:58,320
ways that otherwise might or might not be possible for other
505
00:23:58,320 --> 00:24:02,720
APIs. Yeah, that's so cool. And so important too, I feel
506
00:24:02,720 --> 00:24:07,840
like there's so many misconceptions that you're just
507
00:24:08,720 --> 00:24:12,560
getting rid of. So this is really awesome. I was able to
508
00:24:12,560 --> 00:24:16,400
meet a few of your team members at GraphQL Summit, and they
509
00:24:17,120 --> 00:24:20,560
all had something in common, which they all seem very happy
510
00:24:20,560 --> 00:24:23,840
with their job. They seemed really stoked to be there. And
511
00:24:23,840 --> 00:24:27,440
that was really cool. I think it's a really big deal. So what
512
00:24:27,440 --> 00:24:31,440
do you think makes Stellate a great place to work? And aside
513
00:24:31,440 --> 00:24:35,200
from just being a GraphQL expert or someone interested in
514
00:24:35,200 --> 00:24:39,200
GraphQL, what do you look for when you hire folks? This is
515
00:24:39,200 --> 00:24:41,440
like a whole other podcast. Also, I don't know what I'm the
516
00:24:41,440 --> 00:24:44,080
right person to ask because I'm the opposite of the spectrum,
517
00:24:44,080 --> 00:24:47,600
but I will say how I think about building an organization
518
00:24:47,600 --> 00:24:51,360
on a team, which I think will give you some color on that.
519
00:24:51,360 --> 00:24:54,720
I think broadly speaking, Tim and I started Stellate with
520
00:24:54,720 --> 00:24:58,080
this belief that in order to be successful, we need to hire
521
00:24:58,080 --> 00:25:00,800
the best people and then put them in an environment where
522
00:25:00,800 --> 00:25:04,880
they can do their best work. And through that, we will find
523
00:25:04,880 --> 00:25:08,560
success much more likely than if we didn't do that. And so
524
00:25:08,560 --> 00:25:12,480
from the get-go, we knew we needed to invest in our people.
525
00:25:12,480 --> 00:25:14,320
We knew we needed to invest in our team building. We knew we
526
00:25:14,320 --> 00:25:16,960
needed to invest into connections between people. And
527
00:25:16,960 --> 00:25:22,480
so that culture permeates through our entire organization.
528
00:25:22,480 --> 00:25:25,680
We have four core values, and one of them is win as one team.
529
00:25:25,680 --> 00:25:29,680
And we really try to work together to win as a company,
530
00:25:29,680 --> 00:25:33,440
whatever that means. And we do all kinds of little and big
531
00:25:33,440 --> 00:25:35,600
things like we have bi-weekly connection meetings where we
532
00:25:35,600 --> 00:25:38,480
just hang out and play games. We go to off-sites at least
533
00:25:38,480 --> 00:25:40,560
three times a year. We fly at the whole team out to
534
00:25:40,560 --> 00:25:42,560
conferences every now and then, like Graphical Summit, to go
535
00:25:42,560 --> 00:25:46,000
and hang out and meet the ecosystem. We encourage people
536
00:25:46,000 --> 00:25:48,480
to with a park where people can fly to visit a co-worker a
537
00:25:48,480 --> 00:25:51,600
few times a year. There's lots of big and small things, but
538
00:25:51,600 --> 00:25:54,000
they all fundamentally, I can tell you all the little small
539
00:25:54,000 --> 00:25:55,760
things, but they all fundamentally flow from this
540
00:25:55,760 --> 00:25:58,000
belief that we want to hire the best people and then we want
541
00:25:58,000 --> 00:26:00,400
to put them in a really, really good environment. And so to
542
00:26:00,400 --> 00:26:02,800
us, that environment is one of trust and one of connection.
543
00:26:02,800 --> 00:26:05,440
And so that's a lot of what we're optimizing for and what
544
00:26:05,440 --> 00:26:08,800
we do. And actually, huge credit to Sue Odeo, who joined
545
00:26:08,800 --> 00:26:11,040
us very early on as our head of people and operations and
546
00:26:11,040 --> 00:26:14,560
later our CEO, who drove a lot of these initiatives. Again,
547
00:26:14,560 --> 00:26:16,960
we knew we wanted to do this, but Tim and I had never built
548
00:26:16,960 --> 00:26:19,040
an organization before. And so we knew we needed to hire
549
00:26:19,040 --> 00:26:21,200
somebody to manage all of that. And so Sue was instrumental
550
00:26:21,200 --> 00:26:23,760
in building up that culture and that organization and
551
00:26:23,760 --> 00:26:26,240
building a team to where we have, even as an early stage
552
00:26:26,240 --> 00:26:28,720
startup that's only three years old and is still iterating
553
00:26:28,720 --> 00:26:32,160
and learning quickly and changing every month, we've had
554
00:26:32,160 --> 00:26:35,840
very little voluntary attrition, meaning very few people
555
00:26:35,840 --> 00:26:38,880
that ever lived that joined. And generally, people report
556
00:26:38,880 --> 00:26:43,200
being very happy on their service. So things can always
557
00:26:43,200 --> 00:26:46,080
change, but fundamentally, it all flows from this belief
558
00:26:46,080 --> 00:26:49,360
that we're all adults. We're not a family, but we're more
559
00:26:49,360 --> 00:26:52,000
like a sports team and we want to treat people with respect
560
00:26:52,000 --> 00:26:54,080
that they deserve. Everybody's an adult. Everybody does great
561
00:26:54,080 --> 00:26:56,960
work. Let's go work together and figure it out. And a big
562
00:26:56,960 --> 00:26:59,120
part of that is being connected and understanding each other
563
00:26:59,120 --> 00:27:01,360
and sort of working within the diversity that we have in the
564
00:27:01,360 --> 00:27:06,320
team. So lots of little things that all flow from one big
565
00:27:06,320 --> 00:27:11,040
belief is the answer. Yeah, that's amazing. And I think that
566
00:27:11,040 --> 00:27:15,120
really, that really showed through to me. And I also saw
567
00:27:15,120 --> 00:27:18,800
that handbook on your website and how detailed that is for
568
00:27:18,800 --> 00:27:21,920
just folks joining the team and things. And I think that's
569
00:27:21,920 --> 00:27:26,560
so useful to, I don't know, just articulate that. And I'm
570
00:27:26,560 --> 00:27:32,000
sure that flows down to everybody on your team. So I
571
00:27:32,000 --> 00:27:36,240
love it. Sorry to go off of GraphQL topics, but that was
572
00:27:36,240 --> 00:27:38,720
important because you used to have a really cool company. So
573
00:27:39,360 --> 00:27:43,120
yeah, I think the interesting learnings that I've had as a
574
00:27:43,120 --> 00:27:47,280
founder and it's building my own team is that inherently the
575
00:27:47,280 --> 00:27:53,200
team that you build is sort of a mirror image of yourself, but
576
00:27:53,200 --> 00:27:57,360
a mirror image in a very direct way that I think can be ugly
577
00:27:57,360 --> 00:28:00,240
and can be pretty depending on which parts of your mirror
578
00:28:00,240 --> 00:28:03,280
image match what your organization needs and what it
579
00:28:03,280 --> 00:28:06,960
doesn't. And so even now I have a lot of respect for people
580
00:28:06,960 --> 00:28:12,480
that are a bit maybe controversial in some industries,
581
00:28:12,480 --> 00:28:14,480
right? Like Travis Kalanick who founded Uber, right? Uber
582
00:28:14,480 --> 00:28:17,760
very famously had a very bro-y culture, very aggressive. After
583
00:28:17,760 --> 00:28:19,840
Derek came in and took over as CEO, he had to do a lot of
584
00:28:19,840 --> 00:28:23,200
cultural cleanup. But truthfully, Travis knew that he
585
00:28:23,200 --> 00:28:26,080
was a bro. Travis knew that he was a bit of an asshole and an
586
00:28:26,080 --> 00:28:28,800
aggressive asshole at that. And he found the market where the
587
00:28:28,800 --> 00:28:31,600
only way to win was to play, build a company in a culture
588
00:28:31,600 --> 00:28:33,600
like that. And he ended up winning because they had a
589
00:28:33,600 --> 00:28:35,600
culture like that at the beginning. And eventually that
590
00:28:35,600 --> 00:28:37,600
doesn't work anymore. But for the early stages, that was
591
00:28:37,600 --> 00:28:40,080
exactly what Uber needed in order to win. They needed to
592
00:28:40,080 --> 00:28:43,280
ignore regulators. They needed to ignore laws. They needed to
593
00:28:43,280 --> 00:28:45,760
cause trouble because that was the only way they were ever
594
00:28:45,760 --> 00:28:48,480
going to win in that market. And so you can look at that and
595
00:28:48,480 --> 00:28:50,640
you can go, oh, Travis Kalanick is an asshole, you know, like
596
00:28:51,840 --> 00:28:54,480
Uber sucks. And yeah, that environment definitely wasn't
597
00:28:54,480 --> 00:28:57,920
for everybody. But I'm having never met the guy. I'm 100%
598
00:28:57,920 --> 00:29:00,880
certain that Travis knew exactly who he was. And he was
599
00:29:00,880 --> 00:29:03,520
like, I found the market where that is awesome and it's going
600
00:29:03,520 --> 00:29:06,320
to help us win. I'm going to go into that market. And that
601
00:29:06,320 --> 00:29:09,760
requires an immense level of self-acceptance and
602
00:29:09,760 --> 00:29:12,800
self-understanding that many people don't have. And one of
603
00:29:12,800 --> 00:29:14,720
the interesting parts of being a founder is you found this
604
00:29:14,720 --> 00:29:17,600
organization. And then two years in, I looked at around one of
605
00:29:17,600 --> 00:29:20,080
our offices and I was like, holy, I see myself in this
606
00:29:20,080 --> 00:29:22,560
organization everywhere. All the good things, which is awesome,
607
00:29:22,560 --> 00:29:24,480
but also all the bad things, which is less awesome, right?
608
00:29:24,480 --> 00:29:27,200
Because nobody's perfect and not every way that you are as a
609
00:29:27,200 --> 00:29:30,400
human being matches what the organization needs in order to
610
00:29:30,400 --> 00:29:33,600
be successful. And so a lot of the journey of being a founder
611
00:29:33,600 --> 00:29:36,240
for me has also been just working on myself, being better
612
00:29:36,240 --> 00:29:39,600
understanding who even am I, why am I acting this way and why
613
00:29:39,600 --> 00:29:41,840
is the organization acting this way? And then how can I change
614
00:29:41,840 --> 00:29:44,320
myself, which is always difficult? And so that's just been a
615
00:29:44,320 --> 00:29:48,000
very interesting journey that I reflect on sometimes in case
616
00:29:48,000 --> 00:29:50,480
anybody out there is thinking about building a company. The
617
00:29:50,480 --> 00:29:52,880
main thing you're going to be doing if you're successful is
618
00:29:52,880 --> 00:29:54,880
working on yourself more so than anything else.
619
00:29:55,680 --> 00:29:59,840
Yeah, that's so well put. Working on yourself then
620
00:29:59,840 --> 00:30:03,120
translates to affecting everyone else. I feel like that's
621
00:30:03,120 --> 00:30:06,800
really true. And part of what I saw in that handbook was
622
00:30:06,800 --> 00:30:10,640
coaching too. That's a big part of the benefits that you give
623
00:30:10,640 --> 00:30:13,600
folks, but also I'm sure benefits the organization as a
624
00:30:13,600 --> 00:30:17,200
whole too. So yeah, how does that fit into what you're doing?
625
00:30:18,080 --> 00:30:20,720
Yeah, I mean, again, right, like we're all really good at
626
00:30:20,720 --> 00:30:22,880
what we do and we all want to be better at what we do is sort
627
00:30:22,880 --> 00:30:27,920
of the core tenet of our values. And so we provide a coach of
628
00:30:27,920 --> 00:30:30,080
people's choice to every single employee and they can work with
629
00:30:30,080 --> 00:30:32,560
that coach to get better at whatever it is that they're
630
00:30:32,560 --> 00:30:34,480
working on, right? That might be something very work related,
631
00:30:34,480 --> 00:30:36,640
like, oh, I have this project that's moving forward, how can
632
00:30:36,640 --> 00:30:38,960
I move it forward? But it can also be much more personal, much
633
00:30:38,960 --> 00:30:43,200
more like, hey, I grew up in a way where now I'm struggling
634
00:30:43,200 --> 00:30:45,200
with giving constructive feedback. How can I iterate on
635
00:30:45,200 --> 00:30:47,120
myself to get better at giving constructive feedback, get more
636
00:30:47,120 --> 00:30:50,880
comfortable with it, right? And that's helped the organization
637
00:30:50,880 --> 00:30:52,960
as a whole level up significantly. And also for me
638
00:30:52,960 --> 00:30:55,600
personally has been a big impact, but also everybody that
639
00:30:55,600 --> 00:30:58,560
takes advantage of that perk really benefits, reports
640
00:30:58,560 --> 00:31:01,200
benefiting from it and says, hey, look, you know, and again,
641
00:31:01,200 --> 00:31:03,200
this goes back to we just treat people like humans, like, hey,
642
00:31:03,200 --> 00:31:05,520
you're here to do the job. We want you to do a job better
643
00:31:05,520 --> 00:31:08,560
every day than you did the day before. We'll pay for a coach
644
00:31:08,560 --> 00:31:10,320
so that you can do that, right? And that you can get better
645
00:31:10,320 --> 00:31:12,240
at what you do and you can be even more effective at
646
00:31:12,240 --> 00:31:14,880
studying. And yeah, some of it's sort of altruistic, right?
647
00:31:14,880 --> 00:31:16,400
Some of it's like, yeah, we want you to be a better human.
648
00:31:16,400 --> 00:31:19,200
And some of totally all of it is like, this is how we believe
649
00:31:19,200 --> 00:31:21,680
we will win as an organization, right? We believe we will win
650
00:31:21,680 --> 00:31:23,680
because we have great people and because they keep getting
651
00:31:23,680 --> 00:31:25,680
better over time. And this is the best one of the ways that
652
00:31:25,680 --> 00:31:28,880
we think about accelerating that getting better over time.
653
00:31:28,880 --> 00:31:32,320
Totally. I think that's so cool. And I think confidence is a
654
00:31:32,320 --> 00:31:35,360
thing that everyone needs to make a successful company
655
00:31:35,360 --> 00:31:38,720
happen, but also the vulnerability to say, hey, there's
656
00:31:38,720 --> 00:31:43,120
room for improvement in these areas. And yeah, I think that
657
00:31:43,120 --> 00:31:47,040
is not always the case when companies are starting out or
658
00:31:47,680 --> 00:31:51,520
three years in like you. So it's really cool. So the last
659
00:31:51,520 --> 00:31:54,000
thing I wanted to ask you about today was you have this
660
00:31:54,960 --> 00:31:59,200
murderers row of companies that you've invested in, Fly.io,
661
00:31:59,200 --> 00:32:05,840
Clerc, Zed, Liveblocks, many, many, many others. So when you're investing
662
00:32:05,840 --> 00:32:10,400
in companies, and I'm sure this is colored by your experience
663
00:32:10,400 --> 00:32:16,080
as a founder, multi, multi hyphenate before, but how do you
664
00:32:16,880 --> 00:32:19,680
how do you I'm going to try that question again. What do you
665
00:32:19,680 --> 00:32:22,000
look for in a company as an investor?
666
00:32:22,000 --> 00:32:29,920
So I started doing investment really out of a longing to learn
667
00:32:29,920 --> 00:32:33,840
because I realized that every startup journey, every startup's
668
00:32:33,840 --> 00:32:37,440
journey is very unique, but also every startup's journey has
669
00:32:37,440 --> 00:32:40,240
very many ups and downs, every single one. Even if you're
670
00:32:40,240 --> 00:32:42,400
looking at the very successful companies that are just rocket
671
00:32:42,400 --> 00:32:45,200
ships going through the air, that graph that goes up and to
672
00:32:45,200 --> 00:32:47,360
the right is actually there's lots of ups and downs every
673
00:32:47,360 --> 00:32:49,440
single day that just happened to get bigger and bigger over
674
00:32:49,440 --> 00:32:54,400
time. And so investing was a way for me to stay grounded a
675
00:32:54,400 --> 00:32:56,960
little bit because often when you're founding your own
676
00:32:56,960 --> 00:32:59,680
startup, you're so heads down working on your own thing that
677
00:32:59,680 --> 00:33:01,680
every single up and every single down affects you very
678
00:33:01,680 --> 00:33:04,320
strongly. And then if you look at other startups and you sort
679
00:33:04,320 --> 00:33:06,400
of get these investor updates and you talk to these founders,
680
00:33:06,400 --> 00:33:08,480
they're struggling with ups and downs every day too, right?
681
00:33:08,480 --> 00:33:12,320
It sort of relativizes what you do because you're like if it's
682
00:33:12,320 --> 00:33:15,120
going really well, you're like, ah, well, I know it's going to
683
00:33:15,120 --> 00:33:16,800
get shitty again at some point. Like I'm not going to be
684
00:33:16,800 --> 00:33:19,760
disillusioned from this high right now, nor if it goes really
685
00:33:19,760 --> 00:33:22,800
badly. I look at that and I go, well, it sucks right now, but I
686
00:33:22,800 --> 00:33:24,320
know it's going to get better again, right? Like this just
687
00:33:24,320 --> 00:33:26,160
happens to be a load that happened and now we just got to
688
00:33:26,160 --> 00:33:30,800
deal with it and make it better. The way I invest has changed
689
00:33:30,800 --> 00:33:34,160
over time. I'm really focused on companies where I feel like I
690
00:33:34,160 --> 00:33:37,920
have a unique understanding of the market or the situation or
691
00:33:38,480 --> 00:33:40,720
it's something that I would use because I have a unique
692
00:33:40,720 --> 00:33:42,560
perspective as a software engineer that's founded my own
693
00:33:42,560 --> 00:33:45,840
company that has now run through this process of building up a
694
00:33:45,840 --> 00:33:48,320
whole enterprise go to market motion. I understand many things
695
00:33:48,320 --> 00:33:51,280
that many people don't and definitely not in this detail.
696
00:33:51,280 --> 00:33:54,160
And so then looking at that and going, hey, I might have an
697
00:33:54,160 --> 00:33:56,480
edge in this investing game through having this understanding
698
00:33:56,480 --> 00:33:59,280
that many other people don't. And so I invest in companies
699
00:33:59,280 --> 00:34:03,280
like Incident.io and Fly.io and Z.dev and whatever where I see
700
00:34:03,280 --> 00:34:06,400
something unique that I think the market broadly doesn't
701
00:34:06,400 --> 00:34:08,800
understand yet and hopefully will understand at some point.
702
00:34:08,800 --> 00:34:11,760
Or even better, it's something that I use myself that I love,
703
00:34:11,760 --> 00:34:15,440
like Raycast. I'm a huge Raycast user and so I'm a proud
704
00:34:15,440 --> 00:34:17,920
investor there as well. That's sort of generally how I invest
705
00:34:17,920 --> 00:34:19,920
and then the main thing that matters to me is really the
706
00:34:19,920 --> 00:34:22,000
people, the founders, or the founders that I think could
707
00:34:22,000 --> 00:34:26,320
build a really, really big company. I will also say now
708
00:34:26,320 --> 00:34:29,600
with how the market has shifted around IPOs and acquisitions
709
00:34:29,600 --> 00:34:33,760
where effectively they aren't happening, the bar for success
710
00:34:33,760 --> 00:34:36,080
has gotten so much higher that investing as a whole, I think,
711
00:34:36,080 --> 00:34:38,880
will have to be redefined a little bit because it's going
712
00:34:38,880 --> 00:34:42,960
to be very difficult to say whether or not anybody is going
713
00:34:42,960 --> 00:34:45,360
to be able to have any return. Not even me, but like I
714
00:34:45,360 --> 00:34:48,080
I've written off that money a long time ago and I really just
715
00:34:48,080 --> 00:34:50,320
invest for fun. But a lot of these professional investors
716
00:34:50,320 --> 00:34:52,800
that I fund, I'm very curious to see what's going to happen
717
00:34:52,800 --> 00:34:55,440
over the next couple of years as this develops because I don't
718
00:34:55,440 --> 00:34:57,760
know how they're going to get their returns. In order for a
719
00:34:57,760 --> 00:35:00,320
company to IPO is now so much harder than it used to be in the
720
00:35:00,320 --> 00:35:03,440
past that way fewer companies are going to IPO and even then
721
00:35:03,440 --> 00:35:06,000
they're going to IPO at lower valuations even if they IPO.
722
00:35:06,000 --> 00:35:08,800
And so the whole math of that business, I don't know if it
723
00:35:08,800 --> 00:35:11,200
still works. I don't know how investors are thinking about
724
00:35:11,200 --> 00:35:14,960
this, but very curious to see what's going to happen over the
725
00:35:14,960 --> 00:35:18,080
next few years with the startup ecosystem. I'm very fortunate to
726
00:35:18,080 --> 00:35:19,840
be in the position that I am right now and I'm very curious
727
00:35:19,840 --> 00:35:23,920
to stay on top of that more. Yeah, me too. I'm super
728
00:35:23,920 --> 00:35:27,760
interested. We had a really big run of just free money
729
00:35:27,760 --> 00:35:31,760
everywhere and now it seems a little bit, the calculus has
730
00:35:31,760 --> 00:35:36,640
changed a little bit. So very cool. Well, Max, I won't take
731
00:35:36,640 --> 00:35:39,040
up too much more of your time. Is there anything that you
732
00:35:39,040 --> 00:35:41,760
want to plug before we sign off today?
733
00:35:41,760 --> 00:35:44,560
I just want to say like if you're a company that faces one
734
00:35:44,560 --> 00:35:45,920
of the problems that I was talking about that GraphQL
735
00:35:45,920 --> 00:35:48,560
solves or using GraphQL today, I would love to chat with you.
736
00:35:48,560 --> 00:35:50,720
If you have a problem that our product solve or if you have a
737
00:35:50,720 --> 00:35:52,560
problem that you think GraphQL solves, I would love to talk to
738
00:35:52,560 --> 00:35:55,120
you. I'm always open to give advice from all these
739
00:35:55,120 --> 00:35:57,360
conversations that I've had based on your situation.
740
00:35:57,360 --> 00:35:59,360
Explore whether or not that actually makes sense for you.
741
00:35:59,360 --> 00:36:02,560
Just reach out max.sella.co, email me anytime, happy to help
742
00:36:02,560 --> 00:36:05,840
on a call and just chat. I don't have to sell you anything.
743
00:36:05,840 --> 00:36:08,880
All I ask for in return is that you answer my questions and I
744
00:36:08,880 --> 00:36:11,360
get to learn more about the product. I'm happy to do that.
745
00:36:11,360 --> 00:36:13,920
I want to learn more about what problems you run into and how
746
00:36:13,920 --> 00:36:16,080
you thought about solving them in the past. That's really all
747
00:36:16,080 --> 00:36:17,040
I'm hoping to get out of it.
748
00:36:17,040 --> 00:36:20,800
I love it. That's an extremely good offer. Max is one of the
749
00:36:20,800 --> 00:36:25,600
smartest people out there and one of the OGs of GraphQL.
750
00:36:25,600 --> 00:36:30,240
So take him up on that for sure. And yeah, I think check out
751
00:36:30,240 --> 00:36:33,520
that article. You probably don't need GraphQL. I've read it
752
00:36:33,520 --> 00:36:37,440
many times and it started a little bit of a Twitter ex
753
00:36:37,440 --> 00:36:41,920
story about GraphQL in general. And it's a really interesting,
754
00:36:42,480 --> 00:36:45,840
I feel like transitional moment, but GraphQL is here to stay
755
00:36:45,840 --> 00:36:50,480
for sure. And I see it all the time how beneficial it is,
756
00:36:50,480 --> 00:36:54,800
especially for really huge companies who the data problems
757
00:36:54,800 --> 00:36:58,480
that they're facing are not insignificant. And as you said,
758
00:36:58,480 --> 00:37:03,120
it really just, it doesn't advertise that it solves all of
759
00:37:03,120 --> 00:37:07,920
these problems, but does. So I love that you're helping the
760
00:37:07,920 --> 00:37:11,920
communication around GraphQL too, because I think it's super
761
00:37:11,920 --> 00:37:15,520
important. So anyway, thank you so much, Max, for being here
762
00:37:15,520 --> 00:37:18,960
today. I think you're one of the smartest, coolest people
763
00:37:18,960 --> 00:37:22,240
out there and it's been really fun chatting. Thank you so much.
764
00:37:23,120 --> 00:37:24,880
Thank you for having me. This was awesome.
765
00:37:24,880 --> 00:37:28,320
Awesome. Well, thank you all so much for joining the Last Tech
766
00:37:28,320 --> 00:37:33,360
Podcast. We'll see you next time.