Engineering video
18:23 · 23 October 2024
JWTs are used to authenticate clients with backend services by including them in request authorization headers. Storing JWTs in HTTP-only cookies helps mitigate cross-site scripting (XSS) risks compared to local storage.
Hear it at 0:24 →Monitoring a frontend application involves tracking exceptions and stack traces using error tracking tools like Sentry, measuring core web vitals for performance, and using analytics tools for usage and traffic insights.
Hear it at 3:47 →The shadow DOM provides CSS encapsulation and isolation by separating a subsection of the DOM from the rest of the document, making it useful for component libraries to prevent style conflicts despite potential complexity and performance trade-offs.
Hear it at 6:29 →Hydration is the process of attaching virtual DOM structures and event handlers to server-rendered HTML markup to make the page interactive, though developers must avoid content mismatches like differing timestamps.
Hear it at 9:32 →Client-side applications can be deployed statically to blob storage with a CDN in front for low latency, whereas server-side rendered applications require compute infrastructure like containers or servers to handle rendering and scalability.
Hear it at 11:18 →hi folks D from the senior Dev and today we are back with Bon and we're going to go through seven senior front end interview questions we're going to cover a bunch of very wide topics from authentication all the way towards the shadow Dom and down to deployment this is for you if you are a frontend developer intervie right now and looking to get hired as a mid level or senior frontend engineer well our first question for today is what are Json web tokens jbts and how are they used for authentication in a modern content application so basically the question is what are Json web tokens basically jvt
so in the context of web out you use jvts to authenticate with a back end so as a client let's say I want to make some request to certain resources that are require some privileges I'll have to authenticate and authorize to be able to have access to that so basically when I send a request over to my back service I usually include in the authorization header a jvt and at the back end will verify that jvt with what we call an identity server so that would be a third party either maintain or purchase so let me just so as a client I include the jvt the back end will verify that in with the identity server and then return the
resources to me if I have access to them if I want to get a token I usually myself as a client would redirect the user to Identity server the user would authenticate by giving the credentials even that it's usually you know email password or a multiactor out and then they would obtain like I would obtain a token and then I would use that to exchange requests with a back end now can I as a client have access to that token well depends it really depends how we implement this but it would be not a very good practice to give the client JavaScript access to the jvt because of um cross side scripting attacks so xss
attacks what will happen is that attackers that are able to inject JavaScript in a client are able to read for example a jvt from local storage and then they could use it to act on behalf of the user so it's a very good practice to actually persist the jvt in an HTTP only cookie and so nobody on the front end is being able to access it as a client if I need user information I would just make a request to get user the back end would read the jvt and based on the jvt they would return me the user info which brings us to the second question you talked about storing this in an HTTP only cookie what would
be the difference if we choose to store our gbt token in local storage or any other way to store it sure so basically we have cookies right where we could store it we could store in local storage um or station storage but the thing with station storage is that it's not persistent enough it will be cleared when if I recall well when you close the browser window so it's not very good for a which we usually don't want the user to re authenticate every time they close the browser and local storage is accessible to JavaScript so an attacker could if they have access to or if they can inject scripts into our website
imagine somebody installs a Chrome extension that um it's malicious they could actually read the jvt so the best way is to do it in cookies and in this case HTTP only cookies and you can even make them https only and so JavaScript nobody's able from the front end to access them but they are able to send requests and cookie are automatically included in any requests we send and with those requests they are able to get back user data and then access any of the backend Services because they all carrying the cookie awesome let's move on to the next question and we're going to talk about monitoring a very Coe
topic to frent engineering as a whole Bon what tools have you used and would you be using to monitor a front end application and talking about monitoring what metrics would you focus on when monitoring a frontend application and why um so I guess my first question would be what what kind of frontend application let's focus on a e-commerce use case where you have product pages you have catalog pages in performance it's important SEO it's also important if it's e-commerce um the project I've been working on we probably need to first of all monitor for errors like if there's any exception and for that we
can use those like centry basically when there's an exception on the on the client side or so some user gets it we get an email and there's an alerting system in that so whoever it's on call from our team would be able to deal with that they're able to have stack traces they're able to reproduce the error it tells us like on what operating system it happened was it a mobile device and so on so that's critical that's a must have I would also probably want to have performance metrics in terms of what are the core web vitals we're exper experiencing so what is the real loading speed our users uh experiment when they
land on the page I would probably look for metrics like if it's an e-commerce website the first content of paint I would look for the spe index and I'll probably look for the cumulative layout shift and all those will tell us hey it's our application healthy does it load fast so these are the two most important ones and if we're doing server side rendering we also would probably need a server side monitoring component we basically want to monitor you know the Apu metrix as they call them that's the application machine metrix the CPU the memory and probably also want to know like request coming in request
coming out average response time this will be more backend Focus but coming back to the front end you probably also need or or our product or marketing would also need some analytics so I would look at something like Google analytics and uh I know Google analytics is not the best but it's indust standard and it's one of the easiest to implement so we're talking about Sentry then looking into Google analytics anything else you would add to the mix no I think if we have kind of usage and traffic analytics um covered we have our performance metrics and we have an alting system in place you should be
good to go folks for the ones watching us if you are a software engineer interviewing in the current market or if you're simply interested in getting better make sure you check out the free technical assessment that you can find in the comments where you're going to have to invest about 10 minutes of your time answer a few questions and you will get a full analysis on your tangle gaps and most importantly what you should be focusing on next to level up your skills to a senior level and Beyond now we're going to move on with the next question which is very specific very Niche to the front can you explain the shadow Dom
when and why would you use it sure so um basically the shadow Dom is a you can think of it as as an extra subsection of the Dom we can create to declare our CSS variables and the main advantage there would be encapsulation and isolation in the sense of whatever it's in that shadow dome it's not accessible to the rest of the Dom so we can easily use any kind of CSS class without having the fear of a conflict in a big application however um I feel like in production application it's not it's not so useful in our day-to-day work unless you're building your own component library and you want to ship that and you want to make sure
there's no conflicts with the global application the problem with the Shadow do it's usually it's kind of complex right it adds complexity it will decrease performance there's more work to the browsers to to interpret it it's also not compatible with all browsers so if you're using if you have users that use maybe Internet Explorer or older versions of the browser they might not be able to to use it and it cannot be really polyfilled right this is not one of those JavaScript features that you can just polyfill and you're done you can't really polyfill it and the other thing is I mean the shadow D would be
really useful if you want to make something look the same regardless of the browser so imagine you're building a drop down component usually those components they inherit a lot from the Native browsers so a drop down will look slightly different on Chrome than it looks in safari with shadow dome you really make sure you do not inherit any of those Styles you have your own Styles and it looks consistent but it's also more work on the developer because there's no inherit Styles so you really have to declare everything yeah I mean there are performance drawbacks but given the global nature of CSS as a
language where everything it's Global if we're talking about a microfrance scenario would you recommend using something like this shadow dome or what would be any an alternative right if we have different frontend applications that are building up together into one you know if there's one developer in a team that's using the same class as another developer in another team for a different service and those those micro front ends will compose in one big front end how do we avoid conflicts without using with and without using the shadow D sure so there there's different ways to avoid conflict and one of the easiest
is by using CSS injs basically your your module bundler will take up your CSS classes and Add a prefix or suffix or hash them all together into a unique hash based on your file PAAD and so there won't be any conflicts and I know this this CSS conflicts used to be a problem back in the days when we didn't have CSS modules but now with CSS modules and CSS injs it's just a lot easier to avoid conflicts without having to over engineer our front end so to be very honest unless you really need a you have a very specific use case like you're building a specific UI component you wanted to beig usable maybe you're
Building open source I do not think the shadow dome it's the best choice for you and it will be a lot of over engineer it's something new we need to learn it will decrease performance I think it comes with a lot of drawbacks and um you can solve the conflict name with CSS modules okay Bon on to the next question and we're going to talk about server side rendering so in the context of server side rendering what is hydration sure so hydration is basically whenever we finished rendering on the server we have our HTML markup and we deliver that to the user right so they see our web page and it's all rendered but they
can't really interact with it until we attach our um our actual virtual Dome and and even handlers to it and so if you're using any of the modern Javas Frameworks like angular or spelt or react or even View and you're doing server side rendering there it's always a hydration phase when we interpret the JavaScript coming from the back end and we attach that to the existing HTML structure so that would be hydration until hydration doesn't happen the page won't be interactive so the users can see something but they might click and nothing happens you get this click rage now how would you avoid issues with
mismatch content doing hydration so most of sa side rendering already have those things built in in and they have like hydration warnings but if you're hydrating you want to avoid things like using for example timestamps in your server rendered HTML because the time stamp on the server would be different from the one on the client so if you really need to generate the time stamp and show it to the user you can do it in a if you're using react you can do it in a use effect hook and you make sure it's only client side rendered and on the other hand you really want to use the same HTML client as on the server so it
kind of has to look the same uh you really want to try to avoid to generate or to ha any value when you're rending on the server because you might get a totally different value when you're on the client and usually this is something that us as developers don't have to care too much about it because Frameworks like nextjs solve it for us but it's good to know right whether you if you run into hydration problems it's good to at least be able to diagnose what's happening now we're going to move on with a question about deployment open scope question feel free to go as deep as you want but how would you deploy a
front end application sure so I think it pretty much depends on what the infrastructure we using um would you like me to go into depth into how I do it over cloud system or are we looking more at can can I pick whatever I want pick whatever you want but keep in mind let's say for example we are quite sensitive about scalability we start with a bunch of users but then our service and Company it's growing faster and faster and also I want you to think of going back to the Ecommerce use case if we have for example we we sponsor some commercials on TV and we have have some certain spikes of traffic how can
we also provision for that um sure is the application client side only or is there a server component like a server s side application let's start with client side first and then we can talk about the server side use case as well sure I mean if it's only client side then we only need to like do a static deployment so this is basically hosting some static files in Blob storage um like blog storage something like Amazon S3 for example let's put it that way so let me I would probably start with that if if we're running Amazon or whatever you whatever service you're running usually it provides a way for you to do that so
I'm going to add here S3 but it could be anything it doesn't have to be Amazon specific so we could upload our files there and then probably I would have some cidian infrastructure in front of it so I know Amazon has Cloud front and so basically Cloud cloudfront will sit in front of it and distribute this on an edge in Edge locations all around the world so we make sure that our users um do not have any latency so our users come in here they get redirected to the closest age location as they call it which is a location where they duplicate lot content and they can easily access it no latency so this would be the most
basic deployment basically some static storage with a cidn in front of it and in this case added S3 and Cloud front from for AWS okay Bon and what about if the application was server side rendered server side rendering it's a bit more complex because we need a computer we need a server that actually handles that you mentioned there will be a lot of users so if we have SSR as they call it we need some compute power so I know nowadays you could even Deploy on things like versel or netlify if you want to one click deployment and they have distributed compute but if you go for the traditional Cloud way you'd probably
need either an2 instance or a container running or in the worst case a Lambda function that will actually you know run when the users go in render our application on the server now still use S three in Cloud front for for our static assets so basically the way that will look like is that uh give me a second so basically we would have our users right that come in here that would be our server and basically our server will kind of so the users they come in here so our users go to our server but they will also be able to request static assets from cloudfront ns3 so we would still use that infrastructure but we
have a server and um in this case is I'll probably go for a it depends on the team setup of course um but in modern most modern teams have a container uh container system here where we can containerize and deploy something like farget or AWS I worked with those in the past or you could also go for something simpler like a Lambda now you mentioned it's an e-commerce so Lambda probably is not that good because there it's a starting time for Lambda so maybe you want to go you know traditionally with a E2 instances that have a load balancer and they can scale but that would be more like the back end kind of side of
yeah so you would go so you would go so basically with SSR you would move towards a more traditional deployment isn't as easy as just deploying your your bundle JavaScript as a static asset and and scale to the moon and back using a threei not at all yeah because it's also if you have users from different geographies the S it's usually located in one place so you add a lot of latency to their creation and what verel I think did and all those modern deployments for for server side Ender is that they deploy they distribute in the s cloud from distribute your static assets they distribute your compute but again it's
it's a fairly complex kind of setup it will definitely add more complexity to the deployment if we do server side ending one of the drawbacks of SSR just keep it in mind cool but final question in this serious give me an example of a tricky production BG had to fix and how you went about it tricky production BG okay so let me think well to go with the front example I think was around 3 or 4 years ago we were we were building a very heavy you can think of it as a widget component that was using a lot of data and a lot of it was um calculation data so we were giving customers like instant quote on a very complex uh
hitting system and what happened is I think one of the developers um was relying on the order of the elements in an array for a computation so we had an array of you can think of the mass prices and it would always rely on the second element being there and being a certain price and I think I spent around three days and one because um people were getting a different price in Safari than in Firefox and I think Google Chrome was the same price as Safari but different from Firefox and it was like impossible to know like we look at all the data that was coming to the front was exactly same exact same inputs
different price and I think what I found out after a while is that the order but the default order of the array was different in Firefox for some reason in some versions of Firefox and that's why um the array was totally different I think it was a a big um programming error there because whenever we have the we we don't want to rely on the order of things in an array if you if you really want to access something um and it has always to be that something you just put it in a key value pair in an object using an array there was misleading and I think it was around three days of work to actually debug the whole thing on the
client side TR to reproduce it and understand oh it's actually this array that's creating the problem yeah that's what I wanted to say it feels more like a malpractice in the back end and if you're back in engineer keep this in mind this kind of stuff can get you fired that that generated a production bug but there's an interesting thing out there that frontend Engineers have to deal with on a daily basis which is supporting different browsers and different versions of those browsers as well as even mobile clients like this is one of the why front end is so hard leaving aside the user user requirements
which are always increasing with that being said for the people watching us as ban did it's good if you're interviewing right now to have a bunch of stories ready whether that's a production bug whether that's a team conflict just write them down because they can come up in interviews and people want to see what you did about it what was the impact how you found the solution with that being said Bon thank you very much very interesting set of interviews forks for the one watching us if you're interviewing or if you simply want to get better check out your teal assessment and find out what your gaps
are with that being said once again thank you bam and we will see you folks in the next one
