Full stack Django Rest Framework

Speaker 1: Well, okay, recording Hi everyone. Welcome to our presentation. My name is Thiago. I'm from Brazil. I'm living now in Berlin. I'm working for the company called Mirror where we develop uh what we're going to show to you today. And I'm here with my friend Israel.

Speaker 2: Hi everyone. I'm Israel and I work with Giago in Mater as well. It's nice to be with you here.

Speaker 1: So today we're going to talk about FoodStack Jungle Has Framework. Before I start talking about it, I want to give you a little bit of context, maybe disclaimer, why this solution was a feat for us. So first I want to talk a little bit about like how the team at Meter looks like. So we are a very small company, we have a very small team. And then we started to have some problems when we tried to separate backend and front end. Um it was kinda hard uh because we want to have one big problem solved by a pair, so we always do pair programming So we want that pair to be able to solve the whole problem. We don't need it to have some other pairs working on the front end only or with the back end only Then we had more

Speaker 1: back-end developers than front-end developers. I think that also helped moving things more close to the back-end parts. And because most people were already used to Django has framework, then they were used to Django itself, we started to think about maybe we can make has framework work more in a full stack way than just to have uh JSON APIs. And we knew that Jungle has framework had handlers and we knew they had the HTML template handler. So that's why we decided to start um using that.

Speaker 2: Well, the progressive enhancement way is a concept that we we that this concept appears a lot in our conversation, but not only in our conversation. We actually use this concept to uh decide on how we are going to to do stuff and to solve problems. And I guess this is the overall frame we use to shape this talk as well. And I believe that the best metaphor to understand what progressive enhancement is, is to think about a seed and a tree and the relationship between them. And if you think that the seed doesn't look like a tree, but

Speaker 2: The city actually has uh within uh itself uh all the well all that it needs to solve the current problem and to do the next step. And not just about that, it's not just about the next step, but it's the next step in direction of becoming a tree So talking about code, we use that to decide how we are going to solve the current problem. and still uh without carrying too much abstraction and solving too much uh uh upfront, but align it to the the north uh where we can where

Speaker 2: where we want to arrive. So uh and why why do like that Because it's easy to stop because we always have uh some problem solved. It's easy to stop in the middle of something because actually There's no uh middle because we always have something ready to be deployed. And it's easy to change the paths uh because we are not always risking the whole because we are looking to solve a specific problem and a local problem And it helps us to make sure that we are not solving a problem that is already solved by some framework.

Speaker 2: some protocol or uh some tool you use. For example, we are not re-implementing stuff that jungle already does and we are not re-implementing stuff that the browser does itself. So it's nice to not worry about things that already works. So this is the the background of the what we are going to show And one important disclaimer is we are not showing code that as a recommendation. This code is not, despite of being ready to production, it actually is in production. uh it's a seed. It doesn't look like the final outcome. So we are going to see some ifs

Speaker 2: that uh probably is better to become uh I don't know a mixing uh but we are not too worried about that we are worried about the path the whole path and the process of uh making the next step easier and still being aligned to the final outcome. And with that in mind, we are going to talk about the API in uh render, Django templates, add new renders, and at the end, enhancing some uh UI with JavaScript. And uh start with the API. Uh what 's the importance of that? When we are thinking about the API, it's not just about

Speaker 2: uh relate uh thinking about the the usage of that it's important but first we need to think about the the data that we are going to use so the API gives us a useful uh tool that is more focused focused on the data itself. And we are not thinking about an abstraction of the data or the data we are going to have in the future. We are going to think about the data we have now. and what we can do with the data we have now. And because of that, we start with the API, even if our first intention is to have an uh uh template an HTML version of that and not just because of that

Speaker 2: but we realize that even work when working with uh uh HTML template Sometimes we went back and looked at the JSON version of the data just to make sure that the the context are well done and uh stuff. So uh it's important and useful to have a good fallback to simplify stuff and face the problem in a simpler way and instead of always having to worry worry about the presentation of this data. And this looks like uh a waste of time but it's actually makes the process easier even when we are not using uh an endpoint for that specific uh screen

Speaker 1: So then after thinking about the data, um thinking about the API, we start to think now about handling jungle templates. So when we first start this project and we sort of start approaching this problem, we we we expect that it's a little things like a little different, and we want to show you some of the things that we found out And the first thing we saw was like if you set a HTML template handler to your view , you may expect, okay, so now I can just do a template and it would just work. It doesn't really work like that. What happened is by default, Django has framework always returned to the template the serializer. data, which means is

