Reinventing Streamlit

Speaker 1 [00:07]

This morning, I'm happy so many people have appeared because this talk is not about AI, LLMs, there's not even a single line of rust in there, so yeah, I'm quite happy. So I think the morning coffee is wearing off for most people, so maybe we get a bit of activity and start by everybody who has used Streamlit before standing up. So, anybody who felt a bit at some point maybe that your dashboard became too complex can sit down now. That's good. So everybody else, I'm not sure this talk is for you, but you can also sit down now. Okay. First I want to introduce myself very shortly. So I have a passion for UIs and data visualization, and it has been quite a while since I had my last talk at PyCon, so that was seven years ago. In my daily life I work as a data engineer at Blue Yonder, I don't do a lot of UIs and data visualization there, but we use Streamlit a lot for internal tooling, and that's probably also a use case for many of you. I have a past in mathematics and information theory, I'm also the author of NetX, which is a library to draw network diagrams in the terminal, and I really love baking bread, so when not coding. So I've been a Streamlink user since 2019, but sometimes it feels even longer because At Blue Yonder we built in 2015 some kind of precursor where we also had a dataflow-based visualization library based on Bokeh where you could also in a very declarative way fill with your inputs and see the outputs. It was not based on executing everything in the whole goal like Streamlit does, but when Streamlit came out, I was quite excited because developing something in-house is always a bit more costly than having something that is built by a community. So yeah, I started using it, and we used it heavily, and we were not alone. So if you look at the kind of history, how the stars on GitHub started, so there was a steep increase, and then there's a steady increase since then, and yeah, I mean, this This is a testament of the popularity, a lot of people are interested in it. And in this talk, I don't want to say don't use Streamlit. I'm really happy with it and I love it and I think everybody or a lot of people like it and it's because it's very simple. You start with a script and you can kind of start from your actual computation maybe that that you did and then sprinkle some API calls here and there. And what your API calls basically do, I mean, they create widgets on a dashboard. I mean, these widgets can be simple, static stuff like text, for example, here. Most of them are that. But you also have the interactive widgets, like the text input. And I think one of the great key parts of Streamlit is that the results are actual values. There's no wrappers. script is executed and you can use your functions as you normally can do and they yeah they can be used and you can simply for example format and and I'll put that so that's a really great great idea to start there yeah some some callbacks will if something changes simply everything is re-executed and you You can see how your function or how your code reacts to the changed input. So that's nice. And maybe if you go to the Streamlit website, you can run this little tutorial and run this. And you're really happy. It works nice. Then maybe you create some internal tool and people ask for new features. You add multiple screens. There's somebody asking, oh, I want the detail tab there, and complexity grows and grows, and you add different data sources. And at least at that point, I'm usually not that happy anymore, and I feel that I outgrow the kind of scope of what Streamlit is supposed to do, actually, for me. There's then some helpers, so I mean when this starts usually there's a way, I mean you can cache data, so just do the cache data decorator around it and then if you have a very expensive function like this one there, it's only run whenever the inputs are actually changing, but you never rerun it if something else in the dashboard changed, you don't rerun it. for data fetching, but at a certain point, this feels a bit, yeah, that actually the concept of this kind of whole data flow dashboard doesn't work anymore. Maybe then you discover, and I think this is a more recent addition, you discover fragments. So fragments are a way that you can define a function and basically say, okay, not every Every change should rerun the whole code, but I can actually define something like scopes in there. And if you then change something, for example, the button here, I mean, button click also reruns the whole script usually. If you click the button, it would only run this function. So that's also nice. You can now get a little bit more structure in there. But if your dashboard grows even more, or your application, and it becomes more of a full-fledged web app, and this happened, for example, to some of our internal dev tools, then you need to kind of maybe get back and re-evaluate, am I using the right tool, or am I in this situation where I have a hammer and everything looks like a nail? So fragments and caching are just a band-aid at a certain point. So that's when I discovered, I think a few years back, Reflex. Some people might know it under the older name Pinecone, and I'm just going to read what they are writing because I cannot summarize it more eloquently. So Reflex is an open source framework for quickly building beautiful interactive web in applications in pure Python. So not my words. I don't disagree. I mean, you can always argue about beautiful, but everything else I think is a quite factual statement. And let's have a look at that. How do you build applications with that? And yeah, I had to move up all the slides yesterday because I saw a set in the back at the talk and I couldn't see anything down there. So I added some people here to make sure that you can read it in the back. So this is an example from the website, and we're just following through with a kind of small tutorial there. This is a counter app. You have increment, decrement, and if you need to count something, this might come in handy. And in the middle, we have the count value. And let's have a look at the code, how it looks different from Streamlit. So the first thing that you will see, there's a front-end and back-end part. And it's a full Python or pure Python framework, so you don't have to write TypeScript or JavaScript, but you still, and this is different from how you work with Streamlight, for example, you have to think in front-end parts and back-end parts. So the front-end is a function here that returns a component, and then you see something that's a horizontal stack, and you have a button heading button, so that looks quite maybe You can connect it to the mental image of the image before and get some idea. And the difference here is instead of building the UI kind of as a side effect, so where in Streamlit you write your code and the data flows through your code, here the UI is actually the result of the function. And the other part is you can use the state that you have. So components can depend on some state and so your flow is from state to the kind of widget that you see on the side. So that's the front end part. And then there's a kind of also connected back end and you can also have event handlers. So these are then also pure Python functions that you basically can connect there. And then we can have a look at the back end. At the back end, so you have the state class, which in the behind it, it's a simple pydantic class with some kind of metric sprinkled up on. And there we have our account variable. It's an account field. And this needs to be kind of serializable because it's transferred to the front end. So you always have to think a bit more. So there's also complexity coming into your mental model. But you gain kind of flexibility in the structure of how you can structure your application. This is also scoped for session. So every user going to your app or your website that you build with it will get its own state internally. The event handlers can be called. So these are the functions that you've seen on the other, on the front end. And then you create your, sorry, then you create at the bottom, you create your application and you add this front end page that we built on the site before. And in the back, it's an actual, there's a fast API object in this application so you can also add custom routes that you want to add if you want to add also a kind of API access to your application. So that's the very simple kind of counter example. And just to stress this again, so what's the difference now if you look at these two? So on the one hand, we have the dotted lines, that's basically your Streamlit application, and it's always, if you simplify it to the most, there's some input, there's a transformation, there's some output, and the input can be changed, so that triggers a rerun of the script, And the output basically is passed to the widgets. On the other hand, we have this flow that widgets actually, if you change something, if you click on something, if you enter some text, that will trigger a transformation by some event handlers we've seen. And then this transformation can work with the state. And any change of the state is reactively then changing the widgets on the website. So that's kind of a different, a little bit of a different paradigm, and it's much closer to, for example, what you would have if you built a React application with a TypeScript as a front-end. Now, how does this work? Because I mean, we wrote the front-end in Python, so how is that actually running? And what Reflex is doing, there's a kind of small compilation step happening, or transpilation, which takes your frontend function, so the function that we've seen earlier that returns the component, it takes that and it runs it once, only at compile time, and then creates a TypeScript Next.js frontend using React as a kind of library. And this front end will then be started, and it's connecting to the back end via WebSockets and kind of talking to it. So that's a bit more complexity in there, but what you gain is that you basically don't have to learn a new language, a new stack, a new build system. So you get kind of this left part built with a very low barrier to create a front end. On the back end, it's doing some state management, and whenever, for example, you change a state variable, it will push this via a WebSocket. Similarly, like Streamlit actually does, that uses also WebSockets and sends these updates out, but with a different kind of abstraction layer to the developer. So that's how it internally works. And one thing that you might have asked, so if this function, so for example, here we have also a component, if this function is only run once at compile time, how can I do any dynamic stuff in there? So how can I actually build something that is more meaningful than this simple counterexample? And that's where you have to change a bit. So what you have to do, for example here, you have to use this RxCont, which is then a replacement for any if statement that you want to use on the front end. So instead of actually having an if statement, this is actually transpiled to a conditional part on the UI. And this is something that you need to know, that all these component functions are just running once and you need to build something that is then kind of converted to the front end. There's also, yeah, so you need these special constructs. Any kind of dynamic control flow statements are not allowed. There's something similar with, for example, for loop would also be something that you cannot use so you would need to use this for each state and there you can use, for example, example, anything that is in the state of the back end. The nice thing, I think, about this is you don't have to really think about designing your API. So it's really thinking about the state that your UI has, and you do the front end part as a function, and you can access the back end state more or less directly, and you don't have to think really about how do I craft my API, but it's kind of implicitly in there. So while this, maybe if you want to run a large website, might not be the best tool, but if you do want to create kind of a rapid dev tooling or something, then this is really great and reduces some effort. So now that you've seen these kind of two paradigms, I mean, there's more around, and I'm not saying this is the only one. So there's, I mean, the kind of traditional, so you can use Django, FastAPI, Flask, could do a very long list, and you can use React or Vue or any other front-end toolkit, and it's, I mean, that's battle-tested, extremely flexible. There is the language gap, though, so if you have a large team with expertise on both sides, go for it. Do it like this. That's probably going to scale better. I mean, then there's the dashboards and data flow part, Streamlit, Dash, Graduum, more. So it gives you a very quick start into things, but at some point, you might hit this boundary. And then there, I think these all were developed in the last few years, these pure Python frameworks that give you more flexibility in terms of how to build a web application without throwing you into the kind of TypeScript waters where you have to relearn a build system every half a year. And so these are kind of bridging the gap, are rapid and extensible. And I think tomorrow there will be a very similar talk about, like, comparing Streamlit to fast HTML. So if you're interested more in that or still interested, go there as well. Yeah. So what's nice about Reflex? You have these built-in components, it's not just a web framework to give you a page, but there's a lot of components, forms, data tables, it's all built-in. Really nice feature, I think, for using, you can use any TypeScript React library, basically. So for example, in the documentation, there's a how-to, how to integrate a node, like a connection library without writing any TypeScript code. So you simply can more or less import it and use it right away. So that's, I think, quite cool. You have custom components, you can ship them as libraries, which is also, I think, good for a thriving ecosystem. There's some ORM integration, if you fancy that. And this is actually not in the documentation anywhere, but they have a really nice feature called AppHarness, which is a testing class, which automatically sets up WebDriver and Selenium for you. So that means you can automatically click on the website and test it by a program. But on the other hand, and it's doing a lot of the setup for you. So if you ever did the setup yourself, you might know that this is a bit of a hassle. But it connects it with the backend state. So you can really write a test. I click on the back, on a button and see if the back end status is correct. And I don't know who of you ever tried to test Streamlit dashboards. It's sometimes, I mean, it takes a lot of effort, at least personally, I think. Maybe something changed recently, but I really liked this way of doing it while the app harness. Okay. Now that's a lot of code, you don't have to read everything, but I want to give just a small example. So this is a Streamlit dashboard, it's a very useful waveform visualizer. So there's some calculation function, you have some inputs, and yeah, it's just using a bit of the Streamlit functionality. And I'm just going to show you how that looks. So you have this kind of nice view, you can change these things, the waveform will appear in the plot, you have a data table and you can click on animate and you can see that something in Streamlit which is I think quite nice, you can simply do a follow with the sleep and then things animate, you don't have to think about how the UI blocks or anything, it's simply working. So that's also quite nice and a good point. And now if you look, if you would do the same dashboard in Reflex, it's quite similar but you have this kind of changed concept. So what's different is that here we really store this data as a list and explicitly on the event call we say, okay, now change the state, recompute, and the recomputation actually Updates the data which then triggers the UI update so that's kind of on the on the back end side and then the front end is simply just a visualization of the state that we are having and connecting things and If you do that, it doesn't look as nice, but I don't think it's it's looking bad So you get something to work on it's a bit more polishing that you need to do then with your Streamlit dashboard But you get something that you can use in a very similar way So, when I looked at Reflex, I thought, this is great, I want to use it, and we're having a dev tool, maybe I test it. And then I saw this really massive dashboard that we're having, thinking, okay, if I migrate everything now with a big bang, and that's going to be, nobody will approve it, like, people won't like it. So what if there was a smooth transition from Streamlit to Reflex? And this is basically how the idea for the talk was born. I thought, couldn't we simply kind of wrap the Streamlit API and make it possible to port your dashboard slowly over to Reflex? And this is how this POC of Relit was born. So this is not published yet. I will show it. I was so stupid to do a talk with a live demo, so hopefully everything works. The idea basically is, so with Relit is that you still have your Streamlit dashboard, but you have a Streamlit API wrapper, so something that you don't have to change anything initially in the dashboard that you have. And then you have a kind of controller that is framework agnostic that is kind of interacting with the dashboard. So it's the Streamlit API wrapper is basically calling the controller to create widgets and it's all stored in some also framework agnostic state. And whenever there's a change in any input, which can be coming from the outside, the dashboard is also rerun. And the dotted line, so I started with this and thought, okay, this is cool, it's going to be just a few lines and it's going to be easy. And then I really looked into Streamlit, and this is something I can just tell everybody, if you write Streamlit dashboard, it's a good thing. Really go into the documentation and the code and understand all the flows, because there's so many things if you do timers if you then change some input and I was tweaking around and that was I mean really something I can can just encourage everybody to do their selves to understand how streamlit in all cases react sometimes it's surprising sometimes it's it's what you expect but then I realized okay actually recreating this I need to isolate the streamlit dashboard execution so it won't work unless it's in a kind of separate thread so I needed to to isolate this so there's a kind of thread in this relay controller which runs the dashboard all the time when there's a kind of a change from the outside the nice part about this is now also I think this could be something for a streamlit testing framework because what it means I mean you could also run the streamlit dashboard headless so ignore the reflex stuff above you could you have something to run the dashboard and simply say okay this is my input I I want to click this button and you can examine basically the state and how the widgets look like without even spinning up a browser. So I thought that's maybe something I want to use in the future. And then I added up the dashboard on the top and basically there it's just using so in the state there's all basically a list of all the widgets. We can have a state on the back end and we can also create the front end function of that. Okay. So a lot of talking about this. Let's have a look at the demo. So this is where I'm getting really nervous. Okay. So is it possible for you in the back to see that? Okay. So let's start with a very simple example. So we have this most simple dashboard. We just do hello world. We do some input. We output the name. And we have a button that we can click and then it will tell us our name. And I mean what we now can do, it's not here, we now can do, we can run this in streamlet. And I have to type run. So I typed in every other command but not this one. And yes. Hello. What's your name? Malte. Oh, that's actually not right, so this should be streamlit here now. But we can go over and actually say now use relit. Let's run with relit. So now you see there's this compilation step with Reflex, and it's running a backend server at some port, and then the app is running at the front end. And it says, hello, what's your name, and I can go, yep, so that works. So this doesn't have support for all widgets, so I have some basic stuff that's implemented, but you also need to kind of implement every widget, everything that Streamlit supports, Which when I looked at it was surprisingly more than I expected. And now, so last year I submitted a talk and I wanted to do a talk about my library that I mentioned in the beginning. So I wanted to give a talk about doing stuff in the terminal, how to build terminal UIs and wasn't accepted, maybe not too popular, so I thought, okay, this is my chance to sneak this in here, because, I mean, I said it's framework agnostic, so why not use textual? I don't know, does anybody know textual? So it's also a nice framework to write terminal UI applications. And it's not quite easy, so you could also write your kind of translation step from your widget configuration in this real estate and just do it in the terminal so we can and this is not really looking nice so I hacked this together in the last days so this widget actually should be up there and but you get the gist so this works I can click here so we have a streamlit script that we can simply run in the terminal and yeah let's see does this also work for the waveform example I mean you can probably guess it because I mean that's as far as I got with the widgets so here you can change the frequency the waveform type I don't know do this and even kind of this animation part with the sleep command works and the UI is not blocked you can I don't know change and I try to I mean it was a bit really not looking into the Streamlit implementation but a lot of black box seeing like how does Streamlit actually react when I do something and trying to then to in kind of my back end remodel this. So yes this is not ready for the public right now but I feel like if there's interest and let me know in the feedback if people are interested in something like this I can imagine in continuing this and open sourcing it, otherwise maybe it's just a nice example. Okay, let's get back. So now I was very enthusiastic about Reflex, but I guess probably if I look in Slido there's already maybe there's some some questions so why not to use it or what's can I trust this and there's also quite some pain with it I have to be honest but it's getting better in a very rapid rate so there's some runtime errors in javascript that happen sometimes and these are really hard to debug because you didn't write the javascript code right you wrote the python function and you have to map these things. And I think that's something where the framework is really, or needs to improve. But another thing, so I started this talk, I think that was when I started first with the, or playing around with Reflex a bit more, was half a year ago and it improved a lot. So there are frequent releases. It's a quite active developer community. So that's nice. Then you still have to have this mental model of front-end versus back-end. This is something, if you just want to write a quick dashboard, you probably don't want to do that. That's something where I would suggest really see, if you feel the pain with a streamlet, give it a try. If you don't see the pain, don't jump on it because they have a shiny website. As usual, I think that usually goes with it, but that's important here. Also the framework is moving fast, so some stuff is deprecated. You have this kind of incubation mode of a framework where things can change, and if you want to maintain something in production, it's probably not what you want. And performance-wise, I would say with Streamlit, it's completely on par, but if you compare it to something where you write a back-end, I don't know, in Django, and write a front-end in TypeScript, and you have people experience kind of on both sides, I think you're going to have better performance, and you can already see that. And I mean, wide adoption, I think they have some, the company behind Reflex, so I'm not affiliated by the way, but they have some funding and there's some backing, but it has to be seen. I think there's a lot of contenders right now in this space and we'll see what's going to be, I don't know, with a similar status of Flask and FastAPI maybe in, I don't know, three to five years. So that's maybe reasons why to not yet adopt it. On the other hand, you can really get started quickly, and I don't know, quite a while ago I tried to build a TypeScript application just by it, and I was so overwhelmed by it. I think even choosing the right framework took me longer than writing an application in Reflex. And then each framework had its own concepts, so that's something where you can here, I would say, get started more quickly. On the other hand, if you have front-end experience, if you know CSS, Tailwind or something, that's also something that you can use here if you want. So there's possibility to go much deeper. So that's also something where I would say, if you're that person, have a look. Maybe you're happy over there. And the ceiling is much higher. So you can do much more kind of structural composition, different pages. something where I think it really shines and it has the great extensibility so that works really like a charm including some so you see some react components somewhere it can actually use it without a hassle and I tried that and it's it's really nice and you don't have to learn a new language so this is I think the biggest part of it even though I mean nowadays you can have co-pilot write your stuff without knowing the language but I'm not sure if especially if you don't know the territory you also don't know what co-pilot does wrong so that's probably not a good advice. So go ahead, try Reflex yourself. We're still having a bit of time but I think I rushed a bit further and I did not expect the demo code to go so smoothly, so I have a bit more time for questions. Thanks for listening and yeah.

