Blending in Other People’s Codebases - Sadek Drobi (Prismic)

In this episode, Sarah Dayan chats with not only one, but two guests:
- Sadek Drobi, Founder and CEO at Prismic
- Haroen Viaene, Javascript Library Developer at Algolia

They chat about what it takes for a technical product to blend into other people's codebases. How do you ensure that developers want to put your code in their code? Why is it as important to offer idiomatic integrations as it is to build powerful APIs? Sarah, Sadek and Haroen answer these questions in this third episode of Developer Experience.

Prismic is one of the leading headless CMS solutions, and Sadek was one of the founding architects of the Prismic API. He now leads a growing team who build and maintain a dozen integrations on top of it. Haroen has been working for years on many of Algolia's integrations, and is the craftsmen behind the search experience of Yarn. 

• Sadek Drobi: @Sadache
• Haroen Viaene: @haroenv / haroen.me
• Sarah Dayan: @frontstuff_io / sarahdayan.dev
• Algolia: @algolia / algolia.com
• Prismic: @prismicio / prismic.io

Transcript

Sadek Drobi: 0:00

You would end up every time wanting to solve the problem by your own, but be ready to abandon. It's good to have innovation mindset and try to suggest yourself if you have the bandwidth with it. There's the question of focus because you have as a product company, you have so many things to solve. So provide it that you have the bandwidth for it, try it, but make sure that you quickly like, okay, this is not good. It's clear that we are not going that direction. Let's find an alternative and it's okay. Don't be too much attached to your innovation and to your ideas. Just that's it. No problem. We move to the right thing that people people are using and people have already habit for

Sarah Dayan: 0:40

How you, everyone, and welcome to developer experience a podcast by Golia. We chat with guests who build products for developers about their developer experience, strategy, what it means for them, why it's important. And so on. My name is Saha young. 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. How do you ensure that developers want to put your code in their code? Why is it as important to offer idiomatic integrations as it is to build powerful APIs? Lucky for me, I have two guests who have looked at these questions from a fair number of angles. Sad is the founder and CEO of Prismic. One of the leading headless CMS solutions out there. 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. Hi SEK.

Sadek Drobi: 1:46

Hello. Thank you for having me.

Sarah Dayan: 1:48

Our second guest is one of our own Harun. BI is a software engineer at Algolia for years. 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. He's also the craftsman behind the search experience of yarn. Hello, Aun.

Speaker 3: 2:15

Hello. Nice to meet you again.

Sarah Dayan: 2:17

Let's get started. Shall we? 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. Why is it no longer enough to just build really good, low level APIs?

Sadek Drobi: 2:40

But there are a lot of very, uh, tough decisions you have to do in the market. I mean, the market is moving so so quickly you call them technical products. There are so many choices nowadays, but you know, the whole thing it started with with APIs, right? It was the first abstraction. We always have to talk about abstractions. And the fair decision that you have to think about is that, okay, I have my software, right? I have, I'm doing a website, an app, whatever it is that I'm doing, and I need to integrate parts of it. And I don't want to develop these parts. It comes all from, from this first thing, right? I don't want to develop everything. Like I need to search. I don't want to go and develop the whole search. I mean, it's fine. 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. Like for instance, we have a, one of our clients, they do, uh, like, like made.com, right? And they, they always tell like, look, the search is not exactly our domain. Our domain is somewhere else. Okay. So we want to be the state of the art of different comp other components. But then we want to make the difference in one place. This is why they will take maybe Algolia for a search. They will take, maybe take maybe Prismic for, you know, their content. And so and so on and so on. 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. How can I do that? Um, there's so many ways to do that. But the first abstraction was like, okay, call an API. And this way you have the abstraction, at least your servers, you're not managing the servers. The servers are managed by someone else. You don't have to care about it. You tell it, give me an environment. I give you an environment and that's it. So all the complexity is hidden and you have so many options. It allows you right to scale. It allows you to improve performance. It allows you to do a lot of things. So you give you options, but it's one abstraction there, the API. 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. When I have to deal about performance. I know that at solution will bring me all this stuff. When I care about scalability, it will gimme all the options, but my abstraction in the API. So I think it all started by this and it's a very good abstraction. So it's, we should not kind of neglect that kind of basis and go jump into other things in my view. And this is how we develop things in Prismic. We should lay foundation over foundation in. If we don't have the right foundation at the API, we can start getting to another level of obstruction. I don't know what har you, you think about it. Do you have any comment? Yeah,