Speaker 1: It is what it will become a JSON format. So it's like very only simple data formats, simple data types. So for example, you don't have something like a date type So for example, this doesn't quite work because if you try to use that, they created at, we expect a date But actually it will be a string because that was the what the serialized sent back. So the serial data. So your your context actually is not going to be exactly what you expect. So What we did was to create a dummy serializer. And this dummy serializer has only this: there's the self. data equals to data, and the data is the instance of the object on the database.

Speaker 1: We decide to do that even though the documentation doesn't show us this is the way to do. So actually the documentation showed us that we should change our get function and in the get function instead of returning serials. data return the instance itself in a context with a um in a dictionary kind of like the way if you're familiar with Django itself the get context would do. But we decided to go with W serialize. So we decided to do that because we didn't want to change the get, because get is too too far away in the in the in the process, in the pipeline of handering something So we wanted to do something in the middle because we we thought that well other things may use um the get differently. We don't want to change too much, so we want to have uh change only when we need it

Speaker 1: So we decided to change actually the get serializer class. And then when it's HML, we return a dummy serializer. With that everything works. So now we have our data as we expect in the in the template so we don't lose the Python convenience. So after doing that, everything works well. Then we started to have new problems because then we started to have forms. And Handering Forms was a very nice surprise. So here I'm showing you like one of the old custom forms that we overwrote from the press frame covertal input. So you can take a look with more depth in the documentation itself.

Speaker 1: But what I want to show to you just so you understand a little bit how it works, has framework has a form handler that actually don't really use in your view. but actually it's just a template tag which has a render form that you receive as a serializer and this will just work. That's very nice. Because what it does, it goes into the serializer and each of the fields of the serializer, it looks up an HTML that will render that field. In this case, we have an input. So it is the most basic one. We thought it was really cool when we saw that pattern across has framework multiple times where you have the HTML and CSS very not strictly, but very well separated from the rest.

Speaker 1: So that's really nice. So if you have a designer or someone who's more into HML, CSS, not too much into Python, you still have the power of HML right there for you you can you can set your classes uh you can have your context you don't have to have um to worry too much about like python and how for example we in In the form itself from Yango, sometimes you can set the classes in Python. So you can also do that directly here. So that's really nice. Actually, you have more, you have this vertical input. This virtual is like a template pack. You can have multiple of them. So we have vertical, horizontal. You can download a material version of that. So I think that's something really nice. We didn't expect that.

Speaker 1: We were very new to the concept like a has framework being full stack, and that was really nice concept that we found there. So that's really easy to change, really easy to customize, and we totally recommend following the path. So

Speaker 2: um well it's not always a good surprise, and when we are creating uh some app there are some parts of it that repeats and in our case we want that these parts for example pagination and uh filter sometimes and uh stuff like that uh can be different uh according to the different view of the data for example uh when we are creating HTML, we want to be able to choose the pagination strategy uh we want uh for for our case. And that that was our first approach, which is the very

Speaker 2: same approach that the documentation recommends us to overwrite the pagination class and uh change it accord according your uh decision as a as a as uh as designing uh application but uh Sometimes we we have the API and we started by the API actually. And uh Using when using uh a JSON view, we can we want to be able to choose a different approach uh about pagination and following that path of not uh not adding too much abstraction.

Speaker 2: We went for approach that, well, if we are just changing according the format, that's what we are going to do. So we tested if well if it's HTML format, chose the correct pagination strategy. And using this simple solution, we can choose uh and add a new pagination strategy as we want.

Speaker 1: Another thing that we discovered that was not as as we expected actually only was in Django, at least I've been using Django for a long time, and every time I just put a login required to a view, I just know it's gonna redirect to the correct place. So they're like if the user are not allowed there you're going to be redirected to the login page, everything is going to work fine. You have the next set up. So everything is there. When you're working with has framework, that's that's not true anymore. And it makes sense that not to be true anymore, because uh you're mostly working with API, so you actually want to do is like return different um HTTP status. So fortunately for us, has framework created this um