Speaker 2 [34:42]

Thank you so much. So first thing I just wanted to check you. Is it your birthday today? Sorry? Is it your birthday today?

Speaker 1 [34:48]

day to day?

Speaker 2 [34:49]

Yes. okay happy birthday man thanks for gifting us just such a great talk on your birthday

Speaker 1 [34:58]

I don't know.

Speaker 2 [35:04]

Maybe some of your friends are here, so they're pushing. Okay, great. So, going forward. So, there is a new framework. Oh, just give me a second. So, yeah. Do reflex apps render nicely on mobile devices?

Speaker 1 [35:27]

Yes, because you can use all the kind of CSS ways of having kind of these media types where you can say if it's a small screen and you can then use, for example, the conditional formatting and do that and have something like parts for mobile and parts for non-mobile. So I think, I'm not sure if I actually did it in this one, could have a look, yeah, I think I didn't do it. But you can, for example, if you have a title bar or something, you can make it easily that it's getting a kind of collapsible sidebar or something. So that's quite easy.

Speaker 2 [36:11]

Okay, the next question in our opinion, what are the advantages and disadvantages of reflex compared to plotly or dash?

Speaker 1 [36:22]

So I don't have much experience with with plotly so I can't really compare it Well, I mean for dash. I know that it's I mean it's it's a bit closer to actually writing your Writing your code also with kind of callbacks, but I think the it's still very much Not open and extensible in a way that reflex for example is so So if you're using Dash and you're happy, it probably works. But if you want to get a bit more low level, have a look at Reflex. So I think that's the main part. And also this front and back end. So Dash is more, so you still write your whole application like maybe a local UI application. So here you have this mental split, which can be negative, but I mean, it also represents the reality, right? you have a back-end and a front-end so why not kind of take that and kind of work with it.