Speaker 3: 5:10

That's uh, that's, that's very important thing to talk about these different foundations. What I've noticed is that most of these different layers, they form very naturally over time. Like you will start indeed by making an as good as possible way to retrieve certain information. And in almost all cases, that will start being in normal HT P API. 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. So there's this thing called simple requests. 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. That's not of like a super limited standard set of headers at Algolia. We care a lot about performance. And one downside of having a course request is this actually does two network requests for your first call. And, you know, that could be up to a couple hundred milliseconds in the first case, it's just pretty annoying. 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. 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. 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. But I think this analogy goes for every problem that you try to solve for customers.

Sadek Drobi: 7:03

I like how you build it. Like for instance, you can go and document things, right? 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. If it works enough, then they will not need even to go into documentation because you know, you take care of it. And you know, we have to explore a lot of layers. Like we started with the API, right? 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. I document it. If people want to do it for another technology, they can do it. And, and there's so many things to explore there. Uh, but we'll explore these kind of things, but I will stop, uh, still on the API side. 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. It's a technical word, right? As like, imagine someone today tells you, I want to do an interface. Yeah. That doesn't give much information. Like, okay, thank you. Like you want to do an interface for what exactly. So the API should look like the problem, what people want to achieve with the API. And this is a question that we get often like with Pring, like, oh, I want to do this. We want to write API, but write API doesn't mean much. Actually write what for what? 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. And you need to explore these topics before jumping into the solution. Now, of course there are two school. 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. 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. It didn't exist for ages in iPhone. And I suppose this is completely I'm, I'm making things up here. Right. But I suppose the purpose was, why do people need copy paste? It's a generic solution to a lot of problems. Okay. But why do people need it? Some people need it simply to share with another app. As in, I have some text and I want to share it in slack, it's in my SMS or whatever it is. 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. Like I want to share something, but I want that to open in the app directly like a song. And then I click on the link and it opens Spotify right away. And then I have the song that's a completely different way of integration. Copy. Pasting was hiding all kinds of features, all kind of things that people wanted. 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. So API is the same. My, they are too two schools, two ways of doing it, but I'm more for like, okay, why do you need an API? Exactly. Okay. And, and there are a lot of good reasons for having an API, right? 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. And, and often you will find a solution that will solve 80% of the cases. And then you'll have an API that is not verbal. That goes right to the goal that they're trying to do. 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. Well, they will have it outta the box without, without even thinking of the concept, of course, or maybe thinking very little of it. So I like that kind of layered approach of solving problems the way you explain it.

Sarah Dayan: 11:18

So that's really interesting. 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. But you talked about a fact that you want to solve problems and solve mistakes that people often make. And that you also want to, for people not to have to think about it, which arguably you could do without an APA client. Right. 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. The first thing that comes to mind is that it needs to be idiomatic or right. It should feel natural in my code base. It should use the IDMs of my language. I don't want to have something in my code that fits that doesn't look like it belongs there, right. 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. Is it like the biggest seller? Is there more to it? Is there something very, very important that we are not, that can only be solved by, uh, a language specific framework, specific API clients?

Speaker 3: 13:00

I think what you're trying to do is solve certain problems. 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. And then maybe you need to check whether it's already updated and, and this kind of things. And this code done by users will quickly balloon. So this needs to be bundled up in some way. 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. There is not really a universal code language so that you only need to write it once. There's, I mean, it's been tried plenty of times, but it doesn't really work. There's just two, two different. So you, any code that you write automatically has an interface because it needs to be used. 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.

Sadek Drobi: 14:17