Speaker 1: this way of changing how you how you deal with how you handle actually exceptions. So we create our our exception handler. You can set that in your view. You just say like there is like a get exception handler and it just say which view the which function do you want. And the only thing we did was we checked if there's like HTML and then we return the redirect to login. And this is from Django itself So that was actually uh took a while to figure out, but in the end it looks quite small and works really well. But that was something we were not expecting at all. Uh and it took a while to think What is the best approach? How to do with that? We are very happy with this one. So if you're going to do something like we're doing, uh be aware, and maybe this is the

Speaker 1: good way to go. Then I want to talk about handlers. So so far we talked about the HML handler, but now I want to talk about different handlers. So we had a problem at MITA once that was like we needed to create a lot of new features for a data table. People wanted filters, people wanted um search, the paginator itself that we already shown, a lot of things. And they wanted all of this because they wanted to explore the data. And then we we thought like, well, actually why don't we give them like Excel file? Um and we knew that we already had handlers and this whole thing, so adding a new handler should be easy enough. And it really was

Speaker 1: easy enough. In uh by just adding a new handler, now our view. could send back the same data but now render it as XML not XML XLS X uh and not HML. And that was super nice because we could give this new feature really quick. So I want to show you a little bit how it looks like. So if you want to do your own handler, because we of course like we are doing XLSX, you can do your own and see what fits you better. I recommend you going to the third-party packages in the guide of the Jungle Hash framework. There's a link for a lot of them, and you can see code, it's all open source. So it's really nice to learn from them. But basically you need really simple things.

Speaker 1: It's just like a handler function. We have some data coming in and you have to return it, do something. You need also to have just two things, uh two attributes in your class, just the media type for the content type and also the format for when you're requesting data. So you can do something like slash your URL and then has a format in the get parameters and can be in this case CXT So that was quite easy to change if we need to, and also if you want to ex to to explore and to enhance, like the way we've been doing so far. So I think it's nice to know how Handler works And then we also have something different. Like remember like when we talk about dummy serializer that we thought let's change the Sky serializer class?

Speaker 1: That was a really good um Starting point because then this became very important. Um, because now our XLSX needs a serializer that is different than the HML, of course, because the HML is a dummy serializer. Later the Uh JSON is gonna be another serializer maybe, maybe not. That depends on you. But that was important for us, you know, like having a way to to define which serializer to use was really good. And we always using this uh HML format, is XLS format. I want to give you like a quick um look into how we did that So basically you have uh in in Has Framework it um adds the accepted handler for you all the time and you can just check what is the accepted handler

Speaker 1: and you can check if it's the one you're using. And then you can define what to do. That was very, very helpful. And then we use this multiple time, for example, imagination. So Pagination some for example, I don't want to have pagination XLSX. That makes no sense. How can you paginate like an Excel file? So by just having the This if it's easy, I can do it. Otherwise, I just paginate Coryset like normally and then it will just work and that's fine. So that was very cool, uh, easy to do, and we can do more handlers if we want And it was super uh was a feature that was very fast to implement. We didn't have to think too much. We already knew the data, we already knew what the data was talking about. So G uh Starting this was really cool.

Speaker 1: We didn't have to waste too much time thinking about a new endpoint, a new API, how we're gonna do, how it's gonna look like. Everything was already there, so we had a lot of thoughts. already done in that field in in that problem. So that was really cool thing that we we that emerged from this decision of a um Full stack has framework. So next.

Speaker 2: Yeah, and different from the thing we have uh So until now, uh, this part is not in production because uh all we did without JavaScript was fast enough and the user experience was uh good enough. So this part we are not deployed yet, but we did this example just to explore around and see, uh check about what is the limit of that? What is how can we use JavaScript to improve what we already have? Uh so uh we first are making sure that we are just checking the the version without JavaScript and see it's

Speaker 2: work uh fine enough and what we are going to do is to acknowledge some uh error in a list of errors and we are going to click in this acknowledge button and you can see the refresh is it's happening the normal one the traditional one actually And what we are going to try next is to uh enable JavaScript and see how can we improve that. by uh avoiding these additional uh general uh request or big request. I mean so when you click now there's just uh ajax request And we can see

Speaker 2: uh the body of the the the response and we have the the JSON that we can use to update our our HTML in order to enable the the click again and the data we sent it's The same. The same we are going to send when we are using the HTML approach is a form data So we are using the same approach to send the data and with and taking that the response to update the using the response to update the HTML. And you can see that uh it's uh old school uh HTML

