ElixirConf 2021 - Joshua Plicque - Phoenix LiveView: Production Patterns

[Music] [Music] phoenix live view it's amazing alpha software cutting edge so cutting that sometimes it's almost bleeding edge because you are operating in an environment of maximum uncertainty it's not even 1.0 there's a lot of libraries that don't exist you have to write a lot of code yourself uh it is an amazing library it's a new paradigm it's not so new anymore for those in this room but it's effectively a new take on building software as opposed to like microservices or mvc it's essentially starting off with an initial uh html payload being sent from your elixir phoenix backend and then thereafter all the communication occurs over web sockets so with that being said let's move on to the next slide so i am joshua plick i have a small elixir consultancy in jacksonville florida and we specialize in phoenix live view there's just two of us uh just me and philip who's sitting there bald guy in the front he's waving uh yeah so i just want to give a shout out to the jacksonville elixir community micah woods he runs jacksonville ex or jackson x and hashrocket team they are out here just wanted to give a quick shout out to the jacksonville elixir community uh with that being said all this sounds good right like i sound um i guess qualified to give this presentation but i have to confess something to you guys i am a goon so what that means is throughout my career as a software developer i have been a hired gun a gun for hire a sell sword so i am uh here giving this presentation because i've effectively for the entirety of my career been paid to protect software pay to maintain software operating when things are absolutely on fire you've paid overseas developers a penny to develop your software and the next thing you know you can't even hire anybody to work on it this is the situation that i've always i've i've always worked in and uh essentially that's the that's the reason why i was able to choose phoenix live view and i'm able to i was i'm now giving this talk and i'm going to show you guys a bunch of patterns that i've developed that i'm going to bring over into new apps that i'm developing with phoenix live view with that being said i have a few goals for this presentation which is i'm actually trying to put a flag in the ground with this presentation as of right now there really aren't any production patterns so i'm making a bold statement here where i am actually going to try and and define what are some things that we should be doing in the phoenix live view community that no one's talking about and my goal for this presentation is for you to have an emotional reaction ninety percent of what i'm going to say in this presentation three or four hours from now you're not gonna remember but what you are gonna remember is how you felt so as i present each pattern i want you to just kind of log in in your mind like is it straight cash or is it straight trash and i want you to like i want you to build blog posts i want you to tweet about this presentation in regards to i thought you know minute time stamp 11 minutes and 34 seconds when he presented this pattern i thought this was bad and here's why it's because we need you i needed you a a year ago when i started on a phoenix live view application that we're going to talk about briefly i didn't have any i had very few resources so this flag in the ground is supposed to be the beginning of us talking about how we do things in the phoenix labview community no someone's clapping thank you yes so yes this is the beginning of the tribal knowledge and that's very bold and so at the top of the slide the question is like who are you like who are you how are you qualified like what's so special about you and so my my response to you would be very simple which is who are you who are you you tell me and so that the reason why we're starting with this is because this is supposed to be the backbone with which the rest of the of our community is going to define the patterns with which we go forward no one's going to remember me no one's going to remember this talk but with tribal knowledge as we build our our actual culture of phoenix live you how we do things that's what matters and let this be the flag in the stand so with that being said let me give presents with a little context so in april of last year a sales consultant friend of mine presented a client to me and said hey this guy uh he's got a company in jacksonville florida they deliver local grocery produce from local farmers in the area to your doorstep so of course april 2020 this is about two two months after coronavirus started sweeping throughout the united states and the reason why i'm bringing up this company is this company because they deliver local groceries to your doorstep they quadrupled their sales in april 2020 and so this business owner that i was talking to was ripe with new cash and ripe with new problems and so he essentially said i'm losing a lot even though i'm quadrupling my sales i'm losing people because my online store it sucks it's got a it's got a nine step process can you rebuild me an online store i was like okay sure no problem you know like what are you using and so he was using some off off the shelf software from a company that went bankrupt in 2016. so this company went bankrupt in 2016. they had they had no api available for their software so i went i went to my i guess my cave or and then i said to myself the only pitch for this online store is for me to rebuild this entire thing that they've purchased so i i went and i logged into the software and i reverse engineered the whole thing and i was like dude this is going to take me a year to build and um if i'm going to make a big bet like this then i might as well do something crazy i might as well do it in phoenix live view so that's essentially the decision i made back in april 2020 and i told this guy so a week goes by i go back up to the local fair jax founder and i say hey i want to build you an entire platform user sign up managing your deliveries all this stuff it's gonna take me 12 months to build uh this is how much it's going to cost and he leaned back he leaned back in his chair and he said uh so you want me to like bet a house on this like effectively i'm buying a house for this and i'm betting on you a guy i don't know and this is why i said i'm a goon guys you know that that was i am a goon i i looked that man straight in the eye and i said yes you should bet on this your business is at stake like essentially you're on defunct software so with that being said let's get right into it that's the context that we are um working under and so let's just start off with an anti-pattern which is tying data to your code everybody's seen this this always sucks when you like say we're in the ruby on rails community um everyone's opened up a new app and essentially you see a database query blow up in a view template which is bad right the reason why this is bad why is it bad to tie data to your code you know people say this but no one explains why the reason why is because data is fungible data changes throughout your environments when you're in the development environment i don't have the same code as the production environment and so when i actually download okay now i can hear myself um when i download this code base and i try and run this code the reason why the the code brace the code base breaks is because it's assuming data that exists in the production environment for it to work i need to pull down the production code base into my code and you shouldn't have to do that so let's just talk about the first feature i one of the first features i built which is uh the sign-in page the sign up page where you needed to put in your zip code to say that hey like i want to sign up for the software so the problem with this the business requirement is that only people you should only allow people that are within the zip code of the jacksonville area so that those people can only sign up for the app and so the way that looks is like this is the the list of zip codes in the jacksonville area that local for jax supports and if you're not supported then you get sent to this page saying that hey we're sorry you're not in our zip code here's our wait list and then otherwise it actually takes you to the sign up screen so with that being said okay i'm loud we need to break our rule so i was talking about all that went through that entire explanation of why you shouldn't tie data to your code we have to break the rule immediately because the business requirement demands it where only people who are in with certain zip codes which is a dynamic data set that means our data validations of members who are signed up for this app it needs to rely on a dynamic source of data which is the list of zip codes that i was showing you on that previous slide so with that being said um someone who's intelligent on uh might say that you know in phoenix labview there's there's two events that you're pretty much working with which is the phoenix change event and the phoenix submit event so if you're if you're typing each keystroke and you're validating against the the live uh all the zip codes in the database you're doing a database query on every single keystroke so this is actually what i saw when i was coding the feature because i needed it to work on dynamic data so every single keystroke is doing it that is doing a database hit which is horrible so someone might say like a smart person might say well then only validate the data on the phoenix submit event that would work because then essentially you just only val you only do that one database query on the submit event the problem is is that there are more business requirements in the sense that on this page there's a zip code here and there's a whole bunch of fields on this page so i was forced to not only break the rule but come up with a solution so our anti-pattern is not to tie data to your code but our great jose velene who i refer to as the goat in american culture that is an acronym for greatest of all time for our international audience uh so can we get some some boss in the crowd for our our leader jose dude he's awesome no no one's following me there but i mean i i truly believe that he's the greatest of all time because he's built this amazing community and uh anyway that's an aside let's get into it in regards to the code so here's what i did i created an agent which is an abstraction on top of otp where essentially on application startup on the start link it actually does a database query and has a list of zip codes that you can access so that when you're typing you're actually hitting this cache instead of hitting the actual database so there's also a function in here called reset cache can you guys see see these these um this code okay yeah so reset cache works where it'll actually of course re initialize the query meaning that at this point you're no longer doing a database query for every keystroke you're just hitting the cache on every keystroke which is free so for this to work you need to actually figure out where are you going to invalidate the cache so this code here is when you actually that slide that i show you we showed you with the delivery zip codes this zip code cache.reset cache function every time you do one of three things you create a new zip code or update a zip code or delete a zip code it's gonna bust the cache and re-initialize that query so now you have something that's living in in in memory because an agent the otp abstraction it actually allows it's a simple abstraction for allowing you to have state in a stateless language so that this is our initial pattern for how do you tie data to your code you make it a runtime dependency that's the answer and you um you manage your uh otp process via making sure that you are invaliding invalidating the cache at the proper time so with that being said here's the validation itself where it is actually a runtime based uh zip code cache and it's checking against the list of the zip codes and that's our first pattern how do you tie data to your code number one never do it number two when you do do it user use uh runtime dependency aware uh abstractions like otp next step next thing we're going to cover is actually doing wizards i think that somebody's doing a presentation at this conference on wizards i'd love to uh you know check to see if we have the same ideas in regards to how do you develop wizards in phoenix live view so the business requirement uh is of course that you want to save the state of the wizard so like of course a wizard online is like when you have a multi-step process you got step one step two step three step four there are multiple solutions that you could use uh you could store it in the session you can store it in local storage you can it's stored in erlang term storage or you can store it on the socket itself all of these things are many of these things are not available to you in phoenix labview in the sense that local storage is not available to you because remember phoenix live view runs on the server there is no local service storage on the server so then you might you that might lead you to the next thing which is okay well then we'll store it in the session well the websockets the websocket protocol does not have support for accessing the session so you can't do that so there are hacks around it there's a guy named torin billups who i think is speaking here or he gave a training uh presentation where he talks about how to access uh the session store but it's effectively a hack and so that's i mean no disrespect to him you will see a hacks that i did to achieve certain things but remember this is an alpha community i'm a goon and when you're a goon you have to get the job done and that's by any means necessary with that being said the next step is earlying term storage so the problem with earlying term storage is if you actually have a server restart like say you um deploy new code erlang term storage that data is going to get wiped out what if the user is on step four of this long process and you wipe out the earlying term storage because you're doing a deploy this is really going to lead to a bad user experience storing it on the socket you know that's another solution that you could do the problem with storing on the socket is that if the browser disconnects or if the user has bad internet connection that person is going to lose their data the whole library is going to just get wiped out so these are the reasons i'm telling you all the reasons why all the things that i went through of what not to do and the simple solution is store it in the url you store it in you if you stored in the url you you're protected against uh server deploys you're you're protected against everything like it's it's long lived within this within the context of the person filling out the form so side note uh if anybody's new to phoenix live view uh this is a shout out to chris mccord and other people on the phoenix live view core team i just wanted to talk about how phoenix live view protects you from those browser disconnects so this is actually in the phoenix labview docks this is uh really cool uh incredibly clever tech in the sense that recovery following a crash or disconnect so when you're why so the way phoenix labview works is there's two mounts the initial uh payload from the server gets downloaded as html so it's actually serves as a mvc controller initially your live view at that point once you have that front end your javascript then creates a websocket connection to the back to the phoenix backend and now you're communicating over web sockets from uh from your browser so at that point if that that that uh that connection can sever because you might run out of internet or you know your wi-fi socks so the way uh phoenix live protects you in that situation is uh when your live view reconnects to the to the socket it actually uh submits a phoenix change event so it that then goes to your um to your live view and it will actually load the state in your html back onto the socket so it's incredibly uh clever technology so uh i know that's that might be something that people are scared of so that's it's already built into the framework so it works out of the box um yeah so i'm just showing you the the wizard process here's step one step two step three and four for signing up for local fair jacks and uh we just discussed that none of the initial solutions were good enough we should save it to the url so the question is how do we save ephemeral data to the url and the way you do that is with a sub technique called schema let's change sets and we're going to use just pure ecto so a schema-less change set is a change set that actually doesn't get saved to the database so schema list meaning that schemas are coming from it's an ecto macro and instead of using that we're just going to save it to a map instead so that's what you see with that at types and then you pass that into the cat uh to your change set function and effectively you have a a database store but it's just a map instead of like your actual database database being your mongodb postgres or whatever back-end so that's what we start with we start with the schemas change set that defines all the attributes that we're going to be saving in our sign up process so you'll see package id add-ons ids these are just concepts within the local fair jack software so with that being said here's where it gets really interesting uh so you actually can can ensure that the va that the data remains valid in all your single steps because you can just keep piping the change set from step one to step two step three to step four and essentially if you're on step three and you need to confirm your data before you go to step four because you're piping in all the original change sets you're validating all the way back through the beginning of the process and the way this actually works is ecto has a function called apply action so this is what it does under the hood whenever you do like a repo dot insert or a repo dot update under the hood it calls this ectoapply.insert that's what that is actually what returns you that okay tuple or that error tuple you get the error tuple if you if your validations aren't valid and if you if your data is valid you get the okay tuple and in this case since we're using the schemas change set we just end up with a map so what can you do with a map well you can just pass a map to your to your parameters in your um in your url and then the phoenix router knows how to process your map and so you always have valid state that is uh resist that is resilient against uh your your websocket getting disconnected or server deploys it's uh i consider this an elegant solution i think that this is a a really cool pattern and i'd like to hear you guys feedback on this eventually so this i just have a link to the apply the apply action docs in ecto this is essentially that's the whole okay versus error tuple thing that i was discussing and then you just tie it up to a case statement so uh when you do save step 2 that's going to do that ecto apply action that i was talking about going to get an okay or an error tuple and then you can then redirect to the next step so you see that with the push redirect that's going to push a redirect on the on the socket taking you to the next step and then in that params when you see map from struct you see sign up step three path we're going from step two to step three and then we're grabbing all of the stuff on the change set from step two so it's a very elegant solution very robust and um yeah so what if you end up in the state where you're at step four but then for some reason someone changed something in the url that invalidated something from step one in your mount callbacks you can essentially just check the validity of your change set and then it'll re so say your step four change set is invalid it'll redact direct to step three you have the same code in step three it'll see as an invalid it'll redirect to step two same code in step two and redirect to step one so now you have yeah it's a i think this is a really cool solution so yeah like to get your feedback let's move on to the next thing so this pattern that i'm going to show you next is really simple but it shows you how powerful phoenix live view is so like i was telling you about how phoenix live view works with that initial html downloaded the payload and that second mount with the with the socket so i have a very simple feature here where we were just redirecting we were telling the user that hey your zip code is valid and then we're showing them like a splash screen and then you're redirecting to another page so you typically do this in javascript but you can use erlang or you can just use basic otp stuff to do this because each live view process is a at the at the end of the day under the hood all it is is a erlang process under the hood so what you can do you can see my code right underneath right underneath beneath the i'm talking really fast i'm sorry i'm actually already 26 minutes in and like we're just getting started so um yeah i'm talking fast but i mean we're getting there so right underneath the definition of the def update function you'll see that i see process that send after self self is a reference to that phoenix labview process itself so you'll see i have a at timeout variable that's just effectively just an integer where i've got it in the test environment i've got it set to zero in production i've got it set to 500 milliseconds so essentially you load that page up that we just saw which is this and after 500 milliseconds the or ad initially the live use triggers that it's going to send a message to itself after 500 milliseconds it then retrieves that message and then it's processed here in this handle info com callback saying that hey i want you to redirect so we're just using basic structures to achieve like really cool behavior that you would have had to use javascript in the past and we're doing all with backing code and we can write tests against it and it's really easy to do testing in javascript is hard and frustrating testing in the elixir is easy and it's fast along those lines testing faster i don't know if isaac uh there's a guy that we both follow each other on twitter i know you're here isaac are you in the crowd can you raise your hand isaac my man you know what i'm about to say next i was uh doing what i normally do on twitter say about six or eight months ago which is talk trash and um i was talking trash about the phoenix live you test suite and i'm saying holy crap my entire app and this is true to this day the entire local fair jacks app cause remember i told you guys it's go it's a year-long build the entire test suite with 95 coverage runs in under 10 seconds on a macbook pro that is incredible that's insane so i was talking trash on twitter like at this time i don't know um the test suite was eight seconds long and i was like oh phoenix live view is amazing it's the test suite so fast and then isaac uh or yeah he jumped in the comment section and he said have you tried async true on your con well this is a really simple flag and so yeah you should send me bitcoin that's this is uh because i'm saving a lot of companies a lot of money with this in regards to test suite speed and because it's an exponential effect when you when a test suite becomes faster it has exponential effects throughout your organization because it runs faster on ci and it runs faster on all the developer machines there were times when i was working at previous companies we would finish a feature we'd run the test suite and everybody would get up and go grab coffee because we knew it was gonna take 20 minutes so hey like you know i got time so test suite gains are are huge for organizations in regards to as you make it faster you have exponential effects uh yeah all you have to do is add an async true to it and it'll actually run all your tests on all your cores it'll paralyze your test suite and run it all your core so isaac told me about this and my test suite went from like eight seconds to three seconds at that time and yeah so go do this anything with and this works for uh anything with a with a case after so you can do this for your your unit test in regards to ex unit um uh data case yeah data case con case an ex unit case you can throw a async true flag it'll run on all cores of your machine and your your test suite you know assuming you have four or eight cores you get between three to eight times gains so that was a long explanation for a very simple slide but that's very valuable send me bitcoin everybody like i like the clapping yeah like the mid presentation clapping thank you yeah so like i was mentioning testing in live view is bliss the entire uh with massive i'm a testing nazi very dogmatic about testing and with 95 coverage less than 10 seconds of testing time so moving on to the next pattern uh let's just talk about javascript right so i have another thing to reveal to you guys uh after 12 months 13 months of working on this application the application for local fair jacks has exactly 217 lines of javascript so the the promise made the promise made by chris mccord to that you don't have to write javascript it's effectively true there's a little bit of custom stuff but with 200 lines of code let's just consider that negligible to all the elixir code i've written you saw the whole process that send after there are pretty much abstractions and tools and like patterns that you can use to achieve everything with back and elixir code which is easy to test fast to test fun to test because the phoenix live view test actually um the api the the dsl the domain specific language is so easy to use there's even there's an open browser function that you can use and it'll actually just launch your browser in the current state and you can just like easily um debug what's going on what's wrong with your live view so with that being said you want to make sure this is some this is a very simple suggestion but you're going to go through a lot of pain like i and philip both have if you don't do this if you're doing some custom javascript you need to do a phoenix update you need to around the surrounding div of whatever you're doing in javascript you need to put a phoenix update ignore flag around it the reason why is because phoenix live view is going to wipe out your dom and essentially anything that you had any javascript that you had loaded is going to get wiped out and so you want to tell phoenix live view with the phoenix update ignore flag hey like ignore this this div i've got this i'm going to run this in javascript so this is on that same sign up page at the very bottom of that step 4 step i've i've got like this really cool credit card feature as you're typing it it shows what you're typing on this credit card just something that i thought was cool and uh yeah there's that this is the phoenix update ignore essentially telling phoenix live you hey leave these divs alone and phoenix phoenix live view hooks so whenever you do have to reach for custom javascript which as i've told you with 200 lines of javascript it's very rare phoenix live view has a bunch of hooks like the mounted callback and the updated callback similar to react or any of the other front end frameworks of today and tomorrow because we all know that there's another one coming out right now um it will you pretty much have a an infrastructure for setting up your javascript code and making sure that it plays well with with phoenix live view and so you see that at the bottom of the page with the with the credit card where i'm actually initializing the credit card with that that hook you just saw the code on the previous slide it doesn't matter what it is it's more about the idea you if if anybody here is like bearish on phoenix live you oh it's not even 1.0 i'm not sure i'm here to tell you relax it's ready it's ready for prime time when is 1.0 coming when is 1.0 coming because phoenix labview is ready for the big leagues yeah so 200 lines was that right 217 okay i lied it's 200 what is that 215. so i lied it's actually less so let's talk about authentication so this is something that i actually hacked so shout out there's this guy on reddit i was uh talking about so one of my concerns about phoenix liveview is authenticating your live socket so of course on the browser remember there's that html uh hook that happens and then of course there's that websocket hook html is easy right you just you check the session make sure that the user's user has a token in the in the session store um just standard authentication the problem with the websocket there is no access to the session so i had concerns uh about this that i've made known on on reddit um oh yeah in general phoenix genoff uh this has been added to phoenix and one uh in version 1.6 just use it it's it's amazing like it's made by uh jose villain the goat man he um he was on the um the rails core teams and all that stuff but he also was a core contributor to the device authentication library in uh the ruby ecosystem so he's very qualified so you should um he created or he helped with phoenix gen off to make sure that it's valid and secure just use it it's going to make your life easier you're going to have access to all your authentication code it's not going to be abstracted away from you in some library somewhere else all the codes can be in front of you it's going to be in your app easily making it easy for you to make changes to it so warning there is going to be hacky code ahead with regards to how i made sure and ensured that our phoenix live view socket side was always authenticated so i created this post on reddit go to it and upvote it if you want to where it says hey how do you reliably authenticate a phoenix live view so it's got 32 up votes so there were people here if probably here right this is probably the best of the elixir community right um who upvoted this this is clearly a problem uh that needs to be addressed either with he's probably just need to be addressed with a blog post i didn't know what to do so i asked hey like i know that i can uh reliably authenticate on the html side i want to reliably authenticate that nobody has improper access on the websocket side so that post lives here and this uh i don't have i didn't give credit to the person darn it okay someone on reddit responded with a really interesting meta programming solution where uh in your app you just add an options flag to your using your using macro inside of your um your your app underscore web.ex whatever the name of your app like for me it's localfairjacksweb.ex you bolt that on to the using macro and then this chunk of code it doesn't nest you know there's a lot going on here um essentially what this does is it bolts onto the mount hook so any any of your phoenix labviews that require authentication you're actually going to need to write an off mount function so that's actually what this code does is you don't use mounts anymore under the hood it's going to call mounts when you use off mount and so essentially you have the the peace of mind the reason why i like this code is there's peace of mind in the sense that if i don't write off mount my stuff's not authenticated and my live view is gonna blow up that what this code actually does is it actually blows up in the development environment so that it forces you to write that off mount function and so you have the certainty of knowing that all your live views are uh properly authenticated so i don't necessarily want to dig into the details of this uh just go view the link in that previous slide if you want this is a reliable way to authenticate your live views i know michael crum was working on uh introducing more of phoenix live view hooks oh this is the off mount thing i was talking about essentially where instead of writing mounts in your live views you have to write off mount or it will just blow up um in phoenix 1.6 there are new live view server life cycle hooks that are now available like there's an on mount callback that means that maybe this code this hackie code's not necessary anymore but this led to my piece of mind this is what i was saying about the this is the flag in the sand or the flag in the moon right like the neil armstrong picture like i don't really know what the best solution is for this i have one that works uh there may be better ones in the in the future go ahead and tweet at me okay uh the next one that we're going to talk about we're going on almost 40 minutes at this point um i think i have this and one more after this which is uh mocking mocking an elixir is not as intuitive as coming from the ruby ecosystem it's so easy to just mock out an api um but i have a consistent pattern i actually stole this from the uh the programming phoenix book of how to mock out an external api so remember this page where we're actually creating um we're taking in the user's credentials so this actually makes an api call to a payment processor called authorize.net and i wanted to write tests against this like i told you guys i'm dogmatic about testing i wanted to write tests about this but i didn't want to hit authorize.net in my testing environment so what do i do so this is the code that actually authorizes that card and puts it on authorize.net you'll see that there's an at payments uh module variable and that actually talks to an environment variable called local fair jax payments so what that means is i as the way i have that defined is uh there's a gringotts mock there so local fare jacks and as long as it fits the same uh implementation in the sense that as long as you have a module that has that implements a def authorized function you can flip it out like that initial file was config config.exs and you'll see that i have a commented outline where sometimes i do want to flip it and like i can redefine it where i can actually throw it on authorize.net to make sure that it works but essentially i can now configure the module with which calls the authorized function change it in the development and test environment and call the production authorized module function in the production environment this allows me to inject my own module i guess this is a dependency injection in a functional language so i'm injecting my own module that allows me to have control over what that authorized function does now it's an e this is the pattern that i've used over and over for mocking uh out api calls in phoenix live view slash elixir projects so here's my mock uh where i essentially uh gringotts it's just a payment processing library shout out to whoever made the green gox library i've used it a lot thank you and um yeah so this is me just stubbing out a response and effectively it does what i was saying earlier which is um it flips out the module that you're using hitting your mock in the test in the development environment and hitting the actualproductionauthorize.net library in production this is easy mocking in phoenix labview so actually that was it so that's 40 minutes of uh production patterns uh i i guess we'll open the floor i don't know if anybody has questions about or comments on anything or any problems that you're having in phoenix live i'm open to answering anything right now i like the the first the first pattern of having the data cached versus hitting it every time right a different way and i a particular handler you just snapshot the monotonic time and then you balance it like you would normally do in javascript or something right okay yeah so another solution uh to what was your name andy was was talking about how i was doing caching for the the anti-pattern of tying your data to your code and he was saying that phoenix labview has debouncing support where you can actually ride a debounce flag on that on the on the input and so what you can do is you can you can throttle it where it'll only hit the phoenix change event every 500 milliseconds or what andy said 300 milliseconds this will reduce your because remember that the problem was that it was doing a database query on every single keystroke with the by throttling it down with debounce you can only you know it'll only trigger the phoenix change event every once in a while so that is an excellent uh not as invasive solution as mine my man in the back with the with the beard uh oh that's a great question so what was your name so anton was saying that uh when you actually in in the mocking environment when you're flipping out your uh test environment slash development environment library versus your production library how do you make sure that the production library works so um my suggestion for this is to use the the text the tesla elixir library because it has inherent mocking support where you can actually if you go to the github.com i don't know who wrote it slash tesla read me it actually in the in the docs or in the readme it it has mock it talks about how to mock out api calls at the url layer so essentially um if you're not using an external i i was using an external library library gringotts so i could there was nothing i could do um i just assumed that it's tested in green gods but if you are actually making the api calls yourself in your code if you i suggest using the tesla http client library and that way in your test suite all you have to do is like it's just a flag at the top of your test um use tesla.mock and then it'll actually blow up in the test environment when it tries to make a live api call and it'll tell you hey go mock this and it'll go market meaning that you'll get 100 test coverage but then you'll actually have a um a payload that you can define yourself in the test environment that you can um just throw fake data at it and then you get 100 coverage and you have 100 confidence in your results yes sir uh i guess i'll okay one more question um dang it okay my man with the hat okay all right one more question go ahead so you're talking about your concern um that gets delivered with the templates in the front end and then you have the session for the user i'm i'm not sure if you see that pattern i still have an off hold and if you do i don't understand what the hole is uh so what was your name mickey yeah so mickey was saying that what was my concern with authentication with live view sockets so this is more just me being uncomfortable because i imagine that if there was a hole with phoenix labview authentication uh if the problem would probably already be fixed so this is i guess like a sanity check for me because i know that i'm uh that i'm authenticating on my html side i just don't know if i'm doing on the socket side so um i do know that phoenix labview does uh require your csrf token so you can only connect so essentially i think what okay this mickey was leading me with that question essentially saying that when you connect to the live socket it sends your csrf token from your browser to the back end so it can only come from your app and you can only be in your app if you're authenticated on the html side so essentially mickey's saying that you're tripping so that's that okay

Channel: ElixirConf

Views: 1,710

Keywords:

Id: jCtIDbU23lI

Length: 40min 22sec (2422 seconds)

Published: Fri Oct 22 2021