Let, let me start by saying, we are the champions of doing these kind of mistakes. Fri started well inside project and all as a, a scale thing, scale programming, language, the JVM and all of that. And like, we were like toed guys, you know, these strong type and all of these kind of things. 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. Right. 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. And you like the, the, you know, practices. And by, by, at the time, you know, uh, strongly statically types, programming languages were like really the, the fun thing to do. At some point, we realize that our API is not so easy to use in, for instance, JavaScript. 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. And I was like, okay, that's a problem, right? That's a problem. It's not easy to use people were using the product yet. I mean, we had something good out there, but the API wasn't one of them. So people was like, know, it's a weird API. We don't understand why it's written that way. And you know, it's a hassle to, to, to deal with. And that's where more than four years ago, we started with a lot, okay. We need to rewrite our API, like complete rewrite. 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. 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. So we had to change our API. That was a lot to learn, you know, at that very basic level of API rest API, you still have to return Aja zone. And Jayn the Jayn did you return? It should look like the language friendly with the language. Now, if it's for JavaScript, it needs to be simple. You need to access things easily. 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. I had my opinion about it. 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. So even at the APIs, uh, we're not even in the kit, you still have to make a decision. And it's easy to say like, oh, it's service APIs, a general go, go deal with it. But no, you aren't making a choice either you do it, or you let the universe do it for you. And if the universe do it well, it's random. And maybe it's good. Maybe it's not, but you have to make the choice. And we did the choice, like JavaScript is our target. So we, we want to do an API that is easier for the JavaScript word. Now it seems like one thing JavaScript, but is so big because JavaScript is react. It's view it's it's Gadsby's next. It's Knox. It's so many things today. So at the kit level, we had to do the same kind of effort. There is time where I used to work with Eric Meyer. Eric Meyer was one of the people that worked on different programming languages. And then he, he was so enthusiastic about exploring JavaScript. For some reason, I like, I like that fact of his, like really pragmatic on these kind of things. And he told me we should do leaky abstractions. And I was like, the, how come like abstraction should not be leaky. What you talking about? And he was like, no, people need to understand how things happen. If they break, they will know how to fix it. 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. 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. 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. 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. 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. And for that case, you're going to punish them and get them like, oh, go learn the whole thing. So it should be like a little bit have mechanisms that allow you to okay. Open that abstraction and, and hook it into it and do something about it.

Sarah Dayan: 18:51

Yeah. I think you're talking about escape hatches, right? 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. Hatches.

Speaker 3: 19:05

Yeah. That was a quote from, uh, Sunil PI. He wrote that the, of an abstraction can be measured in the quality of its escape patches. When you think about when things go wrong, that means you probably have talked about almost everything. And really when things go wrong, if you design that case first, then automatically the hard becomes much simpler. So if from the start you think about what if people don't like how I'm, let's say requesting the, the API. 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. I think that's very interesting. And, and another approach and something that you thought, uh, touched on earlier is that everything becomes much more, right? The moment that you decide to be simpler, the easier your end points are, the easier your returns are. The less work you'll have to do to make it work well. 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.

Sadek Drobi: 20:33

Yeah. Yeah. This is one of the things that we did instead wrapping the, the same API into another thing. Let's simplify the, the first API. And then maybe we can build things on top of it. I was in the camp of let's design things perfectly since the beginning, and then everything will work. And I, I kind of changed also with a lot of people that were, you know, around me and inspire me and do that. And also while facing problems, J Armstrong, he's one of the creators of Ang and all, all the thing. And he was like, you should not find failure. You should embrace failure. As in, he's more talking about history systems and how you need to accept failure. 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. You know, something happen exceptional. We call exceptions and stuff. It like, it's not exceptional. It's life. Failure is life. 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. Where it's going to fail is what we will understand in the coming months. 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. 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. 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. And that it can only discover by, by having that kind of connection with users. 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. 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. 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. 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. 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. If you get that kind of flow, uh, going,

Sarah Dayan: 23:35

That's actually an excellent segue to my next question. 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? With its own problems on top of the API that you are catering to. 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. It hasn't anything to do with search per se or content per se, but it's a problem that belongs to this ecosystem. It doesn't exist necessarily when you are indexing content or sending content, but it exists in react when you're rendering something. And so you are building new things and they come with their new problems that you're solving for others. But that adds also to your load as the maintainer of that, that solution. 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?

Speaker 3: 24:42

I think a common pitfall is building an integration is making stuff. The code itself to start with is very easy. And it's essentially just, I made an application and you take the code and you put it in its own place. But from then onwards, as you just mentioned, the code exists, you need to maintain it. 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. I didn't really test it in production yet. 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. 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. I think at that point you can, um, you can refactor and then make things a little, little different, make things easier. 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. 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. You can help them. And over time, see the problem. Many times you can start by writing a guide or even just fixing it all together for, let's say SSR. It's a very tough balance to strike, to both still expose everything that needs to be exposed, but not make super complicated API. That solves nothing. It's probably one of the hardest problems.