Speaker 2: form that there's no fancy framework or complicated stuff. It's just as complicated as it can be and as simpler as simpler as it can be. And we Don't even need this explicit value uh checking uh because Django forms can take care of that, but we are doing this way to show explicitly what's happening And we are uh adding this value and trust that the browser itself and the HTML we are going to do the heavy lifting for us. And the JavaScript, uh we chose to go for a vanilla approach without any framework just to show uh

Speaker 2: what's really happening behind of the scenes and what we're doing right now is overriding the submit event and uh getting the answer and using the the the answer of the request the response of the request to update the value of the the the input So this way we can click once and update the data and click again and we will have the same behavior but changing the data in the back end. And a tricky part of that is since we are using the very same view to taking care of these two behaviors, the behavior

Speaker 2: that uses Ajax and the behavior that uses uh normal or uh old school uh requests Uh we had to override this this behavior because uh the Expected behavior when we are using when we are updating a data with a JSON endpoint is to see the detail after uh the update happens. But that's not the behavior we intended to our template, to our HTML version of interacting uh with the data. Because after we we upidate the data, we want to see again the data table we used to change

Speaker 2: the so we are adding this redirect and we try to be as precise as possible to uh uh use what we already have so we have already this uh behavior this sorry this header uh available in the HTML specification so let's use them And we use that to redirect back and preserve this behavior we want. So

Speaker 1: in conclusion, we want to give you um a little bit of like what happened, what we wanted really to for you to take home and use in your own projects. So just reminding you all like what we have um talked so far. So I think for us like the the biggest learns we had was like finding a solution that really fitted us. So we experimented other solutions before, didn't quite work, maybe for a bigger thing or a different thing that could have been better. But finding one that really fitted us was really good. Another thing we learned a lot was this balance of just changing where and what you need. So we didn't have to rewrite our own framework, write everything the one way we wanted and have everything done again, but also at the same time, we didn't have to just

Speaker 1: change our own problems to fit in the framework that already existed. So I we liked a lot this possibility to change just where we need, uh changing just like for example the get serializer classes, adding a few ifs some places, doing a lot of inheritance. Um And maybe everything worked as fast as we thought. And that was really cool. And also, of course, a progressive enhancement that was essential for us to to go through that helped a lot to us deciding like what is the path that we wanted to to go through. And always have this in mind when we want to build something that should give value right away. So we can do something stop then make it better later. So that was very good for us as well.

Speaker 2: Yeah, it's uh it's important for us to highlight that uh The solution we have probably will not look like the solution we want to your case, but uh this process of thinking about the the whole uh problem including the teams the team we have including uh the technology we have on hand and taking it take taking it into into consideration uh together because Sometimes we forget that when we choose some technology, we are actually some uh choosing some stuff about our teams as well. So, and when we choose a team, we are choosing technology as well.

Speaker 2: And thinking about this whole thing together. and progressively and trying to be precise in each step of the problem solving process. It's uh I guess it's the main uh takeaway of uh this whole process for us. So I hope this will be useful to you as well

Speaker 1: So thank you everyone for staying together with us today. We're gonna go for the questions. We still have our uh contacts over here. So thank you one more time.

Speaker 2: Thank you. Till then got it. Uh uh we are are expecting Are are we waiting for a moderation?

Speaker 3: No.

Speaker 1: No.

Speaker 3: I don't think there is one.

Speaker 1: No.

Speaker 4: Recording is on.

Speaker 1: It's uh free for all. Anyone can explain uh ask us questions if you want to.

Speaker 3: Hey.

Speaker 5: Hi.

Speaker 3: Um so your use cases are mostly crude, right? Like just listing and details. Uh like do you did you have any uh page or um you know interaction that needed more complex uh behaviors and like did that get in your way for some reason or you you only have like really simple crude views

Speaker 2: Uh not in this uh project. Uh in this project we have just input roots, but uh we have already used this uh approach to build for example some uh shards and some uh D3DS stuff so we you can have some have interact heavily interactively page uh with the very same approach, but adding an additional layer of JavaScript maybe. Are you seeing my screen? Not yet?

Speaker 1: No.

Speaker 2: Okay. And I know to fix that, but if you look at here, uh there is some uh shards and there's no data sorry but this is a trivial let me try to get a A year with some data. And what we did here is the exactly the same when when we change the the We we two events subscript. We change it the own change event to do a submit

