Alexei and me at the Enginears podcast

Jeroen Leenarts: This is a republication of an interview I did within the engineers podcast with a colleague of mine Alexa, I hope like if it gives a nice insight on the things that the people at stream Berko what a product is and what my role and what Alexis was in the entire situation. So enjoy and talk to you in another episode Elliot Kipling: ladies and gents, welcome back to another feature of engineers. Today we're joined by Sharon and Alexei from string. They're gonna give you some massively insightful pieces around the back end and mobile in particular iOS architecture, and what stream do is a business essentially, building API's and SDKs for chat messaging and activity feeds. But stay tuned, we're gonna go into that in a lot more detail. I chaps. Jeroen Leenarts: Hey, how you doing, Elliot? Cool. How are you? Good. But where do you want us to begin? Really, because there's a lot that we want to talk about, I think, Elliot Kipling: good shout. Why don't we give Oh, why don't we give the audience a bit of an intro into you your backgrounds, and help us understand you a little bit more, then let's get into the nuts and bolts of who stream are and what you do as a business. Then break down some of the components that we had a chat about before. kick us off. Jerome? Jeroen Leenarts: Who you Okay, yeah, my name is urine. I live in the Netherlands. I'm a software developer by trade. I've been doing that for like 20 years now. And last 10 years, I've been focusing on iOS development, I run my own podcast called App Force One. look it up online, if you're into iOS development, really nice. been doing that for like 170 episodes, I think. Cool. Yeah, of course, I work at stream. I'm the Lead iOS developer relations. So that basically means that I run the team of developer advocates, Delphi developer relations, engineers, within stream on the iOS platform. So we have like a focus group of people doing all kinds of iOS related content around the stream products. Sounds like it's like a gazillion people. But it's actually me and two others. So it's a team of three. And so we just try to get the word out on what what stream does what stream as a product can bring to you as a as a customer, how you should use it. Basically trying to drive engagement and based on that engagement, get people to look at our products really Elliot Kipling: love it. Good. At Force One. Did you say? Yeah, Jeroen Leenarts: a PP f o r C, E, and then the numeral one. Love it. Elliot Kipling: We'll have something in the links below for everyone to check that out as well. Alexei Kozlenok: Yeah, cool. Hey, so my name is Alexei, I'm a director of engineering at stream I've been programming for a long time now. So I've been in a few industries, worked in a few big companies. But here at stream, I work with the backend team. I'm the director there with a few teams under me that focus more on like distribution of data within the back end, doing the data models, making sure that we can handle as many users as possible without hiccuping or causing too many problems with the client. And, yeah, we solve those and tooling problems as well as feed the SDK as the urine was just talking about. That's Jeroen Leenarts: me. So I'm just to continue on what stream is we have like a really nice elevator pitch for that. So stream is the number one chat API for custom messaging apps, whether you're creating a social messaging app, a team collaboration platform, a live stream chat feature, or anything else you can come up with stream helps developers rapidly ship in app messaging with highly reliable chat infrastructure, and feature rich SDKs. You can improve your overall in app conversion engagement and retention in a fraction of the time it would take to build a solution in house. So that's what we do at stream. But there's a lot there's a lot of technical stuff happening to make that possible. Because this sounds really, you know, like slick and marketing. But as an engineering company ourselves, we'd really like to get into the get into the things ourselves and really help our customers hands on and really support them by participating in their in the code bases and seeing what challenges they face so that we can hopefully solve some of those for our customers. Yeah. So yeah, I'd say what are some of the biggest challenges that we're run into Alexei in regards to scaling, because we do scale it quite a bit, I think. Alexei Kozlenok: Yeah, so there's some interesting features inside of the platform that cause scaling issues. Sometimes you might have a situation where you have lots and lots and lots of different channels. So let's say you have lots of one on one channels like, you know, medical scenario, let's say it's a medical application. So in that instance, you have to be able to effectively distribute the users across lots of small disparate pieces of data. So you don't necessarily have that like colocation of data. And on the other side, you might have something like an event that has millions or hundreds of 1000s of people watching one thing and participating and engaging in that. And that has the opposite problem where you have one core like point of data that you might want to fan out and get to the users. So those kinds of problems are ones that we run into very often than we solve for our clients and customers. Jeroen Leenarts: And then on the client side of things, of course, you have iOS apps, Android apps, web applications, cross platform SDK is that you would want to be using as a customer of our platform, of course, all this scaling all this, basically, getting the capacity to do these chat features is on the back end. But of course, as a customer of stream, you want to be able to connect to the back end quickly. And that's where the SDK development teams come in. Because you can imagine that if you want to build a full fledged chat feature into your products, yeah, then there's a lot of things that you need to be doing and a lot of things that you need to do, right. But if you use one of our SDK specific to your platform, then you have a much easier time implementing a full fledged chat feature that has all the bells and whistles, all the features that end users come to expect from a chat implementation. So really, like just messages, DMS, making sure that you can post your GIF ease as well. And a whole bunch of other things that, that that you just want to have available in your chat implementation. And that's basically what we offer with our SDK is based on the amazing backend, that stream has been able to build out over the last couple of years. And just to give you an idea, for instance, for iOS, because that's my speciality, if you pick up our SDK, you sign up for an account, pretty much within a week, you can have a full fledged chat implementation live in your products on the App Store, going with potentially 10,000 100,000 Millions of end users really depends on the scale of your company. And that's, that's what we try to offer to our end users just a slick, clean, fast and reliable way to implement chat in your products. Nice. Okay. Elliot Kipling: Help us understand a little bit about the connection between back end and mobile, then, we haven't touched on this too much outside of the podcast. But help us understand that because I think that that relationship between you two, giving an intro on yourselves new positions within the business, that seems quite key for a really good customer experience. Jeroen Leenarts: I can try and answer that. And then Alexei can like jump in, if I miss something, or if there's a detail that I just don't know. And it all begins with, of course, the network connections, you can imagine that if you have a lot of clients, you have a lot of end users, you will be dealing with a lot of scaling on the back end, because you just need to have all those TCP connections active. What we use, there is WebSockets. Because that allows us to asynchronously communicate with our back end so that you don't have the typical HTTP request response cycles going on, which have quite a quite a lot of overhead. But by having a WebSocket connection on active clients to our backends, we're able to really scale out and scale up the number of NGOs that is actively connecting to our backends, you can imagine that there are some complexities that we need to take care of on the client side. Same goes for the server side. But basically, it comes down to when you activate our SDK, and you make your process your app active, we connect with your credentials to the stream backends get this WebSocket going. And then it's basically sent messages when we when we need to communicate something to the server and wait for any messages and information coming back from the server. And we've noticed that with WebSockets, the the amount of scaling that we can do, especially with the type of back end that we've implemented, because I think we use go Lang for that. We're able to really utilize all the virtual hardware, of course, because it's hosted by the cloud provider, but we're really able to saturate CPU and memory and basically only be limited by the amount of bandwidth that we need to consume to support these features, yeah, nice. Alexei Kozlenok: So to sort of build on top of that WebSockets are a core like performance improvement metric. And that metric, the performance improvement factor inside of the product. And it does allow for faster communication. We also have other kinds of RPC, we do have some REST endpoints. If your application is offline, and it gets, let's say, on a mobile and you're wearing a dead zone, and you come back, you do have the ability to do some RPC, once you get that connection back to sort of get yourself back up to speed. There's also some push communication that comes across from the backend, we have some services to provide the ability to get those updates to devices, whether that's through Firebase, or like through the iOS system itself, that depends on the platform where the SDK is running. But that is configurable and available for the clients as well. So there's different ways to get that communication there. And we even have some backend SDKs, and the ability to communicate with services if you have your own back end. So most often, this is used for things like customer authentication schemes, so you might have your own authentication scheme that you're very comfortable with, then you want to integrate stream. Obviously, you don't want people to log into stream every single time you want them to log into your app. So there's ways for your back end services to talk and collect data from stream itself, as well as dashboard and other metrics that might come from stream that might be interacted with through a non SDK way. Right. So Elliot Kipling: okay, seems like the relationship is pretty a synchronous. And what what I gather from both is performance, especially from a back end perspective, but also from a from a mobile perspective, or a customer experience perspective, that's really critical. Would you say performance is probably one of the main engineering challenges that is present in stream? And if it's not performance, what do you think is? So it seems like we're talking in the millions and billions of users that actually use the platform. Alexei Kozlenok: Performance is very important that you want, when you're chatting, you want an experience where you get a response in a decent amount of time. Or if you send out a message, it doesn't take like a minute for the other person to be able to even notice that you're speaking to them, right. So latency is a big thing and latency reduction scheme. So we don't want too many bounces of the message, we use edge services in order to get the data to you faster when you do connect, but there's other aspects to performance, like, you still want that we retain the performance when you scale. So in those situations where the system is loaded with lots of users that a user doesn't have a bad experience. So I would say performance is definitely a big thing. performance and scalability, at least on the back end, there's obviously other problems that you're on might be able to speak to on the SDK itself. Jeroen Leenarts: Yeah, with, with the iOS side of things, of course, performance is a thing. But also the impact that our SDK has on your products as, as somebody implementing an iOS app or not platform. So we actively monitor the size of a binary. If you add it to your products, and we have certain quality metrics in place, we want to make sure that the impact of integrating with our SDK is very much contained to what the SDK does, and that it doesn't leak out in its abstraction all over your codebase. So basically, what this means is that you can use our SDK assets and use our UI components assets, and basically drop it into your app. And that it's like a separate path within your app so that you have like a button or some area. Yep, that basically is the chat, user interface. And then it's very much isolated. But of course, if you want to have a more integrated experience with the rest of your app, you can, you can, if you want go all the way with making custom components that use our SDK, and integrated with your screens and make sure that users can check exactly at the location within your product that you would want. So it's flexible, what you can do. But what we provide is like a base UI components, suite of user interface. And with the suite, you can just get started. But if you want to customize, you can do it through theming. But you can also outright replace components within the entire set of UI components. But you can also just forget about all the UI components and go straight to our low level clients. Sounds scary, but it's basically a networking client that takes care of all the authentication, all the complexities of communicating with a back end so that you just have a clean API to talk to. And then you really use our chat infrastructure as what it is a chat InfraStop And anything you can come up with that you can build on top of that, that's also very much possible. Of course, our UI components are supported by our development teams. So we can really help you there. And if there's an issue, we will make sure that you can get going again and that any issues get resolved. But it's up to you as a as a user of SDKs. At what level, you really want to integrate with our SDKs and our stream products. Okay, help us understand Elliot Kipling: a little bit more about your customer base or where you are present in the market. And, you know, if we touch on that, as well, some use cases of where people are using you. Jeroen Leenarts: We have a number of big chat customers that that's interesting to mention. I will just go down the list and explain a little bit of what our use cases. One is. One is for instance, hopping, that's a online conference slash meeting space. So it's virtualized meeting space that people connect to, they can walk around with an avatar, and have a chat interaction that's like proximity based. And if you are in sort of a presentation room, there's a centralized chat feature, so that anybody in that presentation space can chat with each other, also, with the apps and all those kinds of features. So that's very much like reasonably sized groups of people getting together, chatting together, and you have to make sure that everybody is up to date. Another example is, for instance, Strava. I think if I'm correct, Strava is a app that allows you to track your, your activities in first four spots, like behaviors. So that's like running, or rowing or bicycling, stuff like that, so that you can first of all, track your progress, share your progress, but also have interaction about your progress. Because one of the things that Strafford does with our chat STK is if somebody goes out on a run, then people can support the person running by, by sending messages by by sending emojis. And then the user during the run gets notifications and like readouts and shout outs that somebody is saying, hey, well done, go for the next mile, stuff like that. And then there's like the big brand, companies like Adobe and IBM, not entirely sure what they do exactly what a product is probably going to be a lot. And also a very different set of use cases. But they we have to trust with these, these large corporations as well. And another fun, smaller company, or it's another company, a university that is using a product at the University of Cambridge. And they they use the chat feature to make sure that students can interact amongst themselves, but also with staff, and make sure that they have like a secure environment to engage with their professors and each other so that they, yeah, despite having like golf restrictions for the past two years, and all the living isolated at home or at a student's dorm, that they still could have some sort of interaction going with each other. And you can imagine that tests, especially if you're a student, the amount of chat messages that a single customer can potentially send is quite large. And that's not a very interesting use case that I've seen develop with the products of St. Elliot Kipling: Louis, listening to some of the customers listening to what they build products for. I can imagine there's there's some really interesting Well, there's two parts that I think there's probably some really interesting challenges that you have to solve around trust and safety, authentication. But it but even large scale messaging is in one chat function with hundreds of messages coming in at one time versus 100 Different chat boxes with probably lower levels of messaging coming in at such time. So there's quite interesting challenges between vertical or horizontal scaling plus the trust and safety and authentication part. Because we're dealing with people in in different channels. Jeroen Leenarts: Yeah, there's, there's also healthcare professionals that use our products to interact with the patients. So then you have to deal with all kinds of privacy related restrictions, and make sure that any data that we store on the back end is stored in a way that we, at a minimum, adhere to any government regulations of the territory that people are using a product. But probably Alexa can tell a little bit more about this because I see the scaling mostly along two axes. That's the number of people in a room and the sheer number of rooms that that might be available, but maybe you can share about some something. Alexa, Alexei Kozlenok: yeah, that's an accurate assessment of the general scalability. There's a few other factors to it, in that one person being part of many rooms It's another sort of vertical scale. So if you are the doctor and the scenario that you just gave, you might have n number of rooms, some of them waiting, some of them inactive chat, as opposed to a person on the other side who just has one room. So we try to cater to all of those experiences, and the system does do some dynamic changes, depending on what kind of situation it sends. So accounting for those things, for example, and how we manage on red counts that the system differentiates between those different scenarios might follow different paths. So we always have to take that into account as we build things because we want all those experiences to be positive if someone's using stranger. Elliot Kipling: Okay. How do you go and build something that can scale out like that? Are you able to just touch on some of those parts? Sure. Alexei Kozlenok: So somebody comes to using correct storage, backends and databases, so we lean on multiple ones. And we even have some of their ability to in house to handle different kinds of data for different situations. Some of it leans towards having horizontal scalability of the services so that if something goes down, there's fallback. For example, the WebSockets that we talked about are on set of servlets that can dynamically scale effectively as we need capacity, more or less capacity. So there's some fan out there. And of course, as I talked about databases is being able to have fallbacks for those as well. So if we have clear data models that are easy to access, and easy to query for all of the situations, we don't have any need for super complex queries when time is involved. So we don't want to every time a question is asked or every time a challenge join, we don't want to like do a full table scan. So there's some optimization there that specifically talks about how do we get to that point where the message actually reaches the user? Yeah. Cool. Elliot Kipling: Jerome, where do you think some of your engineering challenges are quite prevalent? Jeroen Leenarts: Well, one of the biggest challenges we had on the iOS SDK in the last few months is also data related. Because with the chat feature, people tend to think it's an online thing, right, you are online chatting, and making sure that you can send the messages. But especially with a mobile device, you're not guaranteed to have a steady connection at all. Sometimes people are offline for a couple hours, if they don't have a data plan on their cellular, or they travel abroad, any any different use case that could have like a short or prolonged duration of not being connected to the backend system. And the offline support feature that we've implemented, it's basically a local storage of what data is available on the server for this specific user. And that's, that's, that's number of things. First of all, you need to store the data. But it's also a sinking challenge, because you have to make sure that once you get connectivity, again, that you try and sync up again with the current state of things on the server. And what's interesting there is that we tried to stick as close as possible to what Apple as a service, and platform provider provides. So we implement our storage mechanism with Core Data. It has one very distinct drawback for people using our SDK. And that is that it doesn't work with with Mac catalyst. So we have a UI kit and a swift UI based SDK. And if you could want to use that, as is, on the Mac platform, you cannot use catalysts. Because core data hasn't been ported to catalyst yet by Apple. But in all other cases, Core Data is, is a is a proven, solid piece of storage technology. It's not so precise, something that you would call a database, even though the underlying storage mechanism is Yeah, but it's more a serialization mechanism for object graphs. And now, we only noticed when we got started with coordinates initially, it was very easy to think about it as just a database. But once we made the cognitive switch from it, being a database to a object graph storage mechanism is things started to click for us. And we were able to to solve all our performance and instability issues that we had with Core Data. And I think nowadays, we have a very solid offline support feature in the iOS SDK available as well, because the iOS SDK had a rough right, over the last few years, and we were playing catch up with the iOS development team that's been working on it, but now, we're completely on par with the rest of the Mobile SDK is that we have available within our ecosystem. Elliot Kipling: What happened over the last few years? Choices? Yeah, it Jeroen Leenarts: was just, we had some engineering challenges and So we, we had some stability issues, it was like a whole plethora of small things that added together detracted from the user experience of our customers. And we've been able with version four of our iOS SDK to pretty much fix all the issues that we are over aware of. And now, the feedback that we are getting from our existing and new customers, it's all Yeah, they pretty much raving about what we're offering as a product, because it's, it's a high barrier of entry with a product, because it's, it's not something that's really cheap to get into. But if you want to have a chat feature, and if you tried it yourself, yeah. Then you know, what amount of effort and what amount of cost it takes to run a chat feature, and then comparatively, at the price level, that we offer a product? Yeah, you cannot beat that. And, yeah, I think right now, compared to the competition, we're pretty much beating them all, across the line, really, in sense of features, capabilities, scalability, performance, and I think, yeah, it's, it's been a long road for the iOS team. But we've managed to pull through. And, yeah, I think we're in a very good place. Now with the SDK, it Elliot Kipling: seems as if the the points that you touched on speed, capabilities, features performance, they're really quite quick critical to winning this game. In chat messaging, and activity feeds, we don't necessarily need to go into competition. But it seems those four elements are really, really key to getting this done. Jeroen Leenarts: But a big difference between the front end side of things, and the back end side of things, is on the back end, if you have performance issues, to some extent, you can just throw more hardware at it. Of course, there are some costs involved, you need to make sure that you you fix things. And it's always better to not need as much hardware. But on the front end side of things, you have one device, one CPU with a number of cores, but that's it, there's no there's no horizontal scaling that you can do there. And if you saturate your CPU, first of all, you're draining the battery of the end user. Second of all, if you do that for too long of duration, then the operating system will say I don't know what this process is doing. But I'm evicting it from memory because I don't like what I'm seeing. Yep. So that's something why it's important to have performance in check. And also, for for end users, they are used to tapping on the screen, and the device responding. You don't want to have glitchy things happening, you don't want to have any stuttering on the screen, you just want the experience to be smooth. And especially, I recommend the people listening to this podcast who are app developers themselves, or or even web developers. But the biggest complaint that you probably will get from your end users in is when you try to scroll something and it's just not happening or it's not smooth, then then it's immediately on the table or very visible that, hey, the performance is not as good as it should be. And, yeah, and with an iOS device and an Android device. Also, it's one device. That's the environment that you have to deal with. And especially with Android, there's a whole list of devices that have a longer lifespan have a lesser capability or less performance. So that's something you really need to take into account. And even on the iOS side of things, there are devices that are not as capable as the current flagship model. And you do want to serve those customers in a way that they feel that their product is functioning, that it is smooth and operating correctly. And it's a perception thing, because you can have a product that is perfect that does everything that you want it to do. But if on the surface performance seems to be out of sync, not on par, then immediately you're like, Yeah, you'd like three strikes down already. And and that's what we do not want to cause with with the users of our SDKs. Yeah, Elliot Kipling: Alexei, this one's probably really useful for you as well. It has the mindset shift, been quite a shift coming into an API first business from a b2b, b2c mindset because that they are two different things. Has that been a shift for you? Alexei Kozlenok: So I've done API businesses in the past, so it's not as much of a shift for me. I do feel like as engineers, like my background as an as a as an engineer, as well, you have some more familiarity with the API business because you can look at it and you can see how you would use it. So there is a Some benefit there in that the company itself as it builds things, we have a set of people that can look from it from a user's point of view, oh, an iOS developer might look at this and say, if I was building an app, how would I see this or a back end developer might say, if I was building a back end service and interacting with it, how can I see it? So there's some benefit there. But it doesn't detract from the same sort of customer communication that we happen to know let or regular b2b or b2c environment because you're still, you're still sort of providing that service, eventually to a customer, right? So it gets to someone's screen, even though you might only be providing a part of it. Elliot Kipling: Okay, good answer. Okay. Where do you think the stream will be in a handful of not necessarily months, it's probably short term. But if we were to look at a year, as an example, I can imagine market share is probably quite an appealing thing is in how can we continue to pick up more users more customers? But is there anything in streams crosshair that the business are thinking, we maybe want to diversify into these areas? Or is there a vision for the business that you're able to share that doesn't necessarily coincide with spoiling anything for competition as well, for competition purposes, Jeroen Leenarts: that's a good one. Of course, first of all, we want to add specific features to our current products. Can't really share too much about yet. But, but we have some really big plans. And we are working on some really big plans that basically, will, will put us like, exactly in the lead where we want to be with anything chat related. And I think we're also slowly starting to look at at adding something to the product portfolio of stream so that we come up with another product that would perfectly be in support of a chat feature, but can also stand on its own, so that we, as a company also diversify a little bit our sources of income, because right now we have a chat, SDK and feature and we have what we call a stream type feature that is activity based. But it's like a really small product comparatively to chat. So yeah, it's it's as a company, we're really now getting into into the build out phase of getting a larger portfolio, both in the sense of products, but also in the sense of features, and in the sense of customers. And that's for the foreseeable future, it's going to be our total focus that we will be working on, and making sure that we keep our performance and quality and anything related to solid software development, up to spec so that customers getting in touch with a company trying our products, let's say are convinced that they're better off using our using our stuff instead of inventing it themselves. Because grabbing back to the remarks that you made about API and product business, I did make the transition from a products focused development to an API focused development, because with iOS developments, there's a very strong tendency to have the not invented here syndrome. So getting third party dependencies in, it's a thing, you don't want to do that too much. But now I am working on like the third party thing that you want people to integrate with. So not only have to do you have to be good, but you have to be better than good to make sure that people get convinced and then stay convinced that that your product is good, really love it. Love it. Elliot Kipling: Help us understand a little bit more about room for people in the teams. And what that might look like if if you continuing to diversify some of the products revenue streams, that probably means building new things that might mean hiring more people into your teams. Help us understand from both sides, if there is what that landscape looks like for people listening? And what what do they need? Or what skills or thought processes do they need? Where can they come and find you? Jeroen Leenarts: Well, first of all, there's a number of technologies that we work with. So that front ends and Backends. And basically, front end, we do native app development for SDKs. But also with flutter, React Native and a number of other frameworks that we use on the back end. I think, go Lang is a really big part of what we do. But there are some other technologies that we use. We have a very big presence with our products on the AWS Stuck. Yep. So, yeah, it's not only development, it's also an ops, it's also in marketing in sales. really across the board, we're looking for talent. And even if we don't have an current open position, at the specific thing that you are looking for, if you are quality candidates definitely reach out because for the right candidate, we always have room, even though we don't have exact position available right now. And in the sense of what type of work that we're doing at stream. Yeah, it's, it's, it's highly technical. It's highly distributed across the world, because we have a very large group of people in I think, over 140 countries, with two big clusters in the Boulder office in the US and the Amsterdam office in Europe. But we have people that are pretty much across the world are working in all time zones. And so yeah, that offers some opportunities, opportunities, if you want to do remote work, I myself work 100% remote, even though that I live in the Netherlands. And yeah, it's technically challenging work, work that you do. For our customers, you want to make sure that what we deliver its quality, it has performance, that the engineering is top notch. And we're really working hard on getting the word out. And we really like it when our employees if they want to let you actually share what they're working on, go to conferences present about what you've been working on. That's, that's all perfectly fine. We really want to be like an active participant in the open source ecosystem as well. So we're trying to support the open source products that we use for our developments. So we have sponsorships ongoing. And even if you have a good suggestion that we should support something, we're always willing to engage with our employees to take them up on their suggestions. And it's it's an open your formal culture. And you can just keep going. I think if you if you're looking for a job, you should definitely consider stream because it's amazing to work with us. I think. Elliot Kipling: Alexei you want to double down on that you've recently joined as well. Alexei Kozlenok: Yeah, I definitely want to double down on that. I mean, there's definitely lots of openings, especially as we're growing like other products or verticals like John might have mentioned. But also just even the amount of work that we have now, to have all the features that someone might want when they're looking at a chat solution, to be able to build those and polish them and make them perform it that definitely, we have space for people to do that. And in the back end teams, I think there's a lot of need for people who are self driven and really want to work in the technology. And both learn from others as well as provide their knowledge to stream to be able to make the product better. And I think as we move forward with stream and as we can have a larger client base, maybe move into other businesses that will only just grow. So if you feel like you fit there, you definitely should apply. Elliot Kipling: Regardless, anyway, we've got Sharon's podcasting links, you can come and listen to him. We've got other links and content in regards to stream, what they're sponsoring what they're doing. Psi website is super clean, coherent, it gives you an indication in regards to tech stack. If you're listening and you're smart, passionate about scale, performance, customer experience, come and talk to these guys and girls. If you're Amsterdam Remo bold to remote or US remote, Netherlands remote, come and talk to these guys and girls. It's an absolute must. I want to say big thanks to the pair of you for for coming and joining us. And just talking really coherently about the business. What you do value add to customers is been an awesome 40 minutes where I think people can learn a little bit more about stream what you're doing and probably interacting with stream without ever knowing that they're interacting with stream do a fabulous job of doing so. So a big thanks to the pair of you. Thank you. Jeroen Leenarts: Yeah, and yeah, make sure to reach out on Twitter or other socials and links will be in the show notes. So definitely come talk to us because we like to interact with anybody who's out there listening to this. Elliot Kipling: Good. And for everyone listening. Don't forget to like, share subscribe with your friends in the backend space for our and space mobile space even in the product space, go and share with your friends. Thanks a lot, guys. Bye for now. Bye bye. Thanks. Hey guys, thanks for watching this episode massively appreciate you listening and checking in with us. If you want to find out more about us and what we're doing, please check us out on social media. What we're trying to do at engineers is build a community to drive knowledge sharing and experiences. On Twitter. We can be found engineers bio snow underscore, we've also got a website which is engineers.io. These links will all be posted in the description. Any feedback and comments are massively appreciated. We're always looking to improve on where we can. Thanks guys.