Sadek Drobi: 26:27

This comes as a good advice for even us as a company. 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. This is the thing it's hard to say. No, it's, it's very hard to say no, Sarah cyber rendering, great. Okay. An opportunity. That means an opportunity. That means we can do things better, right? Or image optimization. That's a great opportunity. We want to jump into it. We want to solve it now, can we solve it and be better? Daniella's but that's not. If enough, imagine we solve the problem and you know, our solution is better, their people's habit. So even if we solve it better than the others, will people be ready to change their habits? Are they having enough pain there to change their habits? Uh, so sometimes it sounds like, look like we, we, we looked at image optimization, okay. 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. We said, okay, we will have a functionality. We can define different sizes of images and we will serve all of that. 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. And then you will be able to solve it. It's good. 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. 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. And lot of other things like there are, you know, today images, our, our partner does it. Um, we provide out the box, but there are cloud area and a lot of others that provide it as a service. Now our first way of solving the problem could be good. Could be maybe better even, but does it matter? People took some kind of habit and this habit is like success. Well, and we had to make a decision like, okay, well people want to use that. They have the habit, we couldn't change their habit. And especially this seems to be working well. 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. Okay. Let's give them exactly what they want all out of the box. Any image, any image that comes from SMIC you have, you can put these kind of parameters in that's. That's nice. And all now you you're talking about the pitfalls. Well, here, the pitfall was okay. I want to solve it myself. Okay. Because it sounds like you're doing a platform. Its like, okay, I want to solve problems. And I want to solve this problem as well. And we had our solution, but the community was going in any way. That was not exactly aligned with this one. So the most important thing is like, listen to these people. What they, they want to do. Innovation is good. But innovation is hard for one main reason is that the timing is hard in innovation. 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? They need to be ready. So if you are too early in innovation, it doesn't matter. It's not going to happen. If you're too late, it's not going to happen. The timing is hard. So if you find something that has the good timing, just try it on the timing. No problem. You're wrong, you right or wrong. Who cares? If, if your solution is the best or not, no one cares. Actually the industry wants a solution that is efficient. And that is, you know, you don't have to learn a lot. So if people are ready, maybe your solution will be good. 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. 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. It's good to have innovation mindset and try to suggest yourself if you have the bandwidth with it. There's the question of focus because you have as a product company, you have so many things to solve. So provided that you have the bandwidth for it, try it, but make sure that you fail quickly. Like, okay, this is not good. It's clear that we are not going that direction. Let's find an alternative and it's okay, don't be too much attached to your innovation, to your ideas. Just that's it. No problem. We move to the right thing that people, people are and people have already the habit, uh, for

Sarah Dayan: 30:44

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. 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? So whenever I'm using the, like let's say the HTP rest API, I'm using that directly. I will have a lot more freedom, uh, a lot more power, but it's also more risks. And when I'm using the SDK than it's like, I can start a lot faster. But sometimes there are things that will be harder to do. Like it controls really like draws the path for me and sometimes it can be harder to get out. And so we discuss that there is a balance to strike between, you know, the power and preventing people from making mistakes. 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. 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? Okay, it's time to make a change. 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.

Speaker 3: 32:32

I think it's important to have a lot of metrics around the usage of what you make. 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. How can it be worked? It, I think that's that's one way. And, and another thing that you mentioned as well is, um, it can be dangerous to have major versions. I think that's true. But I think also that the fear sometimes is overblown. It is only dangerous to have major versions when you have a lot of users. 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. 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. They really don't have to, like, you can have major versions, but we, for example, have never deprecated anything. 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. 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. And I think that's something very important. Like why are you afraid of a major version? Is it because you think people aren't going to update is that maybe cuz your update kit isn't good to enough. 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. They can stay on the oldest version that they made their application originally on. If they're happy with it, it's fine. For me,

Sadek Drobi: 34:36