Speaker 2: and we overwrite the submit update the data. So uh here we added some JavaScript. JavaScript and create part for structure, I guess there's no JavaScript at all. It's just CSS. But uh for others like this this This one here we have uh the 3js, but it's the very same approach. It's the very same approach. What changes is the that uh that function that we showed at the end of the talk that handled the the response so we can put thing fancy but it is not our uh use case in this so

Speaker 5: Hello, um very interesting approach. Um it's it's quite special to see this. how you manage to uh kind of use a rest framework to do traditional HTML responses. So I I I got lost a bit into the details during the presentation So I just wanted to know if you had like an example code that we could expect inspect to clearly understand how you handle these, let's say like dual API

Speaker 1: Okay. Um I thought that you were gonna answer. So yeah, uh no we do not have uh we thought we try we try to build something for jungle com Uh we didn't have the time because we wanted to do like a um a nice project that we can put on GitHub. Maybe that's something we can think about now that we don't have the pressure time the time pressure anymore. So maybe that's something we can do. We can think about it and have like a simple uh view that deals with like this um different handlers and you can see the code and play around and use as example. Um yeah, that's something we can do. Uh for start I think going with the has framework documentation is really good. I think the main difference is what we showed it was the dummy

Speaker 1: serializer so instead of So um using like changing your get request or post change only the serialized class. That's what something that we we it's a little bit different than the documentation. Um but yeah we can we can think about that. That's something we wanted to do anyway. So if we then if we do that we can post may I think this this uh slack is going to continue for a while. I think it has the same from last year, I'm not sure Uh maybe we can post it. Maybe we can post it. Or I can tweet.

Speaker 2: Sure. Sorry, please go ahead.

Speaker 5: No, no, it's fine. Thank you.

Speaker 2: One thing I I I felt during the process is if you uh just change the order, if you commit to add the JavaScript at the end of the process So things are uh flows kind of naturally this way we did. Because uh There is already some solutions to traditional problems and uh the the has framework documentation was pretty helpful in this whole process. So It's despite of not having a good example to show you are uh a ready example. Uh I guess just following this commitment and the Django hash framework documentation can provide

Speaker 2: a very cool uh traveling, I guess.

Speaker 3: Uh so this uh this dummy serializer uh you you presented got me thinking about Uh there's a an strategy I I like to use in in Django projects that have like more complex domains. is to create domain objects. So just plain uh Python classes uh detached from from model instances. Because sometimes you need uh data from different models, uh, they're related, but you don't necessarily want all of the fields and you want to apply some some business logic so you can like create your just a class, create a bunch of properties and like

Speaker 3: do whatever business logic you need to do in in that class and like really encapsulates the business logic in in a single place. Uh so that uh dummy serializer got me thinking about that. It it would be really interesting to have uh uh an architecture where uh I I can't give So just use this my directly this my my domain objects, uh at pass them as context to the view to to my template at the same time that I can use this object to to pass to a uh a serializer uh and yeah

Speaker 3: same change send the same data to to the api

Speaker 2: Yeah that that's it's pretty helpful and actually it's pretty annoying not having this possibility not having our own methods in in the view because uh if we don't do that that the mystery laser we are going to handle with uh uh integers and strings and that's all not not even the eight we we are going to have so if you have a uh a richer object with a lot of uh uh properties and uh cool methods and not not having the possibility to use that in in your template it's pretty annoying. So

Speaker 3: yeah

Speaker 2: that was the magic behind the the demonstration laser I guess.

Speaker 1: There was a question from James. He said, hello, I think it's this is really cool. What are the ways that you try to solve this? Given that you probably came up with more than one previous solution to your problem. How did you know that the current solution is the most correct one? So that's nice. Um I don't think we even know that this is the the most the most correct one Uh we we had of course before that uh only using only Django and then we had sometimes problems when we needed to uh to do this more interactive things through JavaScript. Then we kind of like had always to create another view that is an API. We have always the separation we didn't like too much. We've tried using like a single page application approach then that was the worst case scenario for us

Speaker 1: because of the way our team works. Um and then and then we arrive at this one. What we've been liking so far is what we we we told you in the presentation, in the in the talk. Was that was pretty nice to be able to change just little uh small parts and keep the rest the way they were. Um And for now that's what the thing we are uh liking the most. So it's easy to find uh the the the just small parts during the request response process change what we need to change and keep the rest. So our experience have been that from time to time we we took a while to view the whole thing, the the base, but then we need to have new features when somebody have like a new uh feature request like the the example we gave with the XLSX.