Speaker 2 [37:25]

Okay, the next question is, there is a new framework called PyShiny, which also kind of solves the streamlit issues. Any experience with you using PyShiny?

Speaker 1 [37:36]

I looked at it and before doing the talk I tried to look at all the frameworks and it's really hard because there's a pie shiny There's nice guy. There's I think three more. I can't remember right now If I look at them and I mean it's a spectrum if you see I mean you saw the three categories I put up before and I think it's a whole spectrum and I don't know I it would probably a bit more I wouldn't put it somewhere because I haven't used it but But so some parts are in between. For example, this nice guy looks also quite close to what in a way that Reflex and for example FastHDM are working, but with maybe a bit different way of pushing updates out to the front end. So that's also always a difference. So here, Reflex is closer to Streamlit because it's using WebSocket as a connection, kind of as a protocol to send updates, whereas I think FastHTML, for example, is more really doing classical websites where you navigate and it's closer to something using something with X. I don't remember it right now, but if somebody knows...

Speaker 2 [38:55]

okay okay so the next question if reflex doesn't even support a native python conditionals isn't actually a DSL and not really a library

Speaker 1 [39:06]

Yes, the components are kind of a DSL, but I mean, this whole part of bringing the components that you build, so the front end with this kind of DSL in there together with the back end library, I think it's still a kind of streamlined ecosystem. And I mean, I also thought about this, wouldn't it be better transpiling, really compiling the conditionals, but then you end up also in this kind of a whole new language space, So I think it's probably not a bad choice.

