Lighthouse transition journey : from warp to axum by Léa Narzis | Devcon SEA

[Music] thanks Mario and so I'm Leah software engineer specializing in Rust and you need to switch your slides here yeah okay no you need yeah oh no you need to I think I need to um not this oh okay I mean I can duplicate otherwise okay um yeah thanks for being here so I'm a software engineer specialized in R and as mayos mentioned um this project was in fact supposed to be a one week's maximum good first issue to start it in Lighthouse and not my initial project but as we are we are all developer and I think one of our defaults is like to underestimate uh developer time development time um so why um so I pick this project of course to go deep into a lighthouse and understand before uh better before transitioning um um to a more research project uh but as a developer was interest uh in big refactor um so why uh do the team wants to move um between warp and axum but first what is what is warp and what are axum so there web server framework creates in Rust and one has been developed a bit long time ago so is a bit low level um low level oriented and a bit less easy to use despite axum has been developed by the Tokyo team Tokyo organizations and a bit easy to use and why do they want to move um of course they want to move uh for easier fuse and because W types which is very focused on filter uh filter pries is a bit difficult to handle and also it's very um something you need to understand is like only one part is still using warping warp in Lighthouse and um all the other part are using axum so the idea of course is to unify but um one also important things uh in Lighthouse right now they want to have this modular up approach so they will size the opportunity um with this refactor to have a more for all the different Bon IPI end point um to refactor the function andler and then it will be easy to integrate in a new repository called etherum API where you can have a special tra Bon API and just referencing to this Lighthouse new end point and love um just to mention this is the most uh sexy slide I've been doing in my consultant career before uh just to mention as I've been saying only the Bon node API is targeting uh is targeting in this project um previous one previous one have other part are already uh a oriented um so refactor challenge um first intution is like to remove completely the previous crate a warp and just to replace by axum and to find equivalent but it was definitely not a good idea because we wanted a performance test before um before and to have a more soft s approach Pro and just say oh okay I want to use this new crate uh let's replace and not have any Matrix about it um so what we so very um very simple condition first to to test the different uh to test the different implementation something I didn't mention that the work was already initialized uh by the lighthouse C develop and so we could already test very simple endpoint that has been refactor in um in Lighthouse so we could do just uh performance testing and have um test by targeting with a certain number of requests and check and compare the differ uh performance time between axom and WAP end points so the result uh that is war is uh faster than axum and um probably because if you have most of the time if you have a also a crate that is easy to use it means it can be more interface and so it's most of the time um a bit slower also something just by curiosity I was looking at is it was that if the Tas spammer has an incidence of course it has one but the difference is very very important so our idea right now is to refactor um to have a better Handler on the Tas pammer um yeah we there are still a bit work to do to handle a bit in a bit better way the Tas spammer in the AUM Factor so still a lot of step to do as I mentioned I'm already working on it there are this optimization of the Tas pammer and I want uh especially from tomorrow uh have this great occasion to meet the lighthouse team um to define a very uh specific plan in the GitHub issue and have hold this transition issue um and any public um also any developer can take part of this um transition the more it is split the more it is better for anyone to take in and yeah just to deliver the task after and as I mentioned if we are refactoring all this endpoint Handler have they can be referenced uh in this ATM IPI repository um in the specific Bon API trade yet of course um EPF is not just about uh technical or atal knowledge of course it's maybe 90% what is targeting but it's a lot of personal Insight um as a developer I could have a better Vision how to have more manageable piece and yeah do what I called Baby stape um when you are doing a big refactor especially with Lighthouse rate a very huge res repository um work is not finished and there are maybe 80% still to need to be done um but I still have a better overview about a lighthouse repository especially this bigon IPI and yes M reflex as a developer um yeah thanks a lot to the EPF team uh for all the help guidance and to the lighthouse also developer team thank you awesome thank you very much laia and yeah as I mention um so there is all this timeline and as it is finished I can really start the fil implementation thank you yeah awesome thank you so much La yeah I appreciate it um