Speaker 1: It was super easy to to implement or when we need to do like this Ajax things, also it was very um straightforward to implement. I wouldn't say easy, but very straightforward. And we already had everything in place. And it we've been like this um because of that so far. That's uh that's what we liked. Um and got people also Also another thing that I think it's nice, uh in our team uh we had way more people that knew Django has framework than they really knew Django uh because I think nowadays that's very common. A lot of people work so uh a lot in back end exclusive application. So I think that also was a way to to get people uh in the front end without the feeling too much. Uh uh so you when you see your front end , surprise.

Speaker 1: It was uh easy it was nice. It was nice uh to give people so they already knew the concept, so that was cool. Instead of having to because I think has framework looks a lot like the jungle views but they're not quite the same and I think a lot of things you think they're the same they're not so I think it also was nice uh for us to to keep in mind just one thing, one mindset. So this is Jungle has framework. I know what to sub to override, um, and that was um why we stick to this for now.

Speaker 2: Yeah, and about your last uh your last words, the most correct one, uh these raise uh a very philosophical subject and we like it a lot. But uh Why do you why do you think about it is it's kind of uh not obvious that when you go for a solution that adds another layer of abstraction we are actually making things more complex. It looks obvious, but it's not. And we if you add, for example, uh JavaScript. a framework, for example, Ambler, that solves a lot of problems to you, it brings with it

Speaker 2: a lot of complexity. and a lot of weight because we need to to learn that new language that new uh language above JavaScript and above uh ATTP protocol uh and the way the browser works. So uh while we are creating a web app we have a right to to uh uh learn The HTTP and uh HTML and uh the browser the browser before uh I'm sorry, the browser 's default behavior So we we have to to learn that anyway. If we add a new one, a new layer of abstraction, we are adding a new level of complexity.

Speaker 2: Um I can talk hearing the the current presentation. Let me pause here just to I'm sorry. I'm lost in my tabs right now I'm sorry. I can 't talk

Speaker 1: Why you why you you doing that? So just let me answer one another question. So how do you get a copy of the presentation? Um Um I don't know. I think everything is gonna be available uh on loud uh on Loud Swarm for a while and if they are gonna post it also later. But maybe that's uh it's a question that maybe you can ask in the support channel because I think that's better to get from them. Um if you want, you can think me on Slack directly. Uh that's the same name, so Tiago Garcia. uh i can also send you the copy of the the slides so it's just a google um docs but if you want the presentation itself like the recording i think you have to ask the the support channel so they can uh direct you to there

Speaker 2: Uh I'm sorry because my my confusion. I was hearing some noise here, I I couldn't think. So uh what I was trying to say is that uh It's not obvious that we are in complexity. And what we believe that's most correct about that is because it's simpler and sometimes it's harder because we need to figure out how to uh replicate some behavior that these frameworks already does for us. Uh so it's harder. You need we need to understand deeper uh the behavior of the browser and the behavior of uh http and jjango has framework and jjango we need to to handle with the whole stack But we are not adding a new one

Speaker 2: that uh is trying to hide this complexity by adding another layer of complexity. So it's tricky. Uh but we believe that it's most correct because it's simpler But it's not the most correct for all the context. Sometimes we need just to deliver a fast feature that it's built in in these frameworks, in the Angular framework. And sometimes it's better just to deliver that and then try to uh follow a progressive enhancement approach. We kind of call it the the balance between graceful degradation, which is when you deliver stuff and it's just worried about uh getting things done fast. And then

Speaker 2: we we go back and do the progressive enhancement into having this very same feature but in a more robust way Let me just add something. Uh it's important to consider your team in that decision. uh heavily. Uh I guess this is one one of the biggest learns uh of this whole process Because if your team are composed by people that uh handle very well or learn uh or a red-nose angular for example, uh that's what you have so go for angular and we we try to

Speaker 2: uh face the whole problem uh considering these uh aspects that we sometimes ignore the current knowledge we already have so it's important to consider that as well I'd recommend

Speaker 3: the other talk has started, so I'll see you right.

Speaker 2: See you. Bye bye.