Speaker 2 [39:39]

So the next question, which tool did you use to sketch your diagrams? It looks good.

Speaker 1 [39:44]

The sketches or sketches, I think that's X called X Kelly draw or which were the other slides

Speaker 2 [39:54]

A sketch on the slides, maybe, or diagrams that you used in the presentation, maybe.

Speaker 1 [39:58]

That was a Kelly draw.

Speaker 2 [40:01]

Okay, so can one share or cache our data across the states?

Speaker 1 [40:08]

Yes, that's also possible. So that's, I mean, you have a whole backend application, so an API object, and you can use also all the kind of fast API ways to share states, and you also have access to that. I haven't really looked into how stuff, like if you have a thread pool executor or something like that, how that works. Yeah, but you have access, and the documentation is also quite specific of that, which I always like. I mean, that's a good sign the documentation mentions this if they if they don't mention it sometimes it seems like this these problems are not existing and then if you go further you realize okay it doesn't work now with yeah scaling this thing up

Speaker 2 [40:50]

so the next question in reflex is all state managed in the back-end if so can this sometimes negatively impact the performance

Speaker 1 [41:01]

Yes. So it's yes and no. So you can have direct connections. So I didn't show that, but you can have direct connections where you have to enter something and directly pass it to another widget. But it's quite limited. And yes, passing everything to the back end has a performance penalty. And this is why I also mentioned, I mean, earlier with the performance, if you go very large scale, this will probably hit you. But for, I don't know, company internal tools, I wouldn't think it's going to be a problem. I mean, it's still fast enough if it isn't hit with a lot of load.

