Functional programming in Kotlin with Arrow.kt

uh welcome back to our webinar series about kotlin for the server-side programming and today we have a session about functional programming in kotlin with arrow kt uh that is going to be brought to you by simon and alejandro from um 37 degrees uh the the folks are pumped and prepared and uh this is the session uh which is a part of our three webinar series uh uh for like december edition it's the fourth edition that we are doing and uh you can see the uh previous sessions recorded on our youtube channel uh if you haven't subscribed yet please do uh we we announced next sessions uh on on these channels as well so you can subscribe and set a reminder for yourself not to miss the sessions and join us live uh so uh let's get back to our uh presentation and let's welcome simon and alejandro to the studio hello folks hi everyone i'm here welcome i'm really happy to have you uh we are trying to expose more information about kotlin libraries and arrow is definitely a popular one so i'm really happy to have you on this channel and uh without further ado i i would like you to you know to introduce yourself and start the presentation i think people are waiting eagerly for that great thanks simon you want to start sure uh so i'm simon uh i'm from belgium antwerp and i've been software engineer for the last seven years i started using colin in 2015 when i was working as an android developer and i very quickly fell in love with the language since the last several years i've been also using kalin and tooling and in the back end and the best known project that i'm working on is probably the open source project arrow but i'm also here to talk about today thanks uh yeah so i'm i'm alejandra i've been engineer for like a decade or so actually i've started doing haskell but uh recently i moved to start working on on uh kotlin uh working out uh the same company as simon at 47 degrees and yeah i'm i'm helping them uh making the arrow arrow library which has a lot of things which come from from like a functional background and also i'm working developing some coding compiler plugins which maybe if we have time i'll show you i'll show you at the end perfect so uh we already have a lot of folks commenting in the in the chat and uh i really encourage the crowd to actually ask the questions uh which we will handle at the end of the session i guess or well the way it flows maybe folks want to take the questions in the middle as well uh so heated discussions are welcomed in the chat and with that i'm i'm going to stay in the background i will be monitoring the chat but i will disappear from the session so that only two of you are presenting so uh see you in a few minutes right like in an hour yeah see you thank you so much anton great so uh let me maybe maybe introduce a bit you know uh both simon and i have talked about uh the arrow library and well even though it's gaining popularity maybe it's it's good to introduce a bit the library so so uh well uh we like to think of arrow uh as a library that complements that uh fill the gaps of what it's missing in some other parts of the ecosystem if you are if you are seeing uh well the website that's what i'm showing here uh we talk a lot about a companion library for other different libraries in fact arrow it's not itself one library is is a set of libraries i have here well the the main four that we developed so core which is uh you know what it's missing from from the standard library we have fx which is the same thing for the for the corinthians uh framework and then we have some others like optics which is uh [Music] things which are missing to better manipulate once you start using immutable data everywhere and you know what i'm actually working on is is meta which is the meta programming library which means is a library to to work over cod link code so it somehow uh enhances what the kotlin uh compiler api already give us and we are actually uh developing some some cool new things uh using this library so so using uh this library which is uh by the way in many in many in many ways it's it's inspired by by functional programming but as i say it's it's not itself that we want to bring everything which might be available in haskell or a scala it's just that we want to bring which makes sense and it's idiomatic in causing what what we think that enhances the the code that we that we write and today is an example of how uh you can use it with prepared a small a small uh web server example it's just an an an easy uh caterer based cater-based uh web server which just has a couple of routes and we are using there actually things uh from from fx and from core to to you know to show you how you can actually use these these ideas from the library to alleviate things which are usually more boilerplatey or are not that uh simple to to express without this library so uh actually now now uh simon will take the word and we'll introduce the project and uh the idea that he will talk about circuit breaker which is something quite cool you can do with the fx library then i will talk about how you can actually do validation in a more powerful way using arrow and as i said at the beginning if time allows with we would love to show you a bit what we are doing in optics and meta you know so that you know what kind of thing was working on so simon your turn all right thank you um so today we're going to look at katar project which is modeling an order service so first let's take a quick look at the domain uh of our backend of our microservice and as you can see here we have two data classes and order which has a list of entries and an entry is defined by a product id and an amount of in which you want to buy or order the specific product id and here we are using value classes to model product ids in a slightly nicer way and some of you might have read some of my previous blogs but this is very in line with domain driven design so we want uh model ws in our code to mimic as closely as possible the model that we have in reality and also in that required we want to talk about the product id another string so in the entry we can talk about a product id type another string type so then this domain driven design is something that you also might note from object oriented programming it's it's something that is agnostic uh from a programming paradigm and that's why i think this is also very interesting to briefly mention in kotlin that this line between open fp can become very thin as we will see today additionally alejandra also already mentioned mentioned optics as you can see here the optics annotation since we are working with immutable data classes we can either use the copy method which we can find from kotlin out of the box or we can use optics to work with immutable data in a more powerful way which will show in the end if it saves some time or perhaps in another or in the next webinar so let's take a look at our actual logic and which jump to the warehouse functionality so when we are working in our gator code base we are modeling uh use cases or functionality in terms of interfaces and the reason that we use interfaces is for example because the warehouse might be talking to a database or another remote api or it could also be a testable for example in this case the implementation of the warehouse is actually a testable which makes it very easy to provide stubs or test doubles for unit testing and doing things like test driven development where you might want to test your logic before you're actually talking to the remote api so again this is a practice that is also very common in object oriented programming and it's a pattern that is also used a lot in fp additionally here we also mark the function with suspend i mentioned before that this could be talking to the remote database uh or another remote api so marking it as suspend always gives us the power to models these things in the principled way there is another very interesting thing here in this file which is the validate availability function and instead of being a function inside of the interface it is actually an extension function on the interface and that is a very interesting difference because if you implement the warehouse interface you can now override the checkability functionality but you can never override or change the behavior of validate availability and that is actually something here that we want because validate availability composes the functionality of validation around the existing behavior in the interface and we are actually never interested in somebody being able to change or stop this functionality so by making it an extension function we can guarantee that this logic is always the same and it's only depending on the implementation of check availability so modeling functions in terms of member functions of an interface and extension functions on an interface have a very big difference on your architectural plans and it's very interesting to consider the difference so what is another useful thing that we can do with interfaces another very interesting thing that we can do with interfaces is composition so interfaces compose and here we can say we want to compose our interface billing with a data type circuit breaker and as you can see here below you can very easily do that with the decorator pattern and that's again a pattern that many people might know from object oriented programming and here we are using this object-oriented programming technique to implement a functionality or a pattern that we care about in fp which is composing the billing interface with the circulator data type so before we continue let's quickly recap what a circuit breaker is and why we need it no it's not so here in the main function you can see that we construct a circuit breaker and it's actually an important thing here because a circuit breaker is a stateful uh object which means that we need to pass it around and share the instance between between different implementations so what does the circuit breaker do and you know what's the point of using it so a circuit breaker is used to wrap uh functionality as we can see here we can use it to protect the processing building api and what it does is uh it will detect failures and depending on the failures that occur it will open the circuit breaker and not allow any traffic to come through sorry it will not allow any traffic to go through so when the circuit breaker opens it will not allow our function to actually reach the billing api and that is useful for example if the billing api which is a very crucial api in our system of microservices if it gets too many requests and it gets overloaded it's prone to going down and potentially resulting in a cascading failure of microservices which is something that we absolutely don't want so what can we do with the circuit breaker we can say okay if you see two failures in a row i want you to open the circuit breaker and not allow any traffic to flow to the billing api so when two errors occur it will use a reset period of two seconds to say okay if two second has passed you are now allowed to try and reach the billing api again and this prevents us for retrying or calling the billing api too fast when it's getting overloaded we can then also say okay there's also exponential backup if this keeps occurring and we can also see it set a max exponential back of time so if the service keeps failing and we can never reach the end point then it will eventually have a cooldown period of 60 seconds before it attempts again so let's take another look here at our billing with circuit breaker composition because there is a couple of other things that we might want to add for example we have here also a retry value so we also might want to say we want to recur on the schedule that recurs or retries for the amount of retries that we have and then we can say repeat this operation so now this function says uh we're going to try to reach the underlying billing api using the original implementation which was passed from the extension function here we are going to protect that call that if it fails too many times according to the circuit breaker strategy that it will stop reaching the actual billing api but if it fails we're going to say okay we will still want to retry if we have a single failure the first failure might be unrelated to the microservices going down so we might still want to retry additionally we might also want to say we want to recur the billing response three times and we want to do that while the schedule while the billing response is of type system error then we can say repeat this operation until the results sorry it's not uh yeah while the result is equal to the system error we want to keep repeating this operation so basically now we've composed this function to say i want to repeat this operation until i see a response that is not of the type system error and in case of in case of a failure we want to retry so in the case of a drawable and we also protecting our billing service by saying uh if too many errors occur while reaching the billing api then you need to make sure that we don't overload the billing api and it will not result in cascading failures i saw there were no questions about it this somebody asked will the slides be available as you can see we're in the live project this project will be publicly available after this webinar so everybody can see and look at the code um and now i'm going to pass the word back to alejandro who's going to talk about validation yes actually if i may add a bit about about what we've seen here so something also which is interesting is that uh you know the fact that we can uh uh that we can have this thing which which uh decorates the original thing it it's you know in a lot depends on the fact that we had uh the function marker suspend because that means that we have control over when we execute all of these uh the other uh thing that i wanted to point out is that uh if if you see we we are building uh simon was building a kind of complicated uh uh way to protect our apis or say try twice if it's not an error and then otherwise have the circuit breaker and and and this is one of the things we actually wanted to do with arrow have all these small composable blocks that you can plug together because you know uh maybe you don't need uh exactly the same combination uh that we are showing here but because all of these blocks are composable to just a block which retries twice and a block which retries until this happens and then by using this zip right thing we can compose both of them you can actually build your own thing which you know uh when i was introduced to the effects library i thought this was kind of a cool thing uh yeah but as samuel was saying uh i would like now to show you uh something uh which is a bit related but also uh a bit different is is validation and in this in this uh service uh as part well essentially that what we are thinking about the services that is that you know uh some some uh input comes with uh it's a service to order stuff so now essentially like a set of of product ids with the amount you want and then uh uh as a first step we will need to check that all of these elements uh all these ideas are correct that we have enough amount in the in the warehouses that what i'm gonna focus then you can imagine that once we know all of this is good we will just uh some all the all the prices and then it will go to the billing service which is what simon was showing so the billing service will take care of you know talking to a stripe or or whatever other api you use to to get this building so i want to focus now on the part in which we are doing the validation of the warehouse items and and and this looks like a a simple thing so essentially we have um one of these interfaces the warehouse interface is just as a call which will tell us whether there is enough or this product and whether this product exists but if you think about how you uh validate this this is actually not so easy because well uh all these validations are different calls and and actually you want to check all of them and if some of them failed you want to aggregate these failures you want to know which have failed it's not like you want to only check the first one and then fail you would in a nice system you would like to check all of them and and also you would like to do it with kind of maximal efficiency so you don't want to check them in order because maybe you can check them in in chunks of file you can make five calls to this warehouse and then you can well do it faster uh so this this actually uh by thinking about it it pointed out that there is one one uh notion which is missing from from the from coding to standard library and this is actually one of the gaps we filled with with the core thing and i wanna i wanna show you this is called validation we actually have this nice website by the way with a lot of tutorials and this is part about this error handling tutorial uh so what i was mentioning goes into what we call different validation strategies what we call uh failing fuss versus accumulating error so if you think for example about how uh the nullable types work that's a fail fast uh validation strategy at the moment you get a no and you keep doing things with you know your your elvis dot uh sorry question mark dot operators then the moment you fail then you are done you fail fast you get the first error uh but in many cases as i was mentioning here you have a list of different things you want to check uh different projects you want to check in the warehouse you want a different strategy you want to accumulate as many arrows as you want as you can and for this we've built uh the validated uh data type so this validated is it works essentially as as result as the result in the in the standard library but uh the crucial difference is when two things so when you compose two things which fail you record both failures somehow uh so we have here a big a big uh thing and and the main the main idea here is is this flip operation this zip operation is actually coming from how uh you know the name that that comes from from like haskell and a skylight that's essentially saying well take two different uh possible things that fail in this case we have uh an error which is whether our field contains uh the the add symbol and whether it's smaller than 250 these are two different validations that i'm i'm having here and uh if if they both fails or if any of them fails the result will be a failure but furthermore if both failure will get uh the two errors or in general uh what we want to do here is is uh is check for every element of the list whether these things uh any of this is faded so what we've done is go one step further even and say okay we wanna check this this uh this uh we wanna make this check over each element of the list but actually this check is not what we would call a pure check it's not like this well we just want to check something and we only look at the the value itself we want to uh we need to uh talk to the database this or in this case we talk to the warehouse api so sam if you could show the warehouse file again yeah so so this check availability is is uh the main the main function which will do the check as simon has mentioned with the financing interface so we can later uh in the test just use some some uh way to to to take this and run it in memory but in the real implementation we will actually check another microservice uh in our company and then we've built this validate availability which is just kind of a wrapper which in the case in which this fails it will give us an invalid and you can see it at the end so we we we like to use this this kind of uh kind of way to to write the coding which we say well what's the problem that's online 20 i'm talking about so what the availability problem is is the problem so you had a problem with this product and then we called dot invalid n e l to create an invalid so it's uh it's uh one of the possibilities of this validated type which is being invalid and if you see two lines above everything goes right we just wrap the thing on an entry and just call valid because well everything unwell so you can go now to the application.kt files that's that's the main thing uh or will witness just to quickly mention here sorry uh this nel here stand for non-mp list which means if there is any errors in the list there is always at least one present so here the main the main part is well if you see our process essentially uh checking a bunch of things and and we have these two blogs that uh simon put aside from line 57 which is first doing the validation of the structure of the of the order that's just pure uh validation and we are using some some cool techniques to implement this but maybe today there is not enough time what i wanted to uh here care about is what it's happening later in this in this order dot entries dot par traverse validated this is a huge it's a huge name which is doing a lot of things so the validated is telling us that we are doing this kind of validation in which we don't fail fast but accumulate the errors then the traverse in front of it is telling us that we are doing this for each element of my list uh and then the part is uh saying that actually this is going to if we pass a suspend function as as as an argument this will take care of actually uh doing this doing these validations in parallel and will actually take care of the complicated scenarios in which maybe uh you know you some of these fails so you want to uh cancel some of the things which were going on uh and so on so all of this logic is actually done in in one single function this part reverse validated and there you can see that the only thing we do is take our warehouse and call uh validate availability so you know i said i i like this function because it does a lot but it actually does what you want it to do uh and if there is any error all of this will just uh come and and and you know and and this will be the the you know this will be then actually uh this will be turned later into this other thing so uh talking about about uh how we do validation you could see too that uh yeah and simon knows what i'm going to talk about uh that that uh we call this we have this vine thing and this is uh also part of something with uh with well actually they've built with with arrow i wasn't part of this but it's a cool thing to know about is what we call a computation block so if if you could go a bit uh simon uh you can see that we have uh a big thing which says the result is an either thing and either is the name of the fail fast error type uh in arizona so we actually have a different theme because if i remember correctly result wasn't part of the sun library i don't know if it's still officially part of the continental standard library so just in case we have our own version called uh either which actually allows you to have anything as as the error type it doesn't have to be an exception type itself and and that in this block what you can do is different computations and when you end them in bind you are essentially saying please at this moment take the result of this and if it if it failed then the whole block is gonna end and it's gonna fail and and you can see that we have three of them so this is the the converse to the to the uh to the validated this is the the fail fast part and we have this nice way to to write this which is you can just have this block of one thing after the other and calling by just saying now uh take uh the result whether it fails or not and just you know make this fail fast accumulation uh the only the only thing you have to remember and that's that's maybe the only uh complicated thing is that for all of this to work you need to choose a common type for errors and we have defined it here this this uh but request uh type uh which is just what you know accumulates oh it's it's actu oh right yeah so we have the bad request which is just uh in this case a simple text content and and this is the information that we will uh have if we if we fail so so actually the reason that we're doing this here is basically for example if in this first piece of call you would say okay the order that we received was the incorrect payload then you you don't want to continue with the rest of the computation because the order that you received here was incorrect so here we construct a bad request that we want to reply on this incorrect order that we received and what happens here if we call bind the block here is exit with bad request and now we will come into this block where we say okay we tried to receive the order it was an invalid order so the result is either left of bad request and in that case we send the bad request back to the user without executing any of the other code because at this point it's not needed we already know that the result is going to be bad requests so um again what what we see are an and our approach with the whole uh arrow libraries again uh giving a small block that you can compose so so the idea here is is to give you blocks to express okay have this validation some of them have have to run one after the other some of them have to run in parallel and and then you can put all of this together so so i always found that that writing uh writing validation in this kind of style is would say more decorative so you express more your intent more than actually you know having just one one uh thing which just does the validation and returns a boolean saying yes or no uh cool so i don't know if there are any questions actually about about these two things um well i saw somebody asked a very interesting question about a circuit breaker uh some maybe if some other questions are still coming in about the validation part i can already answer that uh somebody asked how much work is there in replacing resilience 4j with circuit breaker and schedule that's actually a great question so resilience for jay out of the box also already has supports for suspension so if you're only using the circuit breaker uh then potentially there is not much worth in migrating from resilience for j to the circuit base for error effects unless you're already using arrow effects and you want to get rid of the redundant resilience for j dependencies since error effect solves the same problem but schedule is actually not the same as resilience for j retries because as we saw in the billing api example the schedule actually does two things it does repetitions and retries so for example here we're saying uh keep re repeat this function until you see a result that is not of error right and this is something this is a capability that if for as far as i know resilience for jay doesn't support it only works on troll balls or retrying strategies so schedule in that regard is more powerful than resilience for j so if you're interested in any of this functionality then yeah aerofx offers it and as far as i know resilience which it doesn't uh to quickly answer on somebody else's question somebody also asked for example in the case i hear the payload would be incorrect or something like that then we know making the call again will probably not result in a successful error because we know for example if it's a 500 then yeah there's probably something else wrong and retrying a 500 might not be worth it so here you could also say just like above zip right and then we can say schedule do while the error that we receive here it's not of the type is someone formed exception for example and then in this case if the exception that occurs here is of the type json formed exception then it will actually not retry right so in this case it will only retry for all exceptions that are not jsoml formed exception so here you can pass in any predicate that you might want to say okay for this exceptions don't actually retry because we know it's fatal i hope that answers those questions it's also another question which i guess is from somebody who has seen this kind of vine thing and you know uh you know that actually we've taken this idea for from escala's for comprehension and and and this and and haskell do notation it's that's where this is coming from and and you know this this uh these two languages have similar ideas built in the language you can essentially uh write code which looks imperative but it's translated into like a sequence of flat maps one after the other uh so why why not doing something similar here so one nice thing of of uh of using just buying this we do here is this is that that means that the whole language is is still the same it's not just an apartment which is in haskell or scala for example we are not showing it here but you could actually if your uh if your validation thing would be a number you could actually say run myfirstvalidation.bind plus run my secondvalidation.vine and it will do the right thing it will like uh return an error if any of those fails and otherwise it will return the sum of both of them and if you compare this uh with how you need to do it in a scala or haskell you have to introduce an extra variable because you need to write name of your variable back arrow uh whatever and then you have to introduce these two names only to call at the end x plus y uh at the very end so so this is i don't know i've always found this a bit annoying and and this way of doing this uh means that you are explicit in the point where this this uh kind of effect of failing occurs but at that point you can uh you can build the rest of of your code blocks essentially agnostic of these things so everything works you have maybe maybe you know maybe the plus example is just a very tiny small example but imagine where you have binds where things are actually buried one inside the other you for every uh nested call you need you would need to extract this thing and this is you know when you start refactoring all of these things this always gets in the way so that's that's uh you know apart from the fact that you can do it uh there is a reason why we uh prefer to use this style uh compared compared to the to the other style yeah and actually i think in general doing this with suspension is more powerful than uh but people are doing esco and scala for example to give you a super small example we can remove uh traverse for either by simply saying okay you can actually bind inside the map function of list and by doing this there is no need for a traverse operation because you can just write this in place and this is allowed because the map function is defined as an inline function so this bind is still occurring directly inside the dsl it's not happening inside of another piece of code in a stored lambda and this is something that i've not seen in another language so far it's also what gives some of the extreme powers of suspension of these dsls that we have in arrow well uh actually there is another question which i think you would be the best about yeah so far there is no alternative for that feature of resilience for jay uh but yeah i'm definitely interested in uh you know talking about it if there's interest for adding such stuff in the circuit breaker in arrow then please open the issue and we can discuss building this functionality further but currently it's not present i may add actually the code for these features is is not so big so you may even want to have a look at it and and and you know try to add whatever and we are open for contributions of course this is not the first project so i think we have time to actually show the cool stuff yes i mean the cooler stuff because all of this is great do we do you want to jump back to the browser or shall i show yeah let's show the meter example and then and then maybe you can start with the optics part yeah so you want to go ahead and uh yeah sure so so something here yeah so um so i was mentioning that one of the things we are we are actually pretty excited about that we are uh building a few compiler plugins for uh for the coding compiler and one of it is called arrow analysis so um so maybe we can just show what it does if uh we have this wrong piece of code that's that's line seven and eight and and maybe if you can if you can run it so so running it is a bit it's still we're still figuring this out so uh now we have to like run the gradle task uh by hand and so on uh but maybe in the meanwhile you can all think what is wrong in that piece of code it this is just something which which tries to figure out whether there is just one single product you know who just buys one we want to sell one more thing so uh so uh yeah uh so it it actually the compiler takes a time it's the same uh we are running just too many plugins for example uh yeah i'm also running too many streaming stuff on my machine yeah but you can see that at the end it has a very red message and it actually points out something at uh at line eight uh and it says uh it says uh the precondition index and i know what it says later but maybe maybe you can make the the the the and yeah i don't think i can oh oh all right so again so it it actually says something on the lines of of uh the precondition index without bounds is is not is not satisfies here so what we are actually doing here it's it's uh running some additional static analysis uh and and we have uh uh a precondition that we added uh by using this this uh plugin called arrow analysis saying well when you access an element of the list due to better access within balance because actually this this function it will will just uh write raise an index out of an exception if there is no products because in that case you cannot access entries of zero uh so this is something that our our uh plugin can can check for you and actually it it has all the information there and if you if you uh could go a bit a bit down simon in the right part if you see uh what it's cool and what we are excited about that we we were able to to uh add some some nice data flow analysis to this so if you have actually checked the right thing so you have checked beforehand is is my are my entries empty then the the problem is gone because this problem may not occur anymore you have already checked uh the case where entries is zero and you are doing whatever you want and then the compiler plugin knows okay in the else branch then it must be the case that entries is not empty so the access to entries of zero is is uh is one form so yeah this is the the uh kind of thing we're building and we are slowly trying to build more and more of this rule so actually that the this is like more of a generic uh way to attach laws we call it laws like pre and post conditions to functions that already exist or you have written and and then building upon this we we can ensure by running the analysis that everything we've done is right and and you can use this to check out of bound exceptions or to check things and and and what it's nice it's it's using some underlying reasoning engine uh to do this kind of things like saying okay if it's not empty it means that the size must be greater than zero so then the check of entries of zero is correct but you could also replace it with checking i don't know that the size is greater than two and and all of this reasoning is actually done within the within the plugin so that's that's one of the plugins we are we are building with this uh it's called the arrow meta uh library to which and we are trying to complement a bit what the compiler plugin what the coding compare already does uh you know doing all this data flow analysis for news and this kind of things which more and more knowledge about about how you do this uh maybe also interesting to mention that uh now you can here see that this is working already for a collins standard library since we've provided these pre and post conditions for everything in the standard library but also interesting to know is that alejandro also built support for the require function which is in the column standard library so any existing library using the kotlin require or the require not no function they will now also become compile time checks instead of runtime checks i think that is one of the really amazing features uh in this aero analysis uh plugin compiler plugin because it will also work on existing code that is already out there which i think is amazing and the other cool plugin we are building and simon will tell us a bit is is we mentioned a bit about optics this kind of uh thing which is quite nice if you want to uh work with immutable data in kotlin and you know we have copy and copy works for a bit and we actually have an example of you know how it you know stops being so nice uh if you need to go to many nested levels and maybe some of those are actually lists and so on so something if you want to talk about it uh before i'm gonna go to optics i see raul has asked an interesting question uh so to fill on what i just mentioned with the required keyword and alejandro already mentioned we can for example also define uh i'm not sure if this works also for a value class but we could define a value class called postpartums which is wrapping a primitive value and here we could now simply say in the init block that the value of the end has to be bigger than zero before it to be a positive integer and since we're using the kotlin required keyword which exists in the column standard library which error analysis also takes into account it is now impossible to create this value class with a negative uh integer so from here on out whenever you receive the value of type positive in you can always be 100 sure that the value inside is actually positive and this is actually a compile time check which is like a complete thing so of course the require it will run at run time so uh you can do it at run time but the idea here is turns as much of those things we could to the compile times so you know at the end of the day you don't even have to run the requires because everything has been checked at compile time and you know any other do it saying you you wrote a program with this program would actually not compile this program will fail with a similar error message as we saw before but stating that the value should be bigger than zero and it was minus one okay so i'm gonna very briefly show optics uh and specifically because i want to mention uh something new uh and it is a red now which i really don't like but let's show it here so many people aero optics has been a library that's been out there for a very long time uh up till now it was only supported on the gvm or at least the dsl functionality was also only supported for dsl we have now built the ksp compiler plugin so it will be possible to use aero optics with the multi-platform aero optics library to generate multi-platform optics with the ksp library as we can see here or actually as we saw in the original examples we annotate our data classes with the ad optics annotation and we also have to define a companion object and sadly we still have to manually define it like this otherwise the compiler cannot find it but if we have done so we can now use optics to for example rewrite this operation so in this operation we want to add one to the amount of every order of every entry in the order so we construct a new order and we map all the entries and we say every entry we're gonna take the amount and we're gonna increment it with one so how can we do this with optics and i'm not sure why my intellij is here showing red because i can show you that the code is actually here but my.j can for some reason not find it the code is generated and present so now we can access it like this and we can say okay we are interested in focusing through the optic into the entries property of the order data class then we want to look into every list item that is inside the entries and then we say we want to look into the amount that is in the entry so here we have constructed a value as it says here that focuses on every amount that is in every entry inside the order so to look again at the order data class the order data class has a list of entries right we want to look into every entry and for every entry we want to look into the amount and we then want to increment the amount by one so when we have our optic we can simply say modify using this optic we're gonna modify this order and we can now just simply say increment the amount with one and if we do this with the dsl we can actually let's see if this works so it should also be possible to write it like this which is the dsl functionality of error optics and it generates a code so that you don't have to work with compose or you don't have to work like this but instead you can get a fluid api with auto completion uh for all the properties that are available in the data class that's really too bad that i cannot uh get my intellij to find the ksp code [Music] yeah i think that's uh pretty much what i i had to share today i didn't see any more questions coming up is there anything else you wanted to share alejandro or i think you're muted alan you can read it yeah so uh yeah there was this last question about whether all of this is actually available intellij so we try to make today hasn't worked but usually with the optics generated code is taken by intellij and you can use it for the analysis bar we are actually uh waiting for this new uh k2 fear uh compiler stuff so we hope that we can actually share the code so it seemed to us that that was not so much so good to invest into because i will have to create an an intelligent plug-in and a compiler plug-in and and hopefully in the future from what we've understood we can just do it at once so that's our goal is actually uh once this new plug-in functionality is available to port our analysis there and hopefully you will you know you'll be able to get the thing both in gradle and and in the compiler so but right now you have to run it manually and then the error images appear there or you can run it through a github action we've done and then it appears as part of your uh github review functionality so uh and that i don't know if you can uh actually uh we can actually see the browser once again uh yes to you know uh you know uh tell everybody that that is there it's uh the the the library itself uh the core the fx the optics part is is stable uh it's version 101 right now so you know go and try and if you think that there is any gap which still can be filled and could go well with all this plenty in arrow just feel free to hang out in the in the in the coding slide we have a couple of channels about this and or in the github repo and and jazz you know tell us what you think and what we are missing other than that that was that was everything from our side that was perfect thank you very much and uh well i have one question from my side kind of philosophical one uh the demo that you have shown to us basically shows building the resilience into the application so the application itself knows how to behave depending on the configuration you have created uh how to handle timeouts maybe some errors and so on but today we have this containerized infrastructure with kubernetes with service meshes and so on where you can also build the resilience kind of in inside the infrastructure so what do you think how it all plays well together like building the resilience into the app and building the resilience in the infrastructure well there is uh from my experience there's always a lot of people in both camps but for example on my current project my current client project we're working with a lot of different kind of services and some have to be dealt with a lot more carefully than others so for some micro services the need for resilience is much higher and it's much more delicate than for other services and in that way they also apply a lot of different strategies depending on what endpoints or what services they are talking to and building it into the actual code like this seems for everyone to be a lot more straightforward because actually you can also see everything while you're working on the code you don't have to go to a kubernetes configuration to see what the circuit breaker and resilience configuration is for a specific uh function call that you're trying to make yeah that's that's what i felt like the domain knowledge is not always on the on the infrastructural side right you have to build it in into the app all right uh then well it was an awesome session thank you very much and uh i think we can add all the links into the description of the video that will be you know on our channel it's going to be there so we can just put all the resources into the description all the folks online uh thank you for joining us today and uh if you haven't subscribed please do no we have more webinars coming up and i'm pretty sure simon and alejandra will join us next year for more uh deep dives into functional programming and and arrow uh very happy to have you and have a nice evening and thank you for coming guys thank you so much thanks for having us bye thanks for watching you

Channel: Kotlin by JetBrains

Views: 2,699

Keywords: kotlin, webinar, functional programming, arrow.kt

Id: IDMmmrRhUvQ

Length: 59min 46sec (3586 seconds)

Published: Wed Dec 15 2021