WEBVTT
00:00:00.260 --> 00:00:05.360
You would end up every time wanting to solve the problem by your own, but be ready to abandon.
00:00:05.509 --> 00:00:10.759
It's good to have innovation mindset and try to suggest yourself if you have the bandwidth with it.
00:00:11.439 --> 00:00:15.439
There's the question of focus because you have as a product company, you have so many things to solve.
00:00:15.980 --> 00:00:23.269
So provide it that you have the bandwidth for it, try it, but make sure that you quickly like, okay, this is not good.
00:00:23.620 --> 00:00:25.750
It's clear that we are not going that direction.
00:00:25.960 --> 00:00:27.989
Let's find an alternative and it's okay.
00:00:28.480 --> 00:00:32.109
Don't be too much attached to your innovation and to your ideas.
00:00:32.219 --> 00:00:32.990
Just that's it.
00:00:33.250 --> 00:00:33.750
No problem.
00:00:34.130 --> 00:00:38.710
We move to the right thing that people people are using and people have already habit for
00:00:40.829 --> 00:00:46.299
How you, everyone, and welcome to developer experience a podcast by Golia.
00:00:46.520 --> 00:00:54.140
We chat with guests who build products for developers about their developer experience, strategy, what it means for them, why it's important.
00:00:54.600 --> 00:00:55.219
And so on.
00:00:55.520 --> 00:00:56.780
My name is Saha young.
00:00:56.840 --> 00:01:05.969
And on today's episode, we are going to talk about what it takes for a technical product to blend in other people's code bases.
00:01:06.430 --> 00:01:11.569
How do you ensure that developers want to put your code in their code?
00:01:12.150 --> 00:01:18.930
Why is it as important to offer idiomatic integrations as it is to build powerful APIs?
00:01:19.700 --> 00:01:27.040
Lucky for me, I have two guests who have looked at these questions from a fair number of angles.
00:01:27.680 --> 00:01:30.760
Sad is the founder and CEO of Prismic.
00:01:31.140 --> 00:01:34.599
One of the leading headless CMS solutions out there.
00:01:34.859 --> 00:01:45.230
He was one of the founding architects of the Prismic API, and now leads a growing team who build and maintain for a dozen integrations on top of it.
00:01:45.750 --> 00:01:46.189
Hi SEK.
00:01:46.599 --> 00:01:46.950
Hello.
00:01:46.959 --> 00:01:48.030
Thank you for having me.
00:01:48.650 --> 00:01:51.069
Our second guest is one of our own Harun.
00:01:51.430 --> 00:01:55.030
BI is a software engineer at Algolia for years.
00:01:55.260 --> 00:02:08.580
He's been working on many of algo's integrations, including all web flavors of the instant search UI libraries and the JavaScript API clients for search analytics, personalization, and so on.
00:02:09.050 --> 00:02:13.219
He's also the craftsman behind the search experience of yarn.
00:02:13.870 --> 00:02:14.500
Hello, Aun.
00:02:15.189 --> 00:02:15.539
Hello.
00:02:15.729 --> 00:02:16.979
Nice to meet you again.
00:02:17.750 --> 00:02:18.460
Let's get started.
00:02:18.469 --> 00:02:19.020
Shall we?
00:02:19.039 --> 00:02:35.689
So when I look at, uh, at both PR make and Algolia both companies offer a wide range of rappers around their APIs, like API clients, UI libraries, integrations, what's behind that choice.
00:02:36.030 --> 00:02:40.530
Why is it no longer enough to just build really good, low level APIs?
00:02:40.870 --> 00:02:44.009
But there are a lot of very, uh, tough decisions you have to do in the market.
00:02:44.439 --> 00:02:48.960
I mean, the market is moving so so quickly you call them technical products.
00:02:49.090 --> 00:02:54.719
There are so many choices nowadays, but you know, the whole thing it started with with APIs, right?
00:02:54.721 --> 00:02:56.400
It was the first abstraction.
00:02:56.580 --> 00:02:58.319
We always have to talk about abstractions.
00:02:58.819 --> 00:03:04.479
And the fair decision that you have to think about is that, okay, I have my software, right?
00:03:04.599 --> 00:03:11.400
I have, I'm doing a website, an app, whatever it is that I'm doing, and I need to integrate parts of it.
00:03:11.419 --> 00:03:12.759
And I don't want to develop these parts.
00:03:12.979 --> 00:03:15.159
It comes all from, from this first thing, right?
00:03:15.439 --> 00:03:16.800
I don't want to develop everything.
00:03:16.800 --> 00:03:17.719
Like I need to search.
00:03:18.159 --> 00:03:19.990
I don't want to go and develop the whole search.
00:03:20.069 --> 00:03:20.629
I mean, it's fine.
00:03:20.650 --> 00:03:26.669
As a developer, I so much would love to do it, but you know, you want to focus on the important part where, where you add value.
00:03:26.780 --> 00:03:31.509
Like for instance, we have a, one of our clients, they do, uh, like, like made.com, right?
00:03:31.849 --> 00:03:35.870
And they, they always tell like, look, the search is not exactly our domain.
00:03:36.030 --> 00:03:36.990
Our domain is somewhere else.
00:03:37.219 --> 00:03:37.509
Okay.
00:03:37.849 --> 00:03:42.460
So we want to be the state of the art of different comp other components.
00:03:42.759 --> 00:03:45.259
But then we want to make the difference in one place.
00:03:45.449 --> 00:03:47.860
This is why they will take maybe Algolia for a search.
00:03:48.099 --> 00:03:51.379
They will take, maybe take maybe Prismic for, you know, their content.
00:03:51.479 --> 00:03:52.699
And so and so on and so on.
00:03:52.960 --> 00:04:00.250
And then they say, okay, if I, if I have my code base, right, that is doing my, the platform or the product, and I have to great with the others.
00:04:00.310 --> 00:04:01.129
How can I do that?
00:04:01.810 --> 00:04:03.289
Um, there's so many ways to do that.
00:04:03.290 --> 00:04:05.729
But the first abstraction was like, okay, call an API.
00:04:05.789 --> 00:04:10.009
And this way you have the abstraction, at least your servers, you're not managing the servers.
00:04:10.009 --> 00:04:11.569
The servers are managed by someone else.
00:04:11.570 --> 00:04:12.689
You don't have to care about it.
00:04:12.691 --> 00:04:14.129
You tell it, give me an environment.
00:04:14.131 --> 00:04:15.490
I give you an environment and that's it.
00:04:15.990 --> 00:04:19.569
So all the complexity is hidden and you have so many options.
00:04:20.100 --> 00:04:21.560
It allows you right to scale.
00:04:21.560 --> 00:04:23.480
It allows you to improve performance.
00:04:23.660 --> 00:04:25.079
It allows you to do a lot of things.
00:04:25.081 --> 00:04:28.040
So you give you options, but it's one abstraction there, the API.
00:04:28.339 --> 00:04:37.360
So it made a lot of sense right now that was the beginning, but it still, it still makes a lot of sense to have this kind of abstraction so that I don't have to care about all these kind of things until it's important.
00:04:37.470 --> 00:04:39.160
When I have to deal about performance.
00:04:39.639 --> 00:04:42.470
I know that at solution will bring me all this stuff.
00:04:42.620 --> 00:04:46.949
When I care about scalability, it will gimme all the options, but my abstraction in the API.
00:04:47.370 --> 00:04:50.269
So I think it all started by this and it's a very good abstraction.
00:04:50.329 --> 00:04:56.110
So it's, we should not kind of neglect that kind of basis and go jump into other things in my view.
00:04:56.129 --> 00:04:58.189
And this is how we develop things in Prismic.
00:04:58.370 --> 00:05:01.300
We should lay foundation over foundation in.
00:05:01.480 --> 00:05:06.459
If we don't have the right foundation at the API, we can start getting to another level of obstruction.
00:05:06.500 --> 00:05:08.540
I don't know what har you, you think about it.
00:05:09.120 --> 00:05:09.899
Do you have any comment?
00:05:10.089 --> 00:05:10.379
Yeah,
00:05:10.379 --> 00:05:15.500
That's uh, that's, that's very important thing to talk about these different foundations.
00:05:16.009 --> 00:05:23.529
What I've noticed is that most of these different layers, they form very naturally over time.
00:05:24.040 --> 00:05:31.290
Like you will start indeed by making an as good as possible way to retrieve certain information.
00:05:31.750 --> 00:05:36.209
And in almost all cases, that will start being in normal HT P API.
00:05:36.670 --> 00:05:50.240
But on top of that, when you talk to your customers, you will quickly see that there certain things, certain mistakes that they keep making or certain ways in which you cannot just guide them enough.
00:05:50.740 --> 00:05:53.000
So there's this thing called simple requests.
00:05:53.399 --> 00:06:05.040
I dunno if you've heard of that, but if you make an XML HTP request, then a course will kick in when there is any number of headers.
00:06:05.060 --> 00:06:10.600
That's not of like a super limited standard set of headers at Algolia.
00:06:10.620 --> 00:06:12.160
We care a lot about performance.
00:06:12.860 --> 00:06:20.589
And one downside of having a course request is this actually does two network requests for your first call.
00:06:21.209 --> 00:06:27.350
And, you know, that could be up to a couple hundred milliseconds in the first case, it's just pretty annoying.
00:06:28.209 --> 00:06:39.939
So we could ask all of our customers to say like, Hey, go ahead and make sure you avoid the, the course request by doing this and that and making sure it is in the query parameter and not via the body.
00:06:40.480 --> 00:06:47.899
Making sure that you say that the body is form coded, even though it's Jason stuff like that, you wanna avoid as much as possible.
00:06:48.480 --> 00:06:57.850
So we saw the people being struggled, struggling with that, and you wrap it up in a solution in our case, that solution was an API co land.
00:06:58.310 --> 00:07:03.209
But I think this analogy goes for every problem that you try to solve for customers.
00:07:03.769 --> 00:07:04.689
I like how you build it.
00:07:04.690 --> 00:07:07.529
Like for instance, you can go and document things, right?
00:07:07.870 --> 00:07:27.240
You can go and make a good tutorials and, you know, good documentation about how to avoid course or how to avoid extra, um, uh, requests and so on and so on, which will might be effective, but still, maybe you can make always like a solution that makes you, uh, that people should not maybe care about this thing and just take the abstraction.
00:07:27.620 --> 00:07:32.800
If it works enough, then they will not need even to go into documentation because you know, you take care of it.
00:07:33.060 --> 00:07:35.040
And you know, we have to explore a lot of layers.
00:07:35.040 --> 00:07:36.519
Like we started with the API, right?
00:07:36.521 --> 00:07:41.670
And then you say, maybe I can make a kit and I put this kind of abstraction in it so that it's baked in.
00:07:41.750 --> 00:07:42.389
I document it.
00:07:42.410 --> 00:07:44.709
If people want to do it for another technology, they can do it.
00:07:44.829 --> 00:07:46.310
And, and there's so many things to explore there.
00:07:46.790 --> 00:07:50.790
Uh, but we'll explore these kind of things, but I will stop, uh, still on the API side.
00:07:51.329 --> 00:08:00.939
And, you know, uh, it's funny when we, when, you know, the whole API thing started, people were like, okay, let's do an API as if it was a purpose and it's on, but an API is nothing.
00:08:01.089 --> 00:08:02.339
It's a technical word, right?
00:08:02.800 --> 00:08:06.300
As like, imagine someone today tells you, I want to do an interface.
00:08:07.060 --> 00:08:07.060
Yeah.
00:08:07.060 --> 00:08:08.660
That doesn't give much information.
00:08:08.661 --> 00:08:09.540
Like, okay, thank you.
00:08:09.569 --> 00:08:12.660
Like you want to do an interface for what exactly.
00:08:12.959 --> 00:08:17.540
So the API should look like the problem, what people want to achieve with the API.
00:08:17.560 --> 00:08:21.170
And this is a question that we get often like with Pring, like, oh, I want to do this.
00:08:21.389 --> 00:08:24.129
We want to write API, but write API doesn't mean much.
00:08:24.449 --> 00:08:26.569
Actually write what for what?
00:08:27.290 --> 00:08:35.009
Because if you are writing, like, I don't know, models, it will be very different than if you're writing for, you know, migration or writing for something else.
00:08:35.110 --> 00:08:38.210
And you need to explore these topics before jumping into the solution.
00:08:38.669 --> 00:08:40.009
Now, of course there are two school.
00:08:40.539 --> 00:08:49.200
You can provide some kind of API and then look at how people use your API and then try to do to correct the API and then migrate people.
00:08:49.659 --> 00:08:58.960
Or you could, uh, do I, I sub I don't know if I, if the iPhone did it in purpose or not, but it seems to me that it, there were a purpose in there, the copy paste of text.
00:08:59.139 --> 00:09:01.440
It didn't exist for ages in iPhone.
00:09:02.139 --> 00:09:06.000
And I suppose this is completely I'm, I'm making things up here.
00:09:06.000 --> 00:09:06.200
Right.
00:09:06.500 --> 00:09:11.240
But I suppose the purpose was, why do people need copy paste?
00:09:11.240 --> 00:09:13.720
It's a generic solution to a lot of problems.
00:09:13.750 --> 00:09:14.039
Okay.
00:09:14.769 --> 00:09:16.110
But why do people need it?
00:09:16.139 --> 00:09:19.870
Some people need it simply to share with another app.
00:09:20.090 --> 00:09:25.909
As in, I have some text and I want to share it in slack, it's in my SMS or whatever it is.
00:09:25.910 --> 00:09:33.070
And then I want to share it in slack, or I want to, or some other things like sharing is one or getting into the app.
00:09:33.139 --> 00:09:38.019
Like I want to share something, but I want that to open in the app directly like a song.
00:09:38.320 --> 00:09:41.220
And then I click on the link and it opens Spotify right away.
00:09:41.279 --> 00:09:45.460
And then I have the song that's a completely different way of integration.
00:09:45.769 --> 00:09:46.059
Copy.
00:09:46.129 --> 00:09:50.820
Pasting was hiding all kinds of features, all kind of things that people wanted.
00:09:51.360 --> 00:10:12.809
And I think it, to me, at least they waited a little bit until they have the different cases and they solve the major cases and then say, okay, now we can copy paste if none of these solutions are working, because that will force you to focus on these kind of things and not to find some kind of work around that will make everyone satisfied, kind of satisfied, but then you, you don't get innovation.
00:10:13.190 --> 00:10:14.490
So API is the same.
00:10:15.210 --> 00:10:20.639
My, they are too two schools, two ways of doing it, but I'm more for like, okay, why do you need an API?
00:10:20.640 --> 00:10:21.080
Exactly.
00:10:21.669 --> 00:10:21.960
Okay.
00:10:22.019 --> 00:10:25.120
And, and there are a lot of good reasons for having an API, right?
00:10:25.220 --> 00:10:35.360
So I'm not challenging that, but you need first to, to develop something that blends well in the code base is to match the problem that they're trying to solve.
00:10:35.539 --> 00:10:39.309
And, and often you will find a solution that will solve 80% of the cases.
00:10:40.129 --> 00:10:42.429
And then you'll have an API that is not verbal.
00:10:42.580 --> 00:10:45.470
That goes right to the goal that they're trying to do.
00:10:45.850 --> 00:11:07.700
And then as you said, you can put a layer on top of it, say, okay, now the API is proper, but there's something I can't solve in the API because they need to have it in the app in front end on JavaScript where the course thing, and you can do it out of time and then, okay, I can make a kit so that all the user of the kit provided that we have enough people that use the kit and less people provide, like, use the API.
00:11:08.090 --> 00:11:14.299
Well, they will have it outta the box without, without even thinking of the concept, of course, or maybe thinking very little of it.
00:11:14.440 --> 00:11:18.649
So I like that kind of layered approach of solving problems the way you explain it.
00:11:18.710 --> 00:11:19.970
So that's really interesting.
00:11:20.210 --> 00:11:36.809
You, you touched on on many topics, but the two big ones that I've heard, especially, we're talking about technical products right now, and we're talking about APIs because this is the shape that both SMIC and Algolia take, and then you have things on top of it, dashboards, API, clients, whatever.
00:11:36.950 --> 00:11:43.320
But you talked about a fact that you want to solve problems and solve mistakes that people often make.
00:11:43.620 --> 00:11:52.039
And that you also want to, for people not to have to think about it, which arguably you could do without an APA client.
00:11:52.210 --> 00:11:52.559
Right.
00:11:53.019 --> 00:12:08.519
And so one of the things I would say as a user, and it's not the only thing, but as a user, when I, when I think of the ideal way of integrating with a service, when it comes to coding with that service, like I need to code something that accesses that functionality.
00:12:08.700 --> 00:12:12.789
The first thing that comes to mind is that it needs to be idiomatic or right.
00:12:12.850 --> 00:12:15.350
It should feel natural in my code base.
00:12:15.529 --> 00:12:17.509
It should use the IDMs of my language.
00:12:17.669 --> 00:12:23.990
I don't want to have something in my code that fits that doesn't look like it belongs there, right.
00:12:24.269 --> 00:12:45.019
It, it should kind of look like if I wrote it on a very good day, do you think that one of the major reasons why one would make API clients in the language like the target languages, like you would make a ick integration for Java and one for rails and one for, or you would, you would make instant search for view and for react, et cetera.
00:12:45.559 --> 00:12:47.700
Is it like the biggest seller?
00:12:48.360 --> 00:12:49.419
Is there more to it?
00:12:49.559 --> 00:12:59.490
Is there something very, very important that we are not, that can only be solved by, uh, a language specific framework, specific API clients?
00:13:00.450 --> 00:13:04.049
I think what you're trying to do is solve certain problems.
00:13:04.120 --> 00:13:22.399
When you create something, when you create an API client or, or a client library for, let's say synchronizing with a database, you will see that this is actually pretty complicated and quite a lot of good for the users to do themselves going from listening to the changes.
00:13:22.580 --> 00:13:28.159
And then maybe you need to check whether it's already updated and, and this kind of things.
00:13:28.779 --> 00:13:32.200
And this code done by users will quickly balloon.
00:13:32.620 --> 00:13:35.750
So this needs to be bundled up in some way.
00:13:35.980 --> 00:13:45.750
When you see that there's enough people with the problem, because code is written in programming language, you obviously need to match whatever, um, is done.
00:13:46.240 --> 00:13:51.149
There is not really a universal code language so that you only need to write it once.
00:13:51.779 --> 00:13:55.580
There's, I mean, it's been tried plenty of times, but it doesn't really work.
00:13:56.769 --> 00:13:58.379
There's just two, two different.
00:13:58.440 --> 00:14:04.820
So you, any code that you write automatically has an interface because it needs to be used.
00:14:06.240 --> 00:14:16.409
So what I think is more is the fact that you need to match this idioms is just because the codes there and needs to be exposed in some way, you better it the right way.
00:14:17.129 --> 00:14:20.450
Let, let me start by saying, we are the champions of doing these kind of mistakes.
00:14:20.970 --> 00:14:29.049
Fri started well inside project and all as a, a scale thing, scale programming, language, the JVM and all of that.
00:14:29.070 --> 00:14:33.889
And like, we were like toed guys, you know, these strong type and all of these kind of things.
00:14:33.950 --> 00:14:42.399
And it had a huge influence on the first API, the rest API that we got out, it was inspired from what was in our head.
00:14:42.400 --> 00:14:42.720
Right.
00:14:42.820 --> 00:14:54.200
And I was, it's also E very easy, uh, as a developer to kind of, uh, I don't know, get a little bit religious on the programming language that you use because you solve a lot of problems with it.
00:14:54.220 --> 00:14:56.320
And you like the, the, you know, practices.
00:14:56.539 --> 00:15:04.720
And by, by, at the time, you know, uh, strongly statically types, programming languages were like really the, the fun thing to do.
00:15:05.059 --> 00:15:11.070
At some point, we realize that our API is not so easy to use in, for instance, JavaScript.
00:15:11.129 --> 00:15:20.509
And they also re realized that most of our, our users, they develop websites and web apps, and that is using a lot of JavaScript.
00:15:20.970 --> 00:15:23.549
And I was like, okay, that's a problem, right?
00:15:23.690 --> 00:15:24.389
That's a problem.
00:15:24.950 --> 00:15:26.870
It's not easy to use people were using the product yet.
00:15:26.990 --> 00:15:30.750
I mean, we had something good out there, but the API wasn't one of them.
00:15:31.360 --> 00:15:33.779
So people was like, know, it's a weird API.
00:15:33.879 --> 00:15:35.740
We don't understand why it's written that way.
00:15:35.840 --> 00:15:38.179
And you know, it's a hassle to, to, to deal with.
00:15:38.879 --> 00:15:42.620
And that's where more than four years ago, we started with a lot, okay.
00:15:42.679 --> 00:15:45.820
We need to rewrite our API, like complete rewrite.
00:15:45.879 --> 00:15:55.730
The Jay zone structure was not simple, you know, because in JavaScript you can access very easily, like dot, dot, dot, dot, but in other language, you couldn't do that.
00:15:56.070 --> 00:16:07.090
So we had to do something special for these languages to find out that most of our users come from JavaScript, which means like we were wrong at, I mean, it wasn't, it was a mistake to do it that way.
00:16:07.269 --> 00:16:08.610
So we had to change our API.
00:16:08.759 --> 00:16:16.360
That was a lot to learn, you know, at that very basic level of API rest API, you still have to return Aja zone.
00:16:16.659 --> 00:16:19.000
And Jayn the Jayn did you return?
00:16:19.220 --> 00:16:21.799
It should look like the language friendly with the language.
00:16:22.019 --> 00:16:23.919
Now, if it's for JavaScript, it needs to be simple.
00:16:24.019 --> 00:16:25.399
You need to access things easily.
00:16:26.100 --> 00:16:35.149
And then after doing this API, we had also to get to in front of the challenge of graph, uh, QL, whatever people think of it today, but it was, you know, users were coming.
00:16:35.309 --> 00:16:36.389
I had my opinion about it.
00:16:36.509 --> 00:16:44.190
I thought like maybe in a lot, a lot of places, it will not serve us so much, but still you had a lot of users demanding and we had to solve it.
00:16:44.730 --> 00:16:51.509
So even at the APIs, uh, we're not even in the kit, you still have to make a decision.
00:16:51.610 --> 00:16:55.620
And it's easy to say like, oh, it's service APIs, a general go, go deal with it.
00:16:55.960 --> 00:17:01.750
But no, you aren't making a choice either you do it, or you let the universe do it for you.
00:17:02.169 --> 00:17:03.830
And if the universe do it well, it's random.
00:17:03.970 --> 00:17:04.750
And maybe it's good.
00:17:04.750 --> 00:17:06.470
Maybe it's not, but you have to make the choice.
00:17:06.490 --> 00:17:08.869
And we did the choice, like JavaScript is our target.
00:17:09.410 --> 00:17:13.470
So we, we want to do an API that is easier for the JavaScript word.
00:17:13.799 --> 00:17:18.700
Now it seems like one thing JavaScript, but is so big because JavaScript is react.
00:17:19.019 --> 00:17:21.779
It's view it's it's Gadsby's next.
00:17:21.849 --> 00:17:22.420
It's Knox.
00:17:22.421 --> 00:17:23.819
It's so many things today.
00:17:25.039 --> 00:17:27.740
So at the kit level, we had to do the same kind of effort.
00:17:28.029 --> 00:17:30.980
There is time where I used to work with Eric Meyer.
00:17:30.980 --> 00:17:35.450
Eric Meyer was one of the people that worked on different programming languages.
00:17:35.470 --> 00:17:38.769
And then he, he was so enthusiastic about exploring JavaScript.
00:17:38.829 --> 00:17:43.849
For some reason, I like, I like that fact of his, like really pragmatic on these kind of things.
00:17:44.029 --> 00:17:47.009
And he told me we should do leaky abstractions.
00:17:47.010 --> 00:17:50.319
And I was like, the, how come like abstraction should not be leaky.
00:17:50.320 --> 00:17:51.119
What you talking about?
00:17:51.420 --> 00:17:54.319
And he was like, no, people need to understand how things happen.
00:17:54.619 --> 00:17:56.680
If they break, they will know how to fix it.
00:17:56.681 --> 00:18:04.799
Or if they, if their case gets out of this abstraction that you get, then they have some kind of hook, some kind of things that allow them to extend and solve their problems.
00:18:04.819 --> 00:18:11.589
Anyway, because it's, if it's too closed, then you will get in a case like the course quest that you'd asked about, they will have a special case.
00:18:12.190 --> 00:18:20.230
They, they should be a way where they can extend it, because if you abstract it away in a kit, like we were talking about the kit and you did something on top of, uh, of the API.
00:18:20.650 --> 00:18:26.990
But if their case gets out of that, they need to have some kind of hooks of some kind of ways so that they can get out of that and solve their problem.
00:18:27.049 --> 00:18:37.099
Or otherwise they have to go to the low level API and start working with that, which is a very big move at some point, like they might have all their app already done and they have one case.
00:18:37.480 --> 00:18:42.900
And for that case, you're going to punish them and get them like, oh, go learn the whole thing.
00:18:43.440 --> 00:18:46.900
So it should be like a little bit have mechanisms that allow you to okay.
00:18:47.619 --> 00:18:51.049
Open that abstraction and, and hook it into it and do something about it.
00:18:51.200 --> 00:18:51.490
Yeah.
00:18:51.569 --> 00:18:54.009
I think you're talking about escape hatches, right?
00:18:54.109 --> 00:19:04.769
And that's something that I think you retweeted Arun that I like, I don't know from who exactly, but like the fact that an API client is only as strong as I like the power of its escape.
00:19:04.770 --> 00:19:05.210
Hatches.
00:19:05.480 --> 00:19:05.769
Yeah.
00:19:05.970 --> 00:19:07.809
That was a quote from, uh, Sunil PI.
00:19:08.150 --> 00:19:14.400
He wrote that the, of an abstraction can be measured in the quality of its escape patches.
00:19:14.470 --> 00:19:20.680
When you think about when things go wrong, that means you probably have talked about almost everything.
00:19:21.099 --> 00:19:32.230
And really when things go wrong, if you design that case first, then automatically the hard becomes much simpler.
00:19:32.930 --> 00:19:42.349
So if from the start you think about what if people don't like how I'm, let's say requesting the, the API.
00:19:42.769 --> 00:20:05.420
And so you think about that and you make some kind of way to replace whatever built in solution you had at that point, you will automatically have become much more resilient for different, uh, interfaces, maybe for internet Explorer, all of a sudden, now you can let people make their own request or that you didn't even have to think about.
00:20:05.940 --> 00:20:07.099
I think that's very interesting.
00:20:07.119 --> 00:20:14.970
And, and another approach and something that you thought, uh, touched on earlier is that everything becomes much more, right?
00:20:15.190 --> 00:20:22.450
The moment that you decide to be simpler, the easier your end points are, the easier your returns are.
00:20:22.670 --> 00:20:26.250
The less work you'll have to do to make it work well.
00:20:26.470 --> 00:20:33.200
And for the customers, if you have something that's very complicated, you'll probably need to wrap it 15 times it before it looks nice.
00:20:33.710 --> 00:20:34.000
Yeah.
00:20:34.000 --> 00:20:34.240
Yeah.
00:20:34.240 --> 00:20:38.480
This is one of the things that we did instead wrapping the, the same API into another thing.
00:20:38.480 --> 00:20:40.200
Let's simplify the, the first API.
00:20:40.220 --> 00:20:42.480
And then maybe we can build things on top of it.
00:20:42.640 --> 00:20:48.359
I was in the camp of let's design things perfectly since the beginning, and then everything will work.
00:20:48.500 --> 00:20:53.960
And I, I kind of changed also with a lot of people that were, you know, around me and inspire me and do that.
00:20:53.980 --> 00:21:00.279
And also while facing problems, J Armstrong, he's one of the creators of Ang and all, all the thing.
00:21:00.280 --> 00:21:02.880
And he was like, you should not find failure.
00:21:02.980 --> 00:21:04.119
You should embrace failure.
00:21:04.740 --> 00:21:09.589
As in, he's more talking about history systems and how you need to accept failure.
00:21:09.740 --> 00:21:15.750
It's part of, you know, it's not exceptional, like in language, in programming language, we, we deal with it as it's an exception.
00:21:16.170 --> 00:21:17.829
You know, something happen exceptional.
00:21:17.829 --> 00:21:19.190
We call exceptions and stuff.
00:21:19.630 --> 00:21:20.710
It like, it's not exceptional.
00:21:20.711 --> 00:21:21.190
It's life.
00:21:21.191 --> 00:21:22.150
Failure is life.
00:21:22.529 --> 00:21:34.099
So in abstractions, I, I apply now, nowadays I apply exactly same as a it, I write code, we design stuff, but we design it with this abstraction is going to fail okay.
00:21:34.509 --> 00:21:38.019
Where it's going to fail is what we will understand in the coming months.
00:21:38.359 --> 00:21:48.769
And that's why we should be like, okay, the first thing is that we, we could be the best in the world, but we will fail anyway, because we are not using this API as many, as much as our users.
00:21:49.309 --> 00:22:10.119
So that's why integrating a team of developer experience has been so important for us because they're closer to the framework, closer the language and the framework that they and the users so that they get these kind of cases where in theory, it should not happen, but in practice, it happens because ABC or because you are you using this tool with it or, or this and that.
00:22:10.660 --> 00:22:27.799
And actually this reminds me also of one thing that even if it's hard, the easiest and the most less complex thing is that the initial design, the hardest is how your kit is going to work with all the, the 100 other tools that they are using in the same time.
00:22:27.940 --> 00:22:31.950
And that it can only discover by, by having that kind of connection with users.
00:22:32.049 --> 00:22:53.059
And that's why, I guess, developer experience team like developers that are specialized in a framework like in, in not I'm, I'm not saying like in react, I'm saying in next, a person that is specialized in next or in Gadsby or next will, will allow you to find these kind of things and to solve a M and these little annoying things is what's taking time from developers.
00:22:53.160 --> 00:23:02.779
If you want people to be quick into implementing your API, your solution, then you need to kind of get solve these little annoying things because they are time consuming.
00:23:02.779 --> 00:23:11.490
And they so hard because you need to search on stack over flow and the other, and find the solution in the forum that doesn apply, because the version has upgraded.
00:23:11.960 --> 00:23:20.950
It's a huge headache for, for, for winning list little, and that's not motivating because you're spending like hours for, for, for advancing this step.
00:23:21.609 --> 00:23:32.819
So you can capture these, solve them by having someone that is listening all the time, that the users and making sure that these are souls, because they could be actually really low cost, big wins.
00:23:32.960 --> 00:23:34.900
If you get that kind of flow, uh, going,
00:23:35.440 --> 00:23:38.180
That's actually an excellent segue to my next question.
00:23:38.359 --> 00:23:51.119
You're talking about like those specific ecosystems, and I know Arun, you have a, a lot of knowledge around that, you know, how a single SDK or integration or whatever can easily become a whole project, right?
00:23:51.230 --> 00:23:55.599
With its own problems on top of the API that you are catering to.
00:23:55.859 --> 00:24:05.549
So for example, whenever you are building something for a view or for react automatically, you have SSR service side rendering, which become a topic.
00:24:06.210 --> 00:24:13.069
It hasn't anything to do with search per se or content per se, but it's a problem that belongs to this ecosystem.
00:24:13.250 --> 00:24:20.390
It doesn't exist necessarily when you are indexing content or sending content, but it exists in react when you're rendering something.
00:24:20.930 --> 00:24:27.059
And so you are building new things and they come with their new problems that you're solving for others.
00:24:27.319 --> 00:24:32.220
But that adds also to your load as the maintainer of that, that solution.
00:24:32.920 --> 00:24:41.579
And so I'd love to know from your experience, what are the common pitfalls that you should avoid when you're building an integration?
00:24:42.940 --> 00:24:48.049
I think a common pitfall is building an integration is making stuff.
00:24:48.750 --> 00:24:51.650
The code itself to start with is very easy.
00:24:52.230 --> 00:24:58.650
And it's essentially just, I made an application and you take the code and you put it in its own place.
00:24:59.269 --> 00:25:03.809
But from then onwards, as you just mentioned, the code exists, you need to maintain it.
00:25:03.829 --> 00:25:11.519
So I think a lot to solve with that is managing expectations is saying like, look, you can use this, but I just wrote the code.
00:25:11.920 --> 00:25:14.359
I didn't really test it in production yet.
00:25:14.500 --> 00:25:23.039
And I think that's okay for a lot of small things, because you can gauge how much interest there is in a certain solution, just like, go quick, do it.
00:25:23.819 --> 00:25:31.190
And then at a certain point, you'll notice that are spending quite a lot of time on it or that a lot the people are using it.
00:25:31.990 --> 00:25:39.910
I think at that point you can, um, you can refactor and then make things a little, little different, make things easier.
00:25:42.000 --> 00:25:56.900
And yeah, I think we, we, we said that before, but, uh, the more you wrap stuff, the, the less you expose of the original framework, the harder it is to work around edge cases.
00:25:57.220 --> 00:26:06.619
I think what you want to do is something that, especially if that's not like your main number one focus is to make it very easy for people to solve their own problems.
00:26:06.839 --> 00:26:07.740
You can help them.
00:26:07.839 --> 00:26:09.410
And over time, see the problem.
00:26:09.480 --> 00:26:15.450
Many times you can start by writing a guide or even just fixing it all together for, let's say SSR.
00:26:15.559 --> 00:26:23.690
It's a very tough balance to strike, to both still expose everything that needs to be exposed, but not make super complicated API.
00:26:23.691 --> 00:26:24.849
That solves nothing.
00:26:25.079 --> 00:26:26.769
It's probably one of the hardest problems.
00:26:27.200 --> 00:26:30.640
This comes as a good advice for even us as a company.
00:26:31.440 --> 00:26:39.799
Cuz you know, Sarah, when you ask the question inside the question, I read it maybe differently or maybe this is how you see it, but there are so many opportunities.
00:26:39.800 --> 00:26:41.720
This is the thing it's hard to say.
00:26:41.859 --> 00:26:45.359
No, it's, it's very hard to say no, Sarah cyber rendering, great.
00:26:45.910 --> 00:26:46.200
Okay.
00:26:46.299 --> 00:26:47.079
An opportunity.
00:26:47.080 --> 00:26:48.240
That means an opportunity.
00:26:48.240 --> 00:26:50.279
That means we can do things better, right?
00:26:50.819 --> 00:26:52.759
Or image optimization.
00:26:52.940 --> 00:26:54.160
That's a great opportunity.
00:26:54.259 --> 00:26:55.400
We want to jump into it.
00:26:55.420 --> 00:26:57.839
We want to solve it now, can we solve it and be better?
00:26:57.890 --> 00:26:59.640
Daniella's but that's not.
00:26:59.839 --> 00:27:04.910
If enough, imagine we solve the problem and you know, our solution is better, their people's habit.
00:27:05.730 --> 00:27:10.869
So even if we solve it better than the others, will people be ready to change their habits?
00:27:11.009 --> 00:27:13.910
Are they having enough pain there to change their habits?
00:27:14.589 --> 00:27:21.349
Uh, so sometimes it sounds like, look like we, we, we looked at image optimization, okay.
00:27:21.351 --> 00:27:28.619
And we said like, okay, this is an important problem for content writers or for content teams for our websites, you know, web apps that have content.
00:27:28.960 --> 00:27:30.539
We said, okay, we will have a functionality.
00:27:30.819 --> 00:27:33.779
We can define different sizes of images and we will serve all of that.
00:27:33.780 --> 00:27:40.099
So that in the interface you'll be able to say like, okay, this size, that size, that size, you know, different sizes for different devices.
00:27:40.160 --> 00:27:41.619
And then you will be able to solve it.
00:27:41.849 --> 00:27:42.299
It's good.
00:27:42.559 --> 00:27:51.930
And you can manage it of from the interface it's nice and all, but at the same time, there's something that emerg in the image API or image pipelines, they call, there are different names for this.
00:27:52.769 --> 00:28:01.809
Um, where, you know, as a developer, in the link of the, of the, of, of the image, you can add parameters of the size and the resolution.
00:28:01.990 --> 00:28:06.960
And lot of other things like there are, you know, today images, our, our partner does it.
00:28:07.680 --> 00:28:13.039
Um, we provide out the box, but there are cloud area and a lot of others that provide it as a service.
00:28:13.259 --> 00:28:16.319
Now our first way of solving the problem could be good.
00:28:16.329 --> 00:28:19.000
Could be maybe better even, but does it matter?
00:28:19.259 --> 00:28:24.480
People took some kind of habit and this habit is like success.
00:28:24.750 --> 00:28:28.670
Well, and we had to make a decision like, okay, well people want to use that.
00:28:28.819 --> 00:28:31.190
They have the habit, we couldn't change their habit.
00:28:31.650 --> 00:28:34.069
And especially this seems to be working well.
00:28:34.289 --> 00:28:42.910
So we chose to kind of, uh, against our own feature to go and partner with, with images in that kind of case and say, okay, let's, let's give them that.
00:28:43.220 --> 00:28:43.509
Okay.
00:28:43.510 --> 00:28:45.700
Let's give them exactly what they want all out of the box.
00:28:45.920 --> 00:28:51.059
Any image, any image that comes from SMIC you have, you can put these kind of parameters in that's.
00:28:51.059 --> 00:28:51.619
That's nice.
00:28:51.779 --> 00:28:54.900
And all now you you're talking about the pitfalls.
00:28:54.930 --> 00:28:56.779
Well, here, the pitfall was okay.
00:28:56.819 --> 00:28:57.900
I want to solve it myself.
00:28:58.329 --> 00:28:58.619
Okay.
00:28:58.621 --> 00:29:00.740
Because it sounds like you're doing a platform.
00:29:01.140 --> 00:29:02.940
Its like, okay, I want to solve problems.
00:29:03.000 --> 00:29:04.859
And I want to solve this problem as well.
00:29:05.279 --> 00:29:08.849
And we had our solution, but the community was going in any way.
00:29:09.279 --> 00:29:12.009
That was not exactly aligned with this one.
00:29:12.269 --> 00:29:14.690
So the most important thing is like, listen to these people.
00:29:14.691 --> 00:29:15.809
What they, they want to do.
00:29:15.810 --> 00:29:16.769
Innovation is good.
00:29:17.269 --> 00:29:22.369
But innovation is hard for one main reason is that the timing is hard in innovation.
00:29:22.839 --> 00:29:29.720
Like it's easier, uh, to find a solution and say like, okay, is solving it really, really good, but how can you make people change habits?
00:29:29.721 --> 00:29:30.519
They need to be ready.
00:29:31.059 --> 00:29:34.559
So if you are too early in innovation, it doesn't matter.
00:29:34.710 --> 00:29:35.599
It's not going to happen.
00:29:35.660 --> 00:29:37.359
If you're too late, it's not going to happen.
00:29:37.500 --> 00:29:38.440
The timing is hard.
00:29:38.579 --> 00:29:41.799
So if you find something that has the good timing, just try it on the timing.
00:29:42.900 --> 00:29:43.359
No problem.
00:29:43.539 --> 00:29:45.279
You're wrong, you right or wrong.
00:29:45.280 --> 00:29:45.839
Who cares?
00:29:46.019 --> 00:29:48.359
If, if your solution is the best or not, no one cares.
00:29:48.599 --> 00:29:51.039
Actually the industry wants a solution that is efficient.
00:29:51.180 --> 00:29:53.640
And that is, you know, you don't have to learn a lot.
00:29:53.859 --> 00:29:55.880
So if people are ready, maybe your solution will be good.
00:29:55.980 --> 00:30:02.789
If your solution is not ready well, right on, on the other solution, if it's good enough and this is what we did and we had a lot of success with it.
00:30:03.190 --> 00:30:10.349
I, I think this is one of them is like you would end up every time wanting to solve the problem by your own, but be ready to abandon.
00:30:10.500 --> 00:30:15.630
It's good to have innovation mindset and try to suggest yourself if you have the bandwidth with it.
00:30:16.349 --> 00:30:20.470
There's the question of focus because you have as a product company, you have so many things to solve.
00:30:21.119 --> 00:30:26.220
So provided that you have the bandwidth for it, try it, but make sure that you fail quickly.
00:30:26.450 --> 00:30:28.259
Like, okay, this is not good.
00:30:28.609 --> 00:30:30.740
It's clear that we are not going that direction.
00:30:30.950 --> 00:30:37.059
Let's find an alternative and it's okay, don't be too much attached to your innovation, to your ideas.
00:30:37.170 --> 00:30:37.900
Just that's it.
00:30:38.160 --> 00:30:38.619
No problem.
00:30:39.000 --> 00:30:44.369
We move to the right thing that people, people are and people have already the habit, uh, for
00:30:44.920 --> 00:30:57.369
Your answer actually gives me a good opportunity to go back to something that we mentioned earlier that you remember when we're talking about escape hatches and making sure that you let people get out of your integration if they need it.
00:30:57.670 --> 00:31:08.400
One thing I've noticed whenever I use a service is that the more layers of abstractions you have around the primitive API, the more opinions go into it, right?
00:31:08.500 --> 00:31:15.039
So whenever I'm using the, like let's say the HTP rest API, I'm using that directly.
00:31:15.160 --> 00:31:19.799
I will have a lot more freedom, uh, a lot more power, but it's also more risks.
00:31:20.420 --> 00:31:24.990
And when I'm using the SDK than it's like, I can start a lot faster.
00:31:25.650 --> 00:31:29.910
But sometimes there are things that will be harder to do.
00:31:29.911 --> 00:31:36.029
Like it controls really like draws the path for me and sometimes it can be harder to get out.
00:31:36.030 --> 00:31:42.910
And so we discuss that there is a balance to strike between, you know, the power and preventing people from making mistakes.
00:31:43.329 --> 00:31:54.779
They cannot recover from I'd love to know based on those principles and based on the fact that we make mistakes, as you just said, and sometimes we fail at nailing the right abstraction and it's time to decide and to make a change.
00:31:55.089 --> 00:32:05.970
What, in your opinion, and based on your experience, building such integrations, what makes an integration successful and maybe conversely, what would be the red flags telling you?
00:32:06.160 --> 00:32:07.809
Okay, it's time to make a change.
00:32:07.900 --> 00:32:30.720
Maybe it's time, even for a major version, which is kind of a big decision because you're asking people to care about your service while they care about their app and not your service specifically, what would be for you signs that the abstraction that you've designed is succeeding with customers and red flags telling you, okay, maybe we need to change something.
00:32:32.200 --> 00:32:38.599
I think it's important to have a lot of metrics around the usage of what you make.
00:32:39.180 --> 00:32:57.519
If you make integrations, make sure to tag them in some way, we use a user agent so that even afterwards we can just look and say, oh, this has X percentage of usage or this thing that we spend some time on, literally three people are using it.
00:32:57.819 --> 00:32:58.789
How can it be worked?
00:32:59.029 --> 00:33:00.630
It, I think that's that's one way.
00:33:01.150 --> 00:33:07.390
And, and another thing that you mentioned as well is, um, it can be dangerous to have major versions.
00:33:07.710 --> 00:33:08.549
I think that's true.
00:33:08.569 --> 00:33:12.950
But I think also that the fear sometimes is overblown.
00:33:13.529 --> 00:33:17.349
It is only dangerous to have major versions when you have a lot of users.
00:33:18.509 --> 00:33:28.940
Um, and when you only want to have like one thing to support, obviously when you have one thing to support that there's less work.
00:33:29.000 --> 00:33:34.859
People don't have to do it, but you should also make sure that people who are happy and don't want to change anything.
00:33:34.861 --> 00:33:45.200
They really don't have to, like, you can have major versions, but we, for example, have never deprecated anything.
00:33:46.119 --> 00:34:02.230
And uh, like literally you can't use it anymore in the API and the lowest level, even old parameters that we've renamed because to name was really bad and the new one is way better and explains everything better.
00:34:02.380 --> 00:34:10.349
That doesn't mean that you can't today still use a name that was decided in 2012, even though we changed it in 2014.
00:34:10.769 --> 00:34:12.670
And I think that's something very important.
00:34:12.820 --> 00:34:15.230
Like why are you afraid of a major version?
00:34:15.289 --> 00:34:21.179
Is it because you think people aren't going to update is that maybe cuz your update kit isn't good to enough.
00:34:21.400 --> 00:34:28.579
Is that maybe because it is just too hard to update or is it cuz they have no need to, if they have no need to, there's nothing wrong with it.
00:34:28.650 --> 00:34:33.139
They can stay on the oldest version that they made their application originally on.
00:34:33.519 --> 00:34:34.940
If they're happy with it, it's fine.
00:34:34.960 --> 00:34:35.340
For me,
00:34:36.119 --> 00:34:37.619
The question is, is pretty simple.
00:34:38.079 --> 00:34:40.139
The answer is really complex as usual.
00:34:40.280 --> 00:34:45.289
And I would like so much to give some kind of advice so that I look like the person that knows everything.
00:34:45.690 --> 00:34:46.889
I don't, I don't know.
00:34:47.489 --> 00:34:58.050
I mean, I can tell what happened with us and you know, maybe they will serve for a lesson for someone or you know, at least not to do the same mistakes again, there's so many thing ways to look at it, but let me give you an example.
00:34:58.199 --> 00:34:58.489
Okay.
00:34:58.490 --> 00:35:09.760
Like, and, and there's something that we didn't touch on and I so much wanted have some time in it, but now I know that we don't have the time in it, the SDK integration, which is an, a, some kind of API, you know, library.
00:35:10.019 --> 00:35:14.320
And then you, you know, talk to the API, but through the library, JavaScript library or something like that.
00:35:14.320 --> 00:35:24.469
But there is another approach that is really getting very, very interesting actually is the component level abstraction as in for your image, use this component, okay.
00:35:24.650 --> 00:35:28.670
Use the component, the component image in next or in, uh, next.
00:35:29.210 --> 00:35:32.789
And then it will do the proper API calls and you will give it a provider.
00:35:32.929 --> 00:35:41.199
So it can be, and this gives you a good abstraction so that you can change also providers, like you can jump from cloudy to MES to anyone else or to a server on your own.
00:35:41.440 --> 00:35:48.320
And that's a nice abstraction so that you just throw this component and you give it the past to your image and that's it you're done.
00:35:48.460 --> 00:35:50.360
And then everything is else is managed for you.
00:35:50.360 --> 00:35:58.070
So this another level I talked about this layers like API SDK, and then you have also the, the component level, which is a very cool abstraction.
00:35:58.070 --> 00:36:00.469
And we are working a lot on this on PRIs.
00:36:00.489 --> 00:36:05.590
We have a component called slide zone that will, uh, go and initiate all the slices, whatever it is.
00:36:05.650 --> 00:36:14.909
If you look at, at how things developed with, for instance, Gadsby, they, they provide in the beginning, some kind of job that will go through all the images that exist in, in the app.
00:36:15.289 --> 00:36:18.619
And they will do it at bill time and they'll resize them and optimize them.
00:36:18.621 --> 00:36:19.260
That was nice.
00:36:19.280 --> 00:36:22.739
But as an abstraction to my eyes, it wasn't a good abstraction.
00:36:23.000 --> 00:36:29.019
It was more focused on the, how than the, the why, what you, the, what, what you're doing exactly.
00:36:29.480 --> 00:36:34.219
So what you were doing, you were providing an image and you know, you wanted that image to be optimized.
00:36:34.679 --> 00:36:36.500
You didn't want to know that it's a build time.
00:36:36.501 --> 00:36:40.289
You didn't want to soft at the build time of like doing that generation.
00:36:40.469 --> 00:36:50.929
And then next and next came with this component, the image component where that's a better abstraction because you have to give it a, a URL or the past to the image.
00:36:51.230 --> 00:36:53.010
And then you tell it, this is my provider.
00:36:53.400 --> 00:36:58.920
Your provider could be a server on local host, or it could be some, uh, cloud service.
00:36:59.219 --> 00:37:00.000
It doesn't matter.
00:37:00.380 --> 00:37:02.280
The component will do it right now.
00:37:02.449 --> 00:37:07.400
Maybe it just because Gadsby went through that way, it inspired a better abstraction.
00:37:07.710 --> 00:37:09.480
Most probably this is the case, right?
00:37:09.539 --> 00:37:12.920
It started with like, we need absolutely to manage this for users.
00:37:13.099 --> 00:37:14.039
And then, okay.
00:37:14.380 --> 00:37:16.199
The others say like, how can we make it better?
00:37:16.619 --> 00:37:17.639
So it's always progress.
00:37:17.739 --> 00:37:23.309
If you are going into that kind of process, you need to look at the, at the decisions that you made and say like that was wrong.
00:37:23.730 --> 00:37:36.590
So it always boils down to, to say like, am I ready to face my decisions and to understand whether they were right or wrong and abandon something, an effort that I did, this is very hard.
00:37:36.590 --> 00:37:37.710
Like, it's a typical thing.
00:37:37.710 --> 00:37:42.940
When you go out, if your home and you don't have the keys, you so much want, don't want to return to home.
00:37:43.440 --> 00:37:45.420
And you know, you don't want to go the way back.
00:37:45.730 --> 00:37:57.860
Once you go one, one way, you don't want to go the way back, but I make it a, an exercise for myself every time I have to go and regret the effort or, or at least look at the effort that I did and, and go, and it's okay.
00:37:57.929 --> 00:38:00.210
It's okay to abandon an effort or your question.
00:38:00.389 --> 00:38:08.010
If I look at it from different perspective, are you talking about the user or are, are you talking about the producer for me as a producer of, of the service?
00:38:08.610 --> 00:38:09.289
I have two options.
00:38:09.519 --> 00:38:09.809
Okay.
00:38:10.190 --> 00:38:14.250
Am I optimizing for new people or am I optimizing for existing people?
00:38:14.449 --> 00:38:14.969
I have to choose.
00:38:15.130 --> 00:38:16.130
I have to make a decision.
00:38:16.329 --> 00:38:19.210
I have to make a choice or the universe will do it for me.
00:38:19.469 --> 00:38:31.239
So what is the choice that I'm going to do if I'm optimizing for new users, as in, I see more potential in the market and the new coming users than the existing ones, then I will try to change the abstraction to make it better and better.
00:38:31.500 --> 00:38:33.719
And I will try to manage as much as I can.
00:38:33.780 --> 00:38:41.239
The existing provided there is risk in the existing that they will leave because if they keep suffering from, from my API, they will do, but I have a focus.
00:38:41.480 --> 00:38:43.519
I know what is my number one priority.
00:38:43.900 --> 00:38:52.159
And the others I will manage or the other way around it could be that I, I so much, it's more important for me, existing market, existing user.
00:38:52.400 --> 00:38:54.079
And it depends maybe also on the phase of the company.
00:38:54.530 --> 00:38:56.630
So it can be very different, uh, okay.
00:38:56.989 --> 00:38:57.469
Existing ones.
00:38:57.769 --> 00:39:10.190
And then, uh, I want to slowly get it better because like, I want to get to the, the, you know, instead of the art on the market, but I'm not going full innovation that because I'm not going for new market, I could be both ways.
00:39:10.190 --> 00:39:10.389
Right.
00:39:10.949 --> 00:39:15.980
Uh, some, some will say like 50, 50, but that's just not willing to take the decision, need to take a decision.
00:39:16.480 --> 00:39:23.420
And then for instance, for us, we're try and say, okay, we think that we still not yet at the place where we want to be.
00:39:23.719 --> 00:39:30.659
As in, in the simplicity of integrating content and building websites, we think we can do better for, for helping people building websites.
00:39:30.661 --> 00:39:32.659
That's why we're, we're still out for innovation.
00:39:32.760 --> 00:39:34.420
And we're trying to change things very quickly.
00:39:35.050 --> 00:39:35.340
Okay.
00:39:35.530 --> 00:39:36.889
But we know that this has a price.
00:39:37.230 --> 00:39:42.329
So what we do is that everything that is related to migration, we try to take care of it ourselves.
00:39:42.789 --> 00:39:49.329
Now, how now, the first thing that, uh, har talked about is like, you shouldn't understand who uses what so that you understand.
00:39:49.331 --> 00:39:50.050
What's the impact.
00:39:50.050 --> 00:39:51.170
That's a very important thing.
00:39:51.170 --> 00:39:55.449
But the second thing is like, can we MI do the migration for our users without mistakes?
00:39:55.590 --> 00:39:56.599
How can we do that?
00:39:56.601 --> 00:40:01.679
Well, first, if we own their data, then I mean, if we host it, then we can do the migration, maybe for them.
00:40:01.780 --> 00:40:02.599
That's first thing.
00:40:02.940 --> 00:40:06.559
The other thing is like, we run our migrations on, on live data.
00:40:06.980 --> 00:40:11.039
So basically we have shadow servers where we say, okay, now we are doing the migrations.
00:40:11.059 --> 00:40:11.800
We migrate data.
00:40:11.900 --> 00:40:15.360
And we do shadow requests so that we see, okay, is the response still the same?
00:40:15.360 --> 00:40:21.789
And we, we can do it this for like a week, a two weeks for, for like, um, millions of requests.
00:40:21.929 --> 00:40:23.789
And then we see like, okay, we didn't break anything.
00:40:23.849 --> 00:40:24.789
Now we can roll it out.
00:40:24.791 --> 00:40:25.030
Right.
00:40:25.289 --> 00:40:33.349
So you can have processes for doing migration, but you're choosing to do migrations, but you're saying, okay, I'm taking, trying to take care of the migration myself.
00:40:33.610 --> 00:40:36.309
So that user doesn't suffer, uh, of that.
00:40:36.610 --> 00:40:41.420
But you get decision in the beginning that I want to innovate and, and push innovation is going to change stuff.
00:40:41.449 --> 00:40:43.460
It's a lot of decisions on first.
00:40:43.460 --> 00:40:44.820
What do I want to optimize?
00:40:45.079 --> 00:40:46.260
And second, okay.
00:40:46.480 --> 00:40:48.900
How can I make it not painful for my existing users?
00:40:48.900 --> 00:40:51.940
Because the one, they are the one they trusted us, they are the one that brought us here.
00:40:51.940 --> 00:40:55.139
How can I make sure that it, it doesn't become a pain for them.
00:40:55.880 --> 00:41:02.530
And the fact that we don't don't migrate them, it's a pain, it's a pain that is going to surface afterwards.
00:41:02.710 --> 00:41:03.289
We know it.
00:41:03.400 --> 00:41:12.570
They don't know it yet, but if we don't help them in the migration being up to date with their data, then at some point they're going to suffer because they will be the old approach.
00:41:12.570 --> 00:41:12.889
Right.
00:41:13.150 --> 00:41:14.489
So we need to keep them up to date.
00:41:14.590 --> 00:41:16.929
So for me, it's like, we should not ignore it.
00:41:16.931 --> 00:41:23.360
We should not like, look the other way and then say, okay, we will keep two versions of the API, or I don't know what, that's a bad thing.
00:41:23.380 --> 00:41:26.559
You know, you need to face it and say like, okay, how can we migrate that?
00:41:26.561 --> 00:41:29.159
So we try to take migration by, you know, on our own.
00:41:29.161 --> 00:41:33.039
We try to test on, on, on real data and, and still all of that.
00:41:33.119 --> 00:41:35.719
We still have places where we need to put guides.
00:41:35.949 --> 00:41:36.239
Okay.
00:41:36.739 --> 00:41:44.480
But for that, you know, what we choose to do is to have like a high availability on our service, on our people that will help them into the migration process.
00:41:44.539 --> 00:41:53.710
And we give them the time to do it so that they, they benefit from the new stuff because innovation will bring them a lot of good also for existing users.
00:41:54.190 --> 00:41:58.349
We, they need to understand why and why should they should dedicate time for it.
00:41:58.690 --> 00:42:10.510
That's super interesting said, and you know what, as much as I would love to stay the entire afternoon, talking about that, we need to wrap this up at some point, where can people go to find you online?
00:42:11.190 --> 00:42:11.989
Uh, you can, okay.
00:42:12.079 --> 00:42:14.460
There is press me IO.
00:42:14.659 --> 00:42:18.260
So P R I S M I c.io.
00:42:18.960 --> 00:42:19.539
And I'm sad.
00:42:19.739 --> 00:42:20.460
I I'm on Twitter.
00:42:20.860 --> 00:42:23.940
S S a D a C H E.
00:42:24.300 --> 00:42:27.940
I don't tweet much, but you know, from time to time, you can
00:42:27.940 --> 00:42:29.019
Follow on Twitter.
00:42:29.199 --> 00:42:32.739
My account is har V for my last name.
00:42:33.300 --> 00:42:35.769
Uh, H a R O E N V.
00:42:36.769 --> 00:42:45.210
And you can find me on Twitter at front stuff on school IO or on my side, Saha Saha with an h.com.
00:42:46.489 --> 00:42:49.449
Sadek a thank you so much for chatting with me today.
00:42:49.469 --> 00:42:52.050
It was extremely interesting listeners.
00:42:52.449 --> 00:43:02.800
I hope you had a blaster, all things, API clients and integrations and UI libraries and API design went so much further than what initially anticipated.
00:43:02.860 --> 00:43:04.079
And that's the beauty of it.
00:43:04.081 --> 00:43:09.440
Thanks a lot for following developer experience and stay tuned for the next episode.
00:43:10.349 --> 00:43:14.480
This was developer experience, a podcast brought to you by Algolia.
00:43:15.210 --> 00:43:18.190
You can find this podcast on your favorite podcast platform.
00:43:18.650 --> 00:43:25.190
We are on Spotify, apple podcast, Google podcast, Pandora, overcast, everywhere.
00:43:25.849 --> 00:43:32.789
If you want to know more about Algolia check us out on algolia.com and we are at Algolia on Twitter.
00:00:00.260 --> 00:00:05.360
You would end up every time wanting to solve the problem by your own, but be ready to abandon.
00:00:05.509 --> 00:00:10.759
It's good to have innovation mindset and try to suggest yourself if you have the bandwidth with it.
00:00:11.439 --> 00:00:15.439
There's the question of focus because you have as a product company, you have so many things to solve.
00:00:15.980 --> 00:00:23.269
So provide it that you have the bandwidth for it, try it, but make sure that you quickly like, okay, this is not good.
00:00:23.620 --> 00:00:25.750
It's clear that we are not going that direction.
00:00:25.960 --> 00:00:27.989
Let's find an alternative and it's okay.
00:00:28.480 --> 00:00:32.109
Don't be too much attached to your innovation and to your ideas.
00:00:32.219 --> 00:00:32.990
Just that's it.
00:00:33.250 --> 00:00:33.750
No problem.
00:00:34.130 --> 00:00:38.710
We move to the right thing that people people are using and people have already habit for
00:00:40.829 --> 00:00:46.299
How you, everyone, and welcome to developer experience a podcast by Golia.
00:00:46.520 --> 00:00:54.140
We chat with guests who build products for developers about their developer experience, strategy, what it means for them, why it's important.
00:00:54.600 --> 00:00:55.219
And so on.
00:00:55.520 --> 00:00:56.780
My name is Saha young.
00:00:56.840 --> 00:01:05.969
And on today's episode, we are going to talk about what it takes for a technical product to blend in other people's code bases.
00:01:06.430 --> 00:01:11.569
How do you ensure that developers want to put your code in their code?
00:01:12.150 --> 00:01:18.930
Why is it as important to offer idiomatic integrations as it is to build powerful APIs?
00:01:19.700 --> 00:01:27.040
Lucky for me, I have two guests who have looked at these questions from a fair number of angles.
00:01:27.680 --> 00:01:30.760
Sad is the founder and CEO of Prismic.
00:01:31.140 --> 00:01:34.599
One of the leading headless CMS solutions out there.
00:01:34.859 --> 00:01:45.230
He was one of the founding architects of the Prismic API, and now leads a growing team who build and maintain for a dozen integrations on top of it.
00:01:45.750 --> 00:01:46.189
Hi SEK.
00:01:46.599 --> 00:01:46.950
Hello.
00:01:46.959 --> 00:01:48.030
Thank you for having me.
00:01:48.650 --> 00:01:51.069
Our second guest is one of our own Harun.
00:01:51.430 --> 00:01:55.030
BI is a software engineer at Algolia for years.
00:01:55.260 --> 00:02:08.580
He's been working on many of algo's integrations, including all web flavors of the instant search UI libraries and the JavaScript API clients for search analytics, personalization, and so on.
00:02:09.050 --> 00:02:13.219
He's also the craftsman behind the search experience of yarn.
00:02:13.870 --> 00:02:14.500
Hello, Aun.
00:02:15.189 --> 00:02:15.539
Hello.
00:02:15.729 --> 00:02:16.979
Nice to meet you again.
00:02:17.750 --> 00:02:18.460
Let's get started.
00:02:18.469 --> 00:02:19.020
Shall we?
00:02:19.039 --> 00:02:35.689
So when I look at, uh, at both PR make and Algolia both companies offer a wide range of rappers around their APIs, like API clients, UI libraries, integrations, what's behind that choice.
00:02:36.030 --> 00:02:40.530
Why is it no longer enough to just build really good, low level APIs?
00:02:40.870 --> 00:02:44.009
But there are a lot of very, uh, tough decisions you have to do in the market.
00:02:44.439 --> 00:02:48.960
I mean, the market is moving so so quickly you call them technical products.
00:02:49.090 --> 00:02:54.719
There are so many choices nowadays, but you know, the whole thing it started with with APIs, right?
00:02:54.721 --> 00:02:56.400
It was the first abstraction.
00:02:56.580 --> 00:02:58.319
We always have to talk about abstractions.
00:02:58.819 --> 00:03:04.479
And the fair decision that you have to think about is that, okay, I have my software, right?
00:03:04.599 --> 00:03:11.400
I have, I'm doing a website, an app, whatever it is that I'm doing, and I need to integrate parts of it.
00:03:11.419 --> 00:03:12.759
And I don't want to develop these parts.
00:03:12.979 --> 00:03:15.159
It comes all from, from this first thing, right?
00:03:15.439 --> 00:03:16.800
I don't want to develop everything.
00:03:16.800 --> 00:03:17.719
Like I need to search.
00:03:18.159 --> 00:03:19.990
I don't want to go and develop the whole search.
00:03:20.069 --> 00:03:20.629
I mean, it's fine.
00:03:20.650 --> 00:03:26.669
As a developer, I so much would love to do it, but you know, you want to focus on the important part where, where you add value.
00:03:26.780 --> 00:03:31.509
Like for instance, we have a, one of our clients, they do, uh, like, like made.com, right?
00:03:31.849 --> 00:03:35.870
And they, they always tell like, look, the search is not exactly our domain.
00:03:36.030 --> 00:03:36.990
Our domain is somewhere else.
00:03:37.219 --> 00:03:37.509
Okay.
00:03:37.849 --> 00:03:42.460
So we want to be the state of the art of different comp other components.
00:03:42.759 --> 00:03:45.259
But then we want to make the difference in one place.
00:03:45.449 --> 00:03:47.860
This is why they will take maybe Algolia for a search.
00:03:48.099 --> 00:03:51.379
They will take, maybe take maybe Prismic for, you know, their content.
00:03:51.479 --> 00:03:52.699
And so and so on and so on.
00:03:52.960 --> 00:04:00.250
And then they say, okay, if I, if I have my code base, right, that is doing my, the platform or the product, and I have to great with the others.
00:04:00.310 --> 00:04:01.129
How can I do that?
00:04:01.810 --> 00:04:03.289
Um, there's so many ways to do that.
00:04:03.290 --> 00:04:05.729
But the first abstraction was like, okay, call an API.
00:04:05.789 --> 00:04:10.009
And this way you have the abstraction, at least your servers, you're not managing the servers.
00:04:10.009 --> 00:04:11.569
The servers are managed by someone else.
00:04:11.570 --> 00:04:12.689
You don't have to care about it.
00:04:12.691 --> 00:04:14.129
You tell it, give me an environment.
00:04:14.131 --> 00:04:15.490
I give you an environment and that's it.
00:04:15.990 --> 00:04:19.569
So all the complexity is hidden and you have so many options.
00:04:20.100 --> 00:04:21.560
It allows you right to scale.
00:04:21.560 --> 00:04:23.480
It allows you to improve performance.
00:04:23.660 --> 00:04:25.079
It allows you to do a lot of things.
00:04:25.081 --> 00:04:28.040
So you give you options, but it's one abstraction there, the API.
00:04:28.339 --> 00:04:37.360
So it made a lot of sense right now that was the beginning, but it still, it still makes a lot of sense to have this kind of abstraction so that I don't have to care about all these kind of things until it's important.
00:04:37.470 --> 00:04:39.160
When I have to deal about performance.
00:04:39.639 --> 00:04:42.470
I know that at solution will bring me all this stuff.
00:04:42.620 --> 00:04:46.949
When I care about scalability, it will gimme all the options, but my abstraction in the API.
00:04:47.370 --> 00:04:50.269
So I think it all started by this and it's a very good abstraction.
00:04:50.329 --> 00:04:56.110
So it's, we should not kind of neglect that kind of basis and go jump into other things in my view.
00:04:56.129 --> 00:04:58.189
And this is how we develop things in Prismic.
00:04:58.370 --> 00:05:01.300
We should lay foundation over foundation in.
00:05:01.480 --> 00:05:06.459
If we don't have the right foundation at the API, we can start getting to another level of obstruction.
00:05:06.500 --> 00:05:08.540
I don't know what har you, you think about it.
00:05:09.120 --> 00:05:09.899
Do you have any comment?
00:05:10.089 --> 00:05:10.379
Yeah,
00:05:10.379 --> 00:05:15.500
That's uh, that's, that's very important thing to talk about these different foundations.
00:05:16.009 --> 00:05:23.529
What I've noticed is that most of these different layers, they form very naturally over time.
00:05:24.040 --> 00:05:31.290
Like you will start indeed by making an as good as possible way to retrieve certain information.
00:05:31.750 --> 00:05:36.209
And in almost all cases, that will start being in normal HT P API.
00:05:36.670 --> 00:05:50.240
But on top of that, when you talk to your customers, you will quickly see that there certain things, certain mistakes that they keep making or certain ways in which you cannot just guide them enough.
00:05:50.740 --> 00:05:53.000
So there's this thing called simple requests.
00:05:53.399 --> 00:06:05.040
I dunno if you've heard of that, but if you make an XML HTP request, then a course will kick in when there is any number of headers.
00:06:05.060 --> 00:06:10.600
That's not of like a super limited standard set of headers at Algolia.
00:06:10.620 --> 00:06:12.160
We care a lot about performance.
00:06:12.860 --> 00:06:20.589
And one downside of having a course request is this actually does two network requests for your first call.
00:06:21.209 --> 00:06:27.350
And, you know, that could be up to a couple hundred milliseconds in the first case, it's just pretty annoying.
00:06:28.209 --> 00:06:39.939
So we could ask all of our customers to say like, Hey, go ahead and make sure you avoid the, the course request by doing this and that and making sure it is in the query parameter and not via the body.
00:06:40.480 --> 00:06:47.899
Making sure that you say that the body is form coded, even though it's Jason stuff like that, you wanna avoid as much as possible.
00:06:48.480 --> 00:06:57.850
So we saw the people being struggled, struggling with that, and you wrap it up in a solution in our case, that solution was an API co land.
00:06:58.310 --> 00:07:03.209
But I think this analogy goes for every problem that you try to solve for customers.
00:07:03.769 --> 00:07:04.689
I like how you build it.
00:07:04.690 --> 00:07:07.529
Like for instance, you can go and document things, right?
00:07:07.870 --> 00:07:27.240
You can go and make a good tutorials and, you know, good documentation about how to avoid course or how to avoid extra, um, uh, requests and so on and so on, which will might be effective, but still, maybe you can make always like a solution that makes you, uh, that people should not maybe care about this thing and just take the abstraction.
00:07:27.620 --> 00:07:32.800
If it works enough, then they will not need even to go into documentation because you know, you take care of it.
00:07:33.060 --> 00:07:35.040
And you know, we have to explore a lot of layers.
00:07:35.040 --> 00:07:36.519
Like we started with the API, right?
00:07:36.521 --> 00:07:41.670
And then you say, maybe I can make a kit and I put this kind of abstraction in it so that it's baked in.
00:07:41.750 --> 00:07:42.389
I document it.
00:07:42.410 --> 00:07:44.709
If people want to do it for another technology, they can do it.
00:07:44.829 --> 00:07:46.310
And, and there's so many things to explore there.
00:07:46.790 --> 00:07:50.790
Uh, but we'll explore these kind of things, but I will stop, uh, still on the API side.
00:07:51.329 --> 00:08:00.939
And, you know, uh, it's funny when we, when, you know, the whole API thing started, people were like, okay, let's do an API as if it was a purpose and it's on, but an API is nothing.
00:08:01.089 --> 00:08:02.339
It's a technical word, right?
00:08:02.800 --> 00:08:06.300
As like, imagine someone today tells you, I want to do an interface.
00:08:07.060 --> 00:08:07.060
Yeah.
00:08:07.060 --> 00:08:08.660
That doesn't give much information.
00:08:08.661 --> 00:08:09.540
Like, okay, thank you.
00:08:09.569 --> 00:08:12.660
Like you want to do an interface for what exactly.
00:08:12.959 --> 00:08:17.540
So the API should look like the problem, what people want to achieve with the API.
00:08:17.560 --> 00:08:21.170
And this is a question that we get often like with Pring, like, oh, I want to do this.
00:08:21.389 --> 00:08:24.129
We want to write API, but write API doesn't mean much.
00:08:24.449 --> 00:08:26.569
Actually write what for what?
00:08:27.290 --> 00:08:35.009
Because if you are writing, like, I don't know, models, it will be very different than if you're writing for, you know, migration or writing for something else.
00:08:35.110 --> 00:08:38.210
And you need to explore these topics before jumping into the solution.
00:08:38.669 --> 00:08:40.009
Now, of course there are two school.
00:08:40.539 --> 00:08:49.200
You can provide some kind of API and then look at how people use your API and then try to do to correct the API and then migrate people.
00:08:49.659 --> 00:08:58.960
Or you could, uh, do I, I sub I don't know if I, if the iPhone did it in purpose or not, but it seems to me that it, there were a purpose in there, the copy paste of text.
00:08:59.139 --> 00:09:01.440
It didn't exist for ages in iPhone.
00:09:02.139 --> 00:09:06.000
And I suppose this is completely I'm, I'm making things up here.
00:09:06.000 --> 00:09:06.200
Right.
00:09:06.500 --> 00:09:11.240
But I suppose the purpose was, why do people need copy paste?
00:09:11.240 --> 00:09:13.720
It's a generic solution to a lot of problems.
00:09:13.750 --> 00:09:14.039
Okay.
00:09:14.769 --> 00:09:16.110
But why do people need it?
00:09:16.139 --> 00:09:19.870
Some people need it simply to share with another app.
00:09:20.090 --> 00:09:25.909
As in, I have some text and I want to share it in slack, it's in my SMS or whatever it is.
00:09:25.910 --> 00:09:33.070
And then I want to share it in slack, or I want to, or some other things like sharing is one or getting into the app.
00:09:33.139 --> 00:09:38.019
Like I want to share something, but I want that to open in the app directly like a song.
00:09:38.320 --> 00:09:41.220
And then I click on the link and it opens Spotify right away.
00:09:41.279 --> 00:09:45.460
And then I have the song that's a completely different way of integration.
00:09:45.769 --> 00:09:46.059
Copy.
00:09:46.129 --> 00:09:50.820
Pasting was hiding all kinds of features, all kind of things that people wanted.
00:09:51.360 --> 00:10:12.809
And I think it, to me, at least they waited a little bit until they have the different cases and they solve the major cases and then say, okay, now we can copy paste if none of these solutions are working, because that will force you to focus on these kind of things and not to find some kind of work around that will make everyone satisfied, kind of satisfied, but then you, you don't get innovation.
00:10:13.190 --> 00:10:14.490
So API is the same.
00:10:15.210 --> 00:10:20.639
My, they are too two schools, two ways of doing it, but I'm more for like, okay, why do you need an API?
00:10:20.640 --> 00:10:21.080
Exactly.
00:10:21.669 --> 00:10:21.960
Okay.
00:10:22.019 --> 00:10:25.120
And, and there are a lot of good reasons for having an API, right?
00:10:25.220 --> 00:10:35.360
So I'm not challenging that, but you need first to, to develop something that blends well in the code base is to match the problem that they're trying to solve.
00:10:35.539 --> 00:10:39.309
And, and often you will find a solution that will solve 80% of the cases.
00:10:40.129 --> 00:10:42.429
And then you'll have an API that is not verbal.
00:10:42.580 --> 00:10:45.470
That goes right to the goal that they're trying to do.
00:10:45.850 --> 00:11:07.700
And then as you said, you can put a layer on top of it, say, okay, now the API is proper, but there's something I can't solve in the API because they need to have it in the app in front end on JavaScript where the course thing, and you can do it out of time and then, okay, I can make a kit so that all the user of the kit provided that we have enough people that use the kit and less people provide, like, use the API.
00:11:08.090 --> 00:11:14.299
Well, they will have it outta the box without, without even thinking of the concept, of course, or maybe thinking very little of it.
00:11:14.440 --> 00:11:18.649
So I like that kind of layered approach of solving problems the way you explain it.
00:11:18.710 --> 00:11:19.970
So that's really interesting.
00:11:20.210 --> 00:11:36.809
You, you touched on on many topics, but the two big ones that I've heard, especially, we're talking about technical products right now, and we're talking about APIs because this is the shape that both SMIC and Algolia take, and then you have things on top of it, dashboards, API, clients, whatever.
00:11:36.950 --> 00:11:43.320
But you talked about a fact that you want to solve problems and solve mistakes that people often make.
00:11:43.620 --> 00:11:52.039
And that you also want to, for people not to have to think about it, which arguably you could do without an APA client.
00:11:52.210 --> 00:11:52.559
Right.
00:11:53.019 --> 00:12:08.519
And so one of the things I would say as a user, and it's not the only thing, but as a user, when I, when I think of the ideal way of integrating with a service, when it comes to coding with that service, like I need to code something that accesses that functionality.
00:12:08.700 --> 00:12:12.789
The first thing that comes to mind is that it needs to be idiomatic or right.
00:12:12.850 --> 00:12:15.350
It should feel natural in my code base.
00:12:15.529 --> 00:12:17.509
It should use the IDMs of my language.
00:12:17.669 --> 00:12:23.990
I don't want to have something in my code that fits that doesn't look like it belongs there, right.
00:12:24.269 --> 00:12:45.019
It, it should kind of look like if I wrote it on a very good day, do you think that one of the major reasons why one would make API clients in the language like the target languages, like you would make a ick integration for Java and one for rails and one for, or you would, you would make instant search for view and for react, et cetera.
00:12:45.559 --> 00:12:47.700
Is it like the biggest seller?
00:12:48.360 --> 00:12:49.419
Is there more to it?
00:12:49.559 --> 00:12:59.490
Is there something very, very important that we are not, that can only be solved by, uh, a language specific framework, specific API clients?
00:13:00.450 --> 00:13:04.049
I think what you're trying to do is solve certain problems.
00:13:04.120 --> 00:13:22.399
When you create something, when you create an API client or, or a client library for, let's say synchronizing with a database, you will see that this is actually pretty complicated and quite a lot of good for the users to do themselves going from listening to the changes.
00:13:22.580 --> 00:13:28.159
And then maybe you need to check whether it's already updated and, and this kind of things.
00:13:28.779 --> 00:13:32.200
And this code done by users will quickly balloon.
00:13:32.620 --> 00:13:35.750
So this needs to be bundled up in some way.
00:13:35.980 --> 00:13:45.750
When you see that there's enough people with the problem, because code is written in programming language, you obviously need to match whatever, um, is done.
00:13:46.240 --> 00:13:51.149
There is not really a universal code language so that you only need to write it once.
00:13:51.779 --> 00:13:55.580
There's, I mean, it's been tried plenty of times, but it doesn't really work.
00:13:56.769 --> 00:13:58.379
There's just two, two different.
00:13:58.440 --> 00:14:04.820
So you, any code that you write automatically has an interface because it needs to be used.
00:14:06.240 --> 00:14:16.409
So what I think is more is the fact that you need to match this idioms is just because the codes there and needs to be exposed in some way, you better it the right way.
00:14:17.129 --> 00:14:20.450
Let, let me start by saying, we are the champions of doing these kind of mistakes.
00:14:20.970 --> 00:14:29.049
Fri started well inside project and all as a, a scale thing, scale programming, language, the JVM and all of that.
00:14:29.070 --> 00:14:33.889
And like, we were like toed guys, you know, these strong type and all of these kind of things.
00:14:33.950 --> 00:14:42.399
And it had a huge influence on the first API, the rest API that we got out, it was inspired from what was in our head.
00:14:42.400 --> 00:14:42.720
Right.
00:14:42.820 --> 00:14:54.200
And I was, it's also E very easy, uh, as a developer to kind of, uh, I don't know, get a little bit religious on the programming language that you use because you solve a lot of problems with it.
00:14:54.220 --> 00:14:56.320
And you like the, the, you know, practices.
00:14:56.539 --> 00:15:04.720
And by, by, at the time, you know, uh, strongly statically types, programming languages were like really the, the fun thing to do.
00:15:05.059 --> 00:15:11.070
At some point, we realize that our API is not so easy to use in, for instance, JavaScript.
00:15:11.129 --> 00:15:20.509
And they also re realized that most of our, our users, they develop websites and web apps, and that is using a lot of JavaScript.
00:15:20.970 --> 00:15:23.549
And I was like, okay, that's a problem, right?
00:15:23.690 --> 00:15:24.389
That's a problem.
00:15:24.950 --> 00:15:26.870
It's not easy to use people were using the product yet.
00:15:26.990 --> 00:15:30.750
I mean, we had something good out there, but the API wasn't one of them.
00:15:31.360 --> 00:15:33.779
So people was like, know, it's a weird API.
00:15:33.879 --> 00:15:35.740
We don't understand why it's written that way.
00:15:35.840 --> 00:15:38.179
And you know, it's a hassle to, to, to deal with.
00:15:38.879 --> 00:15:42.620
And that's where more than four years ago, we started with a lot, okay.
00:15:42.679 --> 00:15:45.820
We need to rewrite our API, like complete rewrite.
00:15:45.879 --> 00:15:55.730
The Jay zone structure was not simple, you know, because in JavaScript you can access very easily, like dot, dot, dot, dot, but in other language, you couldn't do that.
00:15:56.070 --> 00:16:07.090
So we had to do something special for these languages to find out that most of our users come from JavaScript, which means like we were wrong at, I mean, it wasn't, it was a mistake to do it that way.
00:16:07.269 --> 00:16:08.610
So we had to change our API.
00:16:08.759 --> 00:16:16.360
That was a lot to learn, you know, at that very basic level of API rest API, you still have to return Aja zone.
00:16:16.659 --> 00:16:19.000
And Jayn the Jayn did you return?
00:16:19.220 --> 00:16:21.799
It should look like the language friendly with the language.
00:16:22.019 --> 00:16:23.919
Now, if it's for JavaScript, it needs to be simple.
00:16:24.019 --> 00:16:25.399
You need to access things easily.
00:16:26.100 --> 00:16:35.149
And then after doing this API, we had also to get to in front of the challenge of graph, uh, QL, whatever people think of it today, but it was, you know, users were coming.
00:16:35.309 --> 00:16:36.389
I had my opinion about it.
00:16:36.509 --> 00:16:44.190
I thought like maybe in a lot, a lot of places, it will not serve us so much, but still you had a lot of users demanding and we had to solve it.
00:16:44.730 --> 00:16:51.509
So even at the APIs, uh, we're not even in the kit, you still have to make a decision.
00:16:51.610 --> 00:16:55.620
And it's easy to say like, oh, it's service APIs, a general go, go deal with it.
00:16:55.960 --> 00:17:01.750
But no, you aren't making a choice either you do it, or you let the universe do it for you.
00:17:02.169 --> 00:17:03.830
And if the universe do it well, it's random.
00:17:03.970 --> 00:17:04.750
And maybe it's good.
00:17:04.750 --> 00:17:06.470
Maybe it's not, but you have to make the choice.
00:17:06.490 --> 00:17:08.869
And we did the choice, like JavaScript is our target.
00:17:09.410 --> 00:17:13.470
So we, we want to do an API that is easier for the JavaScript word.
00:17:13.799 --> 00:17:18.700
Now it seems like one thing JavaScript, but is so big because JavaScript is react.
00:17:19.019 --> 00:17:21.779
It's view it's it's Gadsby's next.
00:17:21.849 --> 00:17:22.420
It's Knox.
00:17:22.421 --> 00:17:23.819
It's so many things today.
00:17:25.039 --> 00:17:27.740
So at the kit level, we had to do the same kind of effort.
00:17:28.029 --> 00:17:30.980
There is time where I used to work with Eric Meyer.
00:17:30.980 --> 00:17:35.450
Eric Meyer was one of the people that worked on different programming languages.
00:17:35.470 --> 00:17:38.769
And then he, he was so enthusiastic about exploring JavaScript.
00:17:38.829 --> 00:17:43.849
For some reason, I like, I like that fact of his, like really pragmatic on these kind of things.
00:17:44.029 --> 00:17:47.009
And he told me we should do leaky abstractions.
00:17:47.010 --> 00:17:50.319
And I was like, the, how come like abstraction should not be leaky.
00:17:50.320 --> 00:17:51.119
What you talking about?
00:17:51.420 --> 00:17:54.319
And he was like, no, people need to understand how things happen.
00:17:54.619 --> 00:17:56.680
If they break, they will know how to fix it.
00:17:56.681 --> 00:18:04.799
Or if they, if their case gets out of this abstraction that you get, then they have some kind of hook, some kind of things that allow them to extend and solve their problems.
00:18:04.819 --> 00:18:11.589
Anyway, because it's, if it's too closed, then you will get in a case like the course quest that you'd asked about, they will have a special case.
00:18:12.190 --> 00:18:20.230
They, they should be a way where they can extend it, because if you abstract it away in a kit, like we were talking about the kit and you did something on top of, uh, of the API.
00:18:20.650 --> 00:18:26.990
But if their case gets out of that, they need to have some kind of hooks of some kind of ways so that they can get out of that and solve their problem.
00:18:27.049 --> 00:18:37.099
Or otherwise they have to go to the low level API and start working with that, which is a very big move at some point, like they might have all their app already done and they have one case.
00:18:37.480 --> 00:18:42.900
And for that case, you're going to punish them and get them like, oh, go learn the whole thing.
00:18:43.440 --> 00:18:46.900
So it should be like a little bit have mechanisms that allow you to okay.
00:18:47.619 --> 00:18:51.049
Open that abstraction and, and hook it into it and do something about it.
00:18:51.200 --> 00:18:51.490
Yeah.
00:18:51.569 --> 00:18:54.009
I think you're talking about escape hatches, right?
00:18:54.109 --> 00:19:04.769
And that's something that I think you retweeted Arun that I like, I don't know from who exactly, but like the fact that an API client is only as strong as I like the power of its escape.
00:19:04.770 --> 00:19:05.210
Hatches.
00:19:05.480 --> 00:19:05.769
Yeah.
00:19:05.970 --> 00:19:07.809
That was a quote from, uh, Sunil PI.
00:19:08.150 --> 00:19:14.400
He wrote that the, of an abstraction can be measured in the quality of its escape patches.
00:19:14.470 --> 00:19:20.680
When you think about when things go wrong, that means you probably have talked about almost everything.
00:19:21.099 --> 00:19:32.230
And really when things go wrong, if you design that case first, then automatically the hard becomes much simpler.
00:19:32.930 --> 00:19:42.349
So if from the start you think about what if people don't like how I'm, let's say requesting the, the API.
00:19:42.769 --> 00:20:05.420
And so you think about that and you make some kind of way to replace whatever built in solution you had at that point, you will automatically have become much more resilient for different, uh, interfaces, maybe for internet Explorer, all of a sudden, now you can let people make their own request or that you didn't even have to think about.
00:20:05.940 --> 00:20:07.099
I think that's very interesting.
00:20:07.119 --> 00:20:14.970
And, and another approach and something that you thought, uh, touched on earlier is that everything becomes much more, right?
00:20:15.190 --> 00:20:22.450
The moment that you decide to be simpler, the easier your end points are, the easier your returns are.
00:20:22.670 --> 00:20:26.250
The less work you'll have to do to make it work well.
00:20:26.470 --> 00:20:33.200
And for the customers, if you have something that's very complicated, you'll probably need to wrap it 15 times it before it looks nice.
00:20:33.710 --> 00:20:34.000
Yeah.
00:20:34.000 --> 00:20:34.240
Yeah.
00:20:34.240 --> 00:20:38.480
This is one of the things that we did instead wrapping the, the same API into another thing.
00:20:38.480 --> 00:20:40.200
Let's simplify the, the first API.
00:20:40.220 --> 00:20:42.480
And then maybe we can build things on top of it.
00:20:42.640 --> 00:20:48.359
I was in the camp of let's design things perfectly since the beginning, and then everything will work.
00:20:48.500 --> 00:20:53.960
And I, I kind of changed also with a lot of people that were, you know, around me and inspire me and do that.
00:20:53.980 --> 00:21:00.279
And also while facing problems, J Armstrong, he's one of the creators of Ang and all, all the thing.
00:21:00.280 --> 00:21:02.880
And he was like, you should not find failure.
00:21:02.980 --> 00:21:04.119
You should embrace failure.
00:21:04.740 --> 00:21:09.589
As in, he's more talking about history systems and how you need to accept failure.
00:21:09.740 --> 00:21:15.750
It's part of, you know, it's not exceptional, like in language, in programming language, we, we deal with it as it's an exception.
00:21:16.170 --> 00:21:17.829
You know, something happen exceptional.
00:21:17.829 --> 00:21:19.190
We call exceptions and stuff.
00:21:19.630 --> 00:21:20.710
It like, it's not exceptional.
00:21:20.711 --> 00:21:21.190
It's life.
00:21:21.191 --> 00:21:22.150
Failure is life.
00:21:22.529 --> 00:21:34.099
So in abstractions, I, I apply now, nowadays I apply exactly same as a it, I write code, we design stuff, but we design it with this abstraction is going to fail okay.
00:21:34.509 --> 00:21:38.019
Where it's going to fail is what we will understand in the coming months.
00:21:38.359 --> 00:21:48.769
And that's why we should be like, okay, the first thing is that we, we could be the best in the world, but we will fail anyway, because we are not using this API as many, as much as our users.
00:21:49.309 --> 00:22:10.119
So that's why integrating a team of developer experience has been so important for us because they're closer to the framework, closer the language and the framework that they and the users so that they get these kind of cases where in theory, it should not happen, but in practice, it happens because ABC or because you are you using this tool with it or, or this and that.
00:22:10.660 --> 00:22:27.799
And actually this reminds me also of one thing that even if it's hard, the easiest and the most less complex thing is that the initial design, the hardest is how your kit is going to work with all the, the 100 other tools that they are using in the same time.
00:22:27.940 --> 00:22:31.950
And that it can only discover by, by having that kind of connection with users.
00:22:32.049 --> 00:22:53.059
And that's why, I guess, developer experience team like developers that are specialized in a framework like in, in not I'm, I'm not saying like in react, I'm saying in next, a person that is specialized in next or in Gadsby or next will, will allow you to find these kind of things and to solve a M and these little annoying things is what's taking time from developers.
00:22:53.160 --> 00:23:02.779
If you want people to be quick into implementing your API, your solution, then you need to kind of get solve these little annoying things because they are time consuming.
00:23:02.779 --> 00:23:11.490
And they so hard because you need to search on stack over flow and the other, and find the solution in the forum that doesn apply, because the version has upgraded.
00:23:11.960 --> 00:23:20.950
It's a huge headache for, for, for winning list little, and that's not motivating because you're spending like hours for, for, for advancing this step.
00:23:21.609 --> 00:23:32.819
So you can capture these, solve them by having someone that is listening all the time, that the users and making sure that these are souls, because they could be actually really low cost, big wins.
00:23:32.960 --> 00:23:34.900
If you get that kind of flow, uh, going,
00:23:35.440 --> 00:23:38.180
That's actually an excellent segue to my next question.
00:23:38.359 --> 00:23:51.119
You're talking about like those specific ecosystems, and I know Arun, you have a, a lot of knowledge around that, you know, how a single SDK or integration or whatever can easily become a whole project, right?
00:23:51.230 --> 00:23:55.599
With its own problems on top of the API that you are catering to.
00:23:55.859 --> 00:24:05.549
So for example, whenever you are building something for a view or for react automatically, you have SSR service side rendering, which become a topic.
00:24:06.210 --> 00:24:13.069
It hasn't anything to do with search per se or content per se, but it's a problem that belongs to this ecosystem.
00:24:13.250 --> 00:24:20.390
It doesn't exist necessarily when you are indexing content or sending content, but it exists in react when you're rendering something.
00:24:20.930 --> 00:24:27.059
And so you are building new things and they come with their new problems that you're solving for others.
00:24:27.319 --> 00:24:32.220
But that adds also to your load as the maintainer of that, that solution.
00:24:32.920 --> 00:24:41.579
And so I'd love to know from your experience, what are the common pitfalls that you should avoid when you're building an integration?
00:24:42.940 --> 00:24:48.049
I think a common pitfall is building an integration is making stuff.
00:24:48.750 --> 00:24:51.650
The code itself to start with is very easy.
00:24:52.230 --> 00:24:58.650
And it's essentially just, I made an application and you take the code and you put it in its own place.
00:24:59.269 --> 00:25:03.809
But from then onwards, as you just mentioned, the code exists, you need to maintain it.
00:25:03.829 --> 00:25:11.519
So I think a lot to solve with that is managing expectations is saying like, look, you can use this, but I just wrote the code.
00:25:11.920 --> 00:25:14.359
I didn't really test it in production yet.
00:25:14.500 --> 00:25:23.039
And I think that's okay for a lot of small things, because you can gauge how much interest there is in a certain solution, just like, go quick, do it.
00:25:23.819 --> 00:25:31.190
And then at a certain point, you'll notice that are spending quite a lot of time on it or that a lot the people are using it.
00:25:31.990 --> 00:25:39.910
I think at that point you can, um, you can refactor and then make things a little, little different, make things easier.
00:25:42.000 --> 00:25:56.900
And yeah, I think we, we, we said that before, but, uh, the more you wrap stuff, the, the less you expose of the original framework, the harder it is to work around edge cases.
00:25:57.220 --> 00:26:06.619
I think what you want to do is something that, especially if that's not like your main number one focus is to make it very easy for people to solve their own problems.
00:26:06.839 --> 00:26:07.740
You can help them.
00:26:07.839 --> 00:26:09.410
And over time, see the problem.
00:26:09.480 --> 00:26:15.450
Many times you can start by writing a guide or even just fixing it all together for, let's say SSR.
00:26:15.559 --> 00:26:23.690
It's a very tough balance to strike, to both still expose everything that needs to be exposed, but not make super complicated API.
00:26:23.691 --> 00:26:24.849
That solves nothing.
00:26:25.079 --> 00:26:26.769
It's probably one of the hardest problems.
00:26:27.200 --> 00:26:30.640
This comes as a good advice for even us as a company.
00:26:31.440 --> 00:26:39.799
Cuz you know, Sarah, when you ask the question inside the question, I read it maybe differently or maybe this is how you see it, but there are so many opportunities.
00:26:39.800 --> 00:26:41.720
This is the thing it's hard to say.
00:26:41.859 --> 00:26:45.359
No, it's, it's very hard to say no, Sarah cyber rendering, great.
00:26:45.910 --> 00:26:46.200
Okay.
00:26:46.299 --> 00:26:47.079
An opportunity.
00:26:47.080 --> 00:26:48.240
That means an opportunity.
00:26:48.240 --> 00:26:50.279
That means we can do things better, right?
00:26:50.819 --> 00:26:52.759
Or image optimization.
00:26:52.940 --> 00:26:54.160
That's a great opportunity.
00:26:54.259 --> 00:26:55.400
We want to jump into it.
00:26:55.420 --> 00:26:57.839
We want to solve it now, can we solve it and be better?
00:26:57.890 --> 00:26:59.640
Daniella's but that's not.
00:26:59.839 --> 00:27:04.910
If enough, imagine we solve the problem and you know, our solution is better, their people's habit.
00:27:05.730 --> 00:27:10.869
So even if we solve it better than the others, will people be ready to change their habits?
00:27:11.009 --> 00:27:13.910
Are they having enough pain there to change their habits?
00:27:14.589 --> 00:27:21.349
Uh, so sometimes it sounds like, look like we, we, we looked at image optimization, okay.
00:27:21.351 --> 00:27:28.619
And we said like, okay, this is an important problem for content writers or for content teams for our websites, you know, web apps that have content.
00:27:28.960 --> 00:27:30.539
We said, okay, we will have a functionality.
00:27:30.819 --> 00:27:33.779
We can define different sizes of images and we will serve all of that.
00:27:33.780 --> 00:27:40.099
So that in the interface you'll be able to say like, okay, this size, that size, that size, you know, different sizes for different devices.
00:27:40.160 --> 00:27:41.619
And then you will be able to solve it.
00:27:41.849 --> 00:27:42.299
It's good.
00:27:42.559 --> 00:27:51.930
And you can manage it of from the interface it's nice and all, but at the same time, there's something that emerg in the image API or image pipelines, they call, there are different names for this.
00:27:52.769 --> 00:28:01.809
Um, where, you know, as a developer, in the link of the, of the, of, of the image, you can add parameters of the size and the resolution.
00:28:01.990 --> 00:28:06.960
And lot of other things like there are, you know, today images, our, our partner does it.
00:28:07.680 --> 00:28:13.039
Um, we provide out the box, but there are cloud area and a lot of others that provide it as a service.
00:28:13.259 --> 00:28:16.319
Now our first way of solving the problem could be good.
00:28:16.329 --> 00:28:19.000
Could be maybe better even, but does it matter?
00:28:19.259 --> 00:28:24.480
People took some kind of habit and this habit is like success.
00:28:24.750 --> 00:28:28.670
Well, and we had to make a decision like, okay, well people want to use that.
00:28:28.819 --> 00:28:31.190
They have the habit, we couldn't change their habit.
00:28:31.650 --> 00:28:34.069
And especially this seems to be working well.
00:28:34.289 --> 00:28:42.910
So we chose to kind of, uh, against our own feature to go and partner with, with images in that kind of case and say, okay, let's, let's give them that.
00:28:43.220 --> 00:28:43.509
Okay.
00:28:43.510 --> 00:28:45.700
Let's give them exactly what they want all out of the box.
00:28:45.920 --> 00:28:51.059
Any image, any image that comes from SMIC you have, you can put these kind of parameters in that's.
00:28:51.059 --> 00:28:51.619
That's nice.
00:28:51.779 --> 00:28:54.900
And all now you you're talking about the pitfalls.
00:28:54.930 --> 00:28:56.779
Well, here, the pitfall was okay.
00:28:56.819 --> 00:28:57.900
I want to solve it myself.
00:28:58.329 --> 00:28:58.619
Okay.
00:28:58.621 --> 00:29:00.740
Because it sounds like you're doing a platform.
00:29:01.140 --> 00:29:02.940
Its like, okay, I want to solve problems.
00:29:03.000 --> 00:29:04.859
And I want to solve this problem as well.
00:29:05.279 --> 00:29:08.849
And we had our solution, but the community was going in any way.
00:29:09.279 --> 00:29:12.009
That was not exactly aligned with this one.
00:29:12.269 --> 00:29:14.690
So the most important thing is like, listen to these people.
00:29:14.691 --> 00:29:15.809
What they, they want to do.
00:29:15.810 --> 00:29:16.769
Innovation is good.
00:29:17.269 --> 00:29:22.369
But innovation is hard for one main reason is that the timing is hard in innovation.
00:29:22.839 --> 00:29:29.720
Like it's easier, uh, to find a solution and say like, okay, is solving it really, really good, but how can you make people change habits?
00:29:29.721 --> 00:29:30.519
They need to be ready.
00:29:31.059 --> 00:29:34.559
So if you are too early in innovation, it doesn't matter.
00:29:34.710 --> 00:29:35.599
It's not going to happen.
00:29:35.660 --> 00:29:37.359
If you're too late, it's not going to happen.
00:29:37.500 --> 00:29:38.440
The timing is hard.
00:29:38.579 --> 00:29:41.799
So if you find something that has the good timing, just try it on the timing.
00:29:42.900 --> 00:29:43.359
No problem.
00:29:43.539 --> 00:29:45.279
You're wrong, you right or wrong.
00:29:45.280 --> 00:29:45.839
Who cares?
00:29:46.019 --> 00:29:48.359
If, if your solution is the best or not, no one cares.
00:29:48.599 --> 00:29:51.039
Actually the industry wants a solution that is efficient.
00:29:51.180 --> 00:29:53.640
And that is, you know, you don't have to learn a lot.
00:29:53.859 --> 00:29:55.880
So if people are ready, maybe your solution will be good.
00:29:55.980 --> 00:30:02.789
If your solution is not ready well, right on, on the other solution, if it's good enough and this is what we did and we had a lot of success with it.
00:30:03.190 --> 00:30:10.349
I, I think this is one of them is like you would end up every time wanting to solve the problem by your own, but be ready to abandon.
00:30:10.500 --> 00:30:15.630
It's good to have innovation mindset and try to suggest yourself if you have the bandwidth with it.
00:30:16.349 --> 00:30:20.470
There's the question of focus because you have as a product company, you have so many things to solve.
00:30:21.119 --> 00:30:26.220
So provided that you have the bandwidth for it, try it, but make sure that you fail quickly.
00:30:26.450 --> 00:30:28.259
Like, okay, this is not good.
00:30:28.609 --> 00:30:30.740
It's clear that we are not going that direction.
00:30:30.950 --> 00:30:37.059
Let's find an alternative and it's okay, don't be too much attached to your innovation, to your ideas.
00:30:37.170 --> 00:30:37.900
Just that's it.
00:30:38.160 --> 00:30:38.619
No problem.
00:30:39.000 --> 00:30:44.369
We move to the right thing that people, people are and people have already the habit, uh, for
00:30:44.920 --> 00:30:57.369
Your answer actually gives me a good opportunity to go back to something that we mentioned earlier that you remember when we're talking about escape hatches and making sure that you let people get out of your integration if they need it.
00:30:57.670 --> 00:31:08.400
One thing I've noticed whenever I use a service is that the more layers of abstractions you have around the primitive API, the more opinions go into it, right?
00:31:08.500 --> 00:31:15.039
So whenever I'm using the, like let's say the HTP rest API, I'm using that directly.
00:31:15.160 --> 00:31:19.799
I will have a lot more freedom, uh, a lot more power, but it's also more risks.
00:31:20.420 --> 00:31:24.990
And when I'm using the SDK than it's like, I can start a lot faster.
00:31:25.650 --> 00:31:29.910
But sometimes there are things that will be harder to do.
00:31:29.911 --> 00:31:36.029
Like it controls really like draws the path for me and sometimes it can be harder to get out.
00:31:36.030 --> 00:31:42.910
And so we discuss that there is a balance to strike between, you know, the power and preventing people from making mistakes.
00:31:43.329 --> 00:31:54.779
They cannot recover from I'd love to know based on those principles and based on the fact that we make mistakes, as you just said, and sometimes we fail at nailing the right abstraction and it's time to decide and to make a change.
00:31:55.089 --> 00:32:05.970
What, in your opinion, and based on your experience, building such integrations, what makes an integration successful and maybe conversely, what would be the red flags telling you?
00:32:06.160 --> 00:32:07.809
Okay, it's time to make a change.
00:32:07.900 --> 00:32:30.720
Maybe it's time, even for a major version, which is kind of a big decision because you're asking people to care about your service while they care about their app and not your service specifically, what would be for you signs that the abstraction that you've designed is succeeding with customers and red flags telling you, okay, maybe we need to change something.
00:32:32.200 --> 00:32:38.599
I think it's important to have a lot of metrics around the usage of what you make.
00:32:39.180 --> 00:32:57.519
If you make integrations, make sure to tag them in some way, we use a user agent so that even afterwards we can just look and say, oh, this has X percentage of usage or this thing that we spend some time on, literally three people are using it.
00:32:57.819 --> 00:32:58.789
How can it be worked?
00:32:59.029 --> 00:33:00.630
It, I think that's that's one way.
00:33:01.150 --> 00:33:07.390
And, and another thing that you mentioned as well is, um, it can be dangerous to have major versions.
00:33:07.710 --> 00:33:08.549
I think that's true.
00:33:08.569 --> 00:33:12.950
But I think also that the fear sometimes is overblown.
00:33:13.529 --> 00:33:17.349
It is only dangerous to have major versions when you have a lot of users.
00:33:18.509 --> 00:33:28.940
Um, and when you only want to have like one thing to support, obviously when you have one thing to support that there's less work.
00:33:29.000 --> 00:33:34.859
People don't have to do it, but you should also make sure that people who are happy and don't want to change anything.
00:33:34.861 --> 00:33:45.200
They really don't have to, like, you can have major versions, but we, for example, have never deprecated anything.
00:33:46.119 --> 00:34:02.230
And uh, like literally you can't use it anymore in the API and the lowest level, even old parameters that we've renamed because to name was really bad and the new one is way better and explains everything better.
00:34:02.380 --> 00:34:10.349
That doesn't mean that you can't today still use a name that was decided in 2012, even though we changed it in 2014.
00:34:10.769 --> 00:34:12.670
And I think that's something very important.
00:34:12.820 --> 00:34:15.230
Like why are you afraid of a major version?
00:34:15.289 --> 00:34:21.179
Is it because you think people aren't going to update is that maybe cuz your update kit isn't good to enough.
00:34:21.400 --> 00:34:28.579
Is that maybe because it is just too hard to update or is it cuz they have no need to, if they have no need to, there's nothing wrong with it.
00:34:28.650 --> 00:34:33.139
They can stay on the oldest version that they made their application originally on.
00:34:33.519 --> 00:34:34.940
If they're happy with it, it's fine.
00:34:34.960 --> 00:34:35.340
For me,
00:34:36.119 --> 00:34:37.619
The question is, is pretty simple.
00:34:38.079 --> 00:34:40.139
The answer is really complex as usual.
00:34:40.280 --> 00:34:45.289
And I would like so much to give some kind of advice so that I look like the person that knows everything.
00:34:45.690 --> 00:34:46.889
I don't, I don't know.
00:34:47.489 --> 00:34:58.050
I mean, I can tell what happened with us and you know, maybe they will serve for a lesson for someone or you know, at least not to do the same mistakes again, there's so many thing ways to look at it, but let me give you an example.
00:34:58.199 --> 00:34:58.489
Okay.
00:34:58.490 --> 00:35:09.760
Like, and, and there's something that we didn't touch on and I so much wanted have some time in it, but now I know that we don't have the time in it, the SDK integration, which is an, a, some kind of API, you know, library.
00:35:10.019 --> 00:35:14.320
And then you, you know, talk to the API, but through the library, JavaScript library or something like that.
00:35:14.320 --> 00:35:24.469
But there is another approach that is really getting very, very interesting actually is the component level abstraction as in for your image, use this component, okay.
00:35:24.650 --> 00:35:28.670
Use the component, the component image in next or in, uh, next.
00:35:29.210 --> 00:35:32.789
And then it will do the proper API calls and you will give it a provider.
00:35:32.929 --> 00:35:41.199
So it can be, and this gives you a good abstraction so that you can change also providers, like you can jump from cloudy to MES to anyone else or to a server on your own.
00:35:41.440 --> 00:35:48.320
And that's a nice abstraction so that you just throw this component and you give it the past to your image and that's it you're done.
00:35:48.460 --> 00:35:50.360
And then everything is else is managed for you.
00:35:50.360 --> 00:35:58.070
So this another level I talked about this layers like API SDK, and then you have also the, the component level, which is a very cool abstraction.
00:35:58.070 --> 00:36:00.469
And we are working a lot on this on PRIs.
00:36:00.489 --> 00:36:05.590
We have a component called slide zone that will, uh, go and initiate all the slices, whatever it is.
00:36:05.650 --> 00:36:14.909
If you look at, at how things developed with, for instance, Gadsby, they, they provide in the beginning, some kind of job that will go through all the images that exist in, in the app.
00:36:15.289 --> 00:36:18.619
And they will do it at bill time and they'll resize them and optimize them.
00:36:18.621 --> 00:36:19.260
That was nice.
00:36:19.280 --> 00:36:22.739
But as an abstraction to my eyes, it wasn't a good abstraction.
00:36:23.000 --> 00:36:29.019
It was more focused on the, how than the, the why, what you, the, what, what you're doing exactly.
00:36:29.480 --> 00:36:34.219
So what you were doing, you were providing an image and you know, you wanted that image to be optimized.
00:36:34.679 --> 00:36:36.500
You didn't want to know that it's a build time.
00:36:36.501 --> 00:36:40.289
You didn't want to soft at the build time of like doing that generation.
00:36:40.469 --> 00:36:50.929
And then next and next came with this component, the image component where that's a better abstraction because you have to give it a, a URL or the past to the image.
00:36:51.230 --> 00:36:53.010
And then you tell it, this is my provider.
00:36:53.400 --> 00:36:58.920
Your provider could be a server on local host, or it could be some, uh, cloud service.
00:36:59.219 --> 00:37:00.000
It doesn't matter.
00:37:00.380 --> 00:37:02.280
The component will do it right now.
00:37:02.449 --> 00:37:07.400
Maybe it just because Gadsby went through that way, it inspired a better abstraction.
00:37:07.710 --> 00:37:09.480
Most probably this is the case, right?
00:37:09.539 --> 00:37:12.920
It started with like, we need absolutely to manage this for users.
00:37:13.099 --> 00:37:14.039
And then, okay.
00:37:14.380 --> 00:37:16.199
The others say like, how can we make it better?
00:37:16.619 --> 00:37:17.639
So it's always progress.
00:37:17.739 --> 00:37:23.309
If you are going into that kind of process, you need to look at the, at the decisions that you made and say like that was wrong.
00:37:23.730 --> 00:37:36.590
So it always boils down to, to say like, am I ready to face my decisions and to understand whether they were right or wrong and abandon something, an effort that I did, this is very hard.
00:37:36.590 --> 00:37:37.710
Like, it's a typical thing.
00:37:37.710 --> 00:37:42.940
When you go out, if your home and you don't have the keys, you so much want, don't want to return to home.
00:37:43.440 --> 00:37:45.420
And you know, you don't want to go the way back.
00:37:45.730 --> 00:37:57.860
Once you go one, one way, you don't want to go the way back, but I make it a, an exercise for myself every time I have to go and regret the effort or, or at least look at the effort that I did and, and go, and it's okay.
00:37:57.929 --> 00:38:00.210
It's okay to abandon an effort or your question.
00:38:00.389 --> 00:38:08.010
If I look at it from different perspective, are you talking about the user or are, are you talking about the producer for me as a producer of, of the service?
00:38:08.610 --> 00:38:09.289
I have two options.
00:38:09.519 --> 00:38:09.809
Okay.
00:38:10.190 --> 00:38:14.250
Am I optimizing for new people or am I optimizing for existing people?
00:38:14.449 --> 00:38:14.969
I have to choose.
00:38:15.130 --> 00:38:16.130
I have to make a decision.
00:38:16.329 --> 00:38:19.210
I have to make a choice or the universe will do it for me.
00:38:19.469 --> 00:38:31.239
So what is the choice that I'm going to do if I'm optimizing for new users, as in, I see more potential in the market and the new coming users than the existing ones, then I will try to change the abstraction to make it better and better.
00:38:31.500 --> 00:38:33.719
And I will try to manage as much as I can.
00:38:33.780 --> 00:38:41.239
The existing provided there is risk in the existing that they will leave because if they keep suffering from, from my API, they will do, but I have a focus.
00:38:41.480 --> 00:38:43.519
I know what is my number one priority.
00:38:43.900 --> 00:38:52.159
And the others I will manage or the other way around it could be that I, I so much, it's more important for me, existing market, existing user.
00:38:52.400 --> 00:38:54.079
And it depends maybe also on the phase of the company.
00:38:54.530 --> 00:38:56.630
So it can be very different, uh, okay.
00:38:56.989 --> 00:38:57.469
Existing ones.
00:38:57.769 --> 00:39:10.190
And then, uh, I want to slowly get it better because like, I want to get to the, the, you know, instead of the art on the market, but I'm not going full innovation that because I'm not going for new market, I could be both ways.
00:39:10.190 --> 00:39:10.389
Right.
00:39:10.949 --> 00:39:15.980
Uh, some, some will say like 50, 50, but that's just not willing to take the decision, need to take a decision.
00:39:16.480 --> 00:39:23.420
And then for instance, for us, we're try and say, okay, we think that we still not yet at the place where we want to be.
00:39:23.719 --> 00:39:30.659
As in, in the simplicity of integrating content and building websites, we think we can do better for, for helping people building websites.
00:39:30.661 --> 00:39:32.659
That's why we're, we're still out for innovation.
00:39:32.760 --> 00:39:34.420
And we're trying to change things very quickly.
00:39:35.050 --> 00:39:35.340
Okay.
00:39:35.530 --> 00:39:36.889
But we know that this has a price.
00:39:37.230 --> 00:39:42.329
So what we do is that everything that is related to migration, we try to take care of it ourselves.
00:39:42.789 --> 00:39:49.329
Now, how now, the first thing that, uh, har talked about is like, you shouldn't understand who uses what so that you understand.
00:39:49.331 --> 00:39:50.050
What's the impact.
00:39:50.050 --> 00:39:51.170
That's a very important thing.
00:39:51.170 --> 00:39:55.449
But the second thing is like, can we MI do the migration for our users without mistakes?
00:39:55.590 --> 00:39:56.599
How can we do that?
00:39:56.601 --> 00:40:01.679
Well, first, if we own their data, then I mean, if we host it, then we can do the migration, maybe for them.
00:40:01.780 --> 00:40:02.599
That's first thing.
00:40:02.940 --> 00:40:06.559
The other thing is like, we run our migrations on, on live data.
00:40:06.980 --> 00:40:11.039
So basically we have shadow servers where we say, okay, now we are doing the migrations.
00:40:11.059 --> 00:40:11.800
We migrate data.
00:40:11.900 --> 00:40:15.360
And we do shadow requests so that we see, okay, is the response still the same?
00:40:15.360 --> 00:40:21.789
And we, we can do it this for like a week, a two weeks for, for like, um, millions of requests.
00:40:21.929 --> 00:40:23.789
And then we see like, okay, we didn't break anything.
00:40:23.849 --> 00:40:24.789
Now we can roll it out.
00:40:24.791 --> 00:40:25.030
Right.
00:40:25.289 --> 00:40:33.349
So you can have processes for doing migration, but you're choosing to do migrations, but you're saying, okay, I'm taking, trying to take care of the migration myself.
00:40:33.610 --> 00:40:36.309
So that user doesn't suffer, uh, of that.
00:40:36.610 --> 00:40:41.420
But you get decision in the beginning that I want to innovate and, and push innovation is going to change stuff.
00:40:41.449 --> 00:40:43.460
It's a lot of decisions on first.
00:40:43.460 --> 00:40:44.820
What do I want to optimize?
00:40:45.079 --> 00:40:46.260
And second, okay.
00:40:46.480 --> 00:40:48.900
How can I make it not painful for my existing users?
00:40:48.900 --> 00:40:51.940
Because the one, they are the one they trusted us, they are the one that brought us here.
00:40:51.940 --> 00:40:55.139
How can I make sure that it, it doesn't become a pain for them.
00:40:55.880 --> 00:41:02.530
And the fact that we don't don't migrate them, it's a pain, it's a pain that is going to surface afterwards.
00:41:02.710 --> 00:41:03.289
We know it.
00:41:03.400 --> 00:41:12.570
They don't know it yet, but if we don't help them in the migration being up to date with their data, then at some point they're going to suffer because they will be the old approach.
00:41:12.570 --> 00:41:12.889
Right.
00:41:13.150 --> 00:41:14.489
So we need to keep them up to date.
00:41:14.590 --> 00:41:16.929
So for me, it's like, we should not ignore it.
00:41:16.931 --> 00:41:23.360
We should not like, look the other way and then say, okay, we will keep two versions of the API, or I don't know what, that's a bad thing.
00:41:23.380 --> 00:41:26.559
You know, you need to face it and say like, okay, how can we migrate that?
00:41:26.561 --> 00:41:29.159
So we try to take migration by, you know, on our own.
00:41:29.161 --> 00:41:33.039
We try to test on, on, on real data and, and still all of that.
00:41:33.119 --> 00:41:35.719
We still have places where we need to put guides.
00:41:35.949 --> 00:41:36.239
Okay.
00:41:36.739 --> 00:41:44.480
But for that, you know, what we choose to do is to have like a high availability on our service, on our people that will help them into the migration process.
00:41:44.539 --> 00:41:53.710
And we give them the time to do it so that they, they benefit from the new stuff because innovation will bring them a lot of good also for existing users.
00:41:54.190 --> 00:41:58.349
We, they need to understand why and why should they should dedicate time for it.
00:41:58.690 --> 00:42:10.510
That's super interesting said, and you know what, as much as I would love to stay the entire afternoon, talking about that, we need to wrap this up at some point, where can people go to find you online?
00:42:11.190 --> 00:42:11.989
Uh, you can, okay.
00:42:12.079 --> 00:42:14.460
There is press me IO.
00:42:14.659 --> 00:42:18.260
So P R I S M I c.io.
00:42:18.960 --> 00:42:19.539
And I'm sad.
00:42:19.739 --> 00:42:20.460
I I'm on Twitter.
00:42:20.860 --> 00:42:23.940
S S a D a C H E.
00:42:24.300 --> 00:42:27.940
I don't tweet much, but you know, from time to time, you can
00:42:27.940 --> 00:42:29.019
Follow on Twitter.
00:42:29.199 --> 00:42:32.739
My account is har V for my last name.
00:42:33.300 --> 00:42:35.769
Uh, H a R O E N V.
00:42:36.769 --> 00:42:45.210
And you can find me on Twitter at front stuff on school IO or on my side, Saha Saha with an h.com.
00:42:46.489 --> 00:42:49.449
Sadek a thank you so much for chatting with me today.
00:42:49.469 --> 00:42:52.050
It was extremely interesting listeners.
00:42:52.449 --> 00:43:02.800
I hope you had a blaster, all things, API clients and integrations and UI libraries and API design went so much further than what initially anticipated.
00:43:02.860 --> 00:43:04.079
And that's the beauty of it.
00:43:04.081 --> 00:43:09.440
Thanks a lot for following developer experience and stay tuned for the next episode.
00:43:10.349 --> 00:43:14.480
This was developer experience, a podcast brought to you by Algolia.
00:43:15.210 --> 00:43:18.190
You can find this podcast on your favorite podcast platform.
00:43:18.650 --> 00:43:25.190
We are on Spotify, apple podcast, Google podcast, Pandora, overcast, everywhere.
00:43:25.849 --> 00:43:32.789
If you want to know more about Algolia check us out on algolia.com and we are at Algolia on Twitter.