Speaker 2 [41:42]

okay I'll just take two more questions so since fast api powers the back end can I use my existing fast api and add the front end

Speaker 1 [41:50]

I think that's possible, but I haven't tried it.

Speaker 2 [41:55]

okay so last question so i did not quite get how reflex overcomes that messiness issue or in the streamlet you mentioned can you please elaborate on that so

Speaker 1 [42:05]

So, one thing, these state classes that you saw, you can have multiple of them and you can tie them to components and really instantiate these components. And, I mean, that gives a lot of structure to your application that otherwise you, it's hard to get by in Streamlit where you always are tied to your data flow, more or less. And it's, I mean, that's something, data flow is not always the same as what a UI shows. So I don't know the part that prepares. I don't know the completions or a list of a select box I mean, that's a really UI specific part or something like that. And this is something I mean with streamlit They have a lot of widget to take care of that But if you're kind of trying to exceed that it's hard to build this and separate this part from your kind of core logic So I think it allows you to give much or way more structure because it adds a separate layer where kind of the presentation and the state and then your actual execution is handled. You can do that in Streamlit but I think it's way more effort. So a bit of a personal opinion but maybe you can give it a try.

Speaker 2 [43:16]

Okay. That's all we got. With that, thank you so much, one second, Madhav, for sharing your valuable insights. And thank you so much, everyone of you, for posting our questions and making this session interactive. Thank you for being a wonderful audience.

Speaker 1 [43:32]

Thank you.

Speaker 2 [43:32]

Thank you.