The question is, is pretty simple. The answer is really complex as usual. And I would like so much to give some kind of advice so that I look like the person that knows everything. I don't, I don't know. 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. Okay. 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. And then you, you know, talk to the API, but through the library, JavaScript library or something like that. 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. Use the component, the component image in next or in, uh, next. And then it will do the proper API calls and you will give it a provider. 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. 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. And then everything is else is managed for you. 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. And we are working a lot on this on PRIs. We have a component called slide zone that will, uh, go and initiate all the slices, whatever it is. 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. And they will do it at bill time and they'll resize them and optimize them. That was nice. But as an abstraction to my eyes, it wasn't a good abstraction. It was more focused on the, how than the, the why, what you, the, what, what you're doing exactly. So what you were doing, you were providing an image and you know, you wanted that image to be optimized. You didn't want to know that it's a build time. You didn't want to soft at the build time of like doing that generation. 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. And then you tell it, this is my provider. Your provider could be a server on local host, or it could be some, uh, cloud service. It doesn't matter. The component will do it right now. Maybe it just because Gadsby went through that way, it inspired a better abstraction. Most probably this is the case, right? It started with like, we need absolutely to manage this for users. And then, okay. The others say like, how can we make it better? So it's always progress. 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. 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. Like, it's a typical thing. 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. And you know, you don't want to go the way back. 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. It's okay to abandon an effort or your question. 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? I have two options. Okay. Am I optimizing for new people or am I optimizing for existing people? I have to choose. I have to make a decision. I have to make a choice or the universe will do it for me. 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. And I will try to manage as much as I can. 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. I know what is my number one priority. 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. And it depends maybe also on the phase of the company. So it can be very different, uh, okay. Existing ones. 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. Right. Uh, some, some will say like 50, 50, but that's just not willing to take the decision, need to take a decision. 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. As in, in the simplicity of integrating content and building websites, we think we can do better for, for helping people building websites. That's why we're, we're still out for innovation. And we're trying to change things very quickly. Okay. But we know that this has a price. So what we do is that everything that is related to migration, we try to take care of it ourselves. Now, how now, the first thing that, uh, har talked about is like, you shouldn't understand who uses what so that you understand. What's the impact. That's a very important thing. But the second thing is like, can we MI do the migration for our users without mistakes? How can we do that? Well, first, if we own their data, then I mean, if we host it, then we can do the migration, maybe for them. That's first thing. The other thing is like, we run our migrations on, on live data. So basically we have shadow servers where we say, okay, now we are doing the migrations. We migrate data. And we do shadow requests so that we see, okay, is the response still the same? And we, we can do it this for like a week, a two weeks for, for like, um, millions of requests. And then we see like, okay, we didn't break anything. Now we can roll it out. Right. 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. So that user doesn't suffer, uh, of that. But you get decision in the beginning that I want to innovate and, and push innovation is going to change stuff. It's a lot of decisions on first. What do I want to optimize? And second, okay. How can I make it not painful for my existing users? Because the one, they are the one they trusted us, they are the one that brought us here. How can I make sure that it, it doesn't become a pain for them. 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. We know it. 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. Right. So we need to keep them up to date. So for me, it's like, we should not ignore it. 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. You know, you need to face it and say like, okay, how can we migrate that? So we try to take migration by, you know, on our own. We try to test on, on, on real data and, and still all of that. We still have places where we need to put guides. Okay. 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. 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. We, they need to understand why and why should they should dedicate time for it.

Sarah Dayan: 41:58

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?

Sadek Drobi: 42:11

Uh, you can, okay. There is press me IO. So P R I S M I c.io. And I'm sad. I I'm on Twitter. S S a D a C H E. I don't tweet much, but you know, from time to time, you can

Speaker 3: 42:27

Follow on Twitter. My account is har V for my last name. Uh, H a R O E N V.

Sarah Dayan: 42:36

And you can find me on Twitter at front stuff on school IO or on my side, Saha Saha with an h.com. Sadek a thank you so much for chatting with me today. It was extremely interesting listeners. 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. And that's the beauty of it. Thanks a lot for following developer experience and stay tuned for the next episode. This was developer experience, a podcast brought to you by Algolia. You can find this podcast on your favorite podcast platform. We are on Spotify, apple podcast, Google podcast, Pandora, overcast, everywhere. If you want to know more about Algolia check us out on algolia.com and we are at Algolia on Twitter.