Frontend Design System Interview - Azure resources application, 2024

Hi guys, in this session we're gonna be going over a design system interview question for a frontend engineer that was asked in 2024 by one of the FAANG companies. And this is what was presented. This is all this information you was given in the interview. Design a web app that displays all the resources in Azure. So I'm not really familiar with, with Azure. I'm more working with AWS, so, so I needed to verify a lot of questions for that. So also not given any UI, so you need to also talk about UI. So all the resources, for example, all the data files that you upload, so it can be all the dist files, all the images that you upload, any, any data that you work in Azure and have all your resources there. So you want an app that displays all of these resources in the table. So, but it can contain different services, you know. So it can contain— first, it can have instances, which is running servers or Okay, it can have just resources, um, it can have, uh, CDN data, uh, so it can have a lot of different resources that you use right now in Azure. And that was asked to design it to design an app that displays all of your resources. Okay, so in this question we need to ask a lot of questions. Okay, so we define our questions. So first we want to display, um, all the resources in table. Okay, display them in table, in table, yes. Um, second, but there is different type of resources. Do we want to display all of them together, or do we want to have like first the resources? I'm gonna I'm gonna have a little draw to, to show what I mean. So I'm just trying to, um, to understand what exactly required. So I'm gonna have a little draw. So do we want, um, first like kind of tabs that here we have like different services, for example, I don't know, images I don't know, not— I don't know really how much, how is it in Azure, but I know that there are different types of instances in all the cloud services. There is just, they're very similar, but they have just different types: images, instances. It can be, it can be allocated IPs. IPs. It, it can be, um, well, I would call it Elastic IPs because this is how I'm familiar in AWS. Elastic IPs. So this is the example what I said. So it's kind of, so you select the instance and then downstairs you have a table when in the table you have in every row you have a resource. It can be files, it can be images, it can be running instances, IPs, it can be Lambdas, right? So I'm gonna add Lambdas. So this is kind of example because Lambdas. So I would say it kind of can be empty. So the table is empty until you first, you choose the images, and then you can choose instances, and by what you choose, you receive all of them, and In the beginning, you can get, you can maybe have all of them, but then if you filter by type, you can get specifically filtered. So it can also be, but I just don't, I just don't see how it can be useful for someone to see mixed mixed resources because if I want to see something is that I want to see whether instances, whether images, whether— so this is what I think. So I think first you should choose the service and only, and only then you can see all this service resources because a mix of them not really helping me because I'm not sure. Well, um, I don't know, but I'm not sure. For me personally, I don't see how it can help for me as a user. So I prefer for user to select as a service, and then I will display the instances. Okay, so, um, we display them in the table. Yes, we can assume that this is per user. We can assume that this page is per user. Per user, yes, yes. So this feels like, um, like the main, the main questions. This is what was requested. Okay, so, so now we're gonna define our functional requirements. Functional requirements. Functional requirements. So the function is And for each service, user should get his resources. For each service, user should get his resources. And again, so it's, it's also per user, so, so I'm gonna assume that we have authentication, and maybe we can also see, um, different, different reasons, resources by, by roles. If, if we want this feature, um, that you allow, um, that you can create specific users, but I think in this, in this example we just want a user and we want authentication. And we want in the authentication, we don't want that any other user will get access, so it's— we should have security, security on a high level because it has our our instances and resources. And this is very important in this case, that no one has access to our instances, Lambdas, or resources. So this is pretty much the functional requirements. We should be— we should get visible all our resources, okay? So now we're gonna go to non-functional requirements, and I think I'm gonna move it a bit up. And disappeared. Okay, non-functional requirements, non-functional requirements. So Again, like in the previous videos, there are functional requirements that we should have for all the apps, and this app is— should also have these requirements. So we're gonna go quickly over these requirements And then we're gonna deep dive more into the question. So, so just a reminder, reminder, so we need it to be highly performant. So performance, performance, what we can mean by performance is responsiveness. So the app, so once I land on the page, I should get very fast all my resources. So responsiveness, responsiveness, also optimization, optimization, which means that our app shouldn't bring— should only fetch data by API only what it needs, and it should display in the browser only what it needs and not to do any extra calculations which will make the loading process larger. So we want our application be optimized, only fetching what it needs, only returning what it needs, only showing what it needs. This is about performance. Second, security. Very important. If you can imagine that all your resources is there, all your website, your, um, all your business information, all the data about your business is there. So you want to have high security. Three, usability. So you want The app that displays all your resources to display so it's easy to use. Usability, usability, which means accessibility, responsive design, high, um, easy-to-use UX. For scalable, we want it— we want this app to be able to scale as, as as many instances or resources I have, and we want this app still be responsive and high performance. So scalable 5. We have to have monitoring, monitoring in order to know if anything is down, if our user have problems or anything like that. Monitoring is very important. Um, 6, reliability. We want the app to be reliable. We want to know that if I have a resource that is running, this app gonna be displaying to me this resource that is running. So everything I have, it will display, um, it will display exactly what it promised to display. So the app is reliable. Every time I start the server, I upload any resource file, image, I know it will be there and I will see it in the table. Again, we'll see it in this table. So it's reliability, reliability. 7. Availability. This app is always available. Up and running, availability. 8, customizability and extendability. So if we want to add more services to display, so we want it to be customizable, easy to extend from UI perspective. From backend perspective, from database perspective, from a number of service perspective. All of this is very important. So the app should be customizable and extendable. And extendable. Okay, so this is the main non-functional requirements. If you ask to go deep down in every, um, on every point of this, of this list, you can go deep down. But as long as you mention all of these points, you should be good. And then it depends on how the question will continue. Okay, and now from From this, I will move— I think I will move the question here. Functional, non-functional here. And this is our design. And so now also, what was, what was asked in the question is So how would you, how would you manage the state for this list and how would you display the items? So, so what we need, what we need here, so this is what we need to, to show. And so what we need is we need API per service. So for example, in the beginning, by my design that I choose I don't want to display anything on the list until the user choose which service he wants to see. And this was my choice, you can also choose, make another choice, but I just don't think it's usable for a user. So at the beginning user will see just the services and then we will have API getResourceByService, service. So example of the service will be images or instances, okay? So we pass in a service and we're returning items. And also, so by service which will— so I'm gonna make it like this. So we're passing a service, service which is name, but also we're passing a size, how many, how many items we want to display. So also, how do we want to use the pagination, or do we want to, or do we want to use infinite scrolling, okay, because this is different items. But still we will fetch by size and here we will receive the, the items. And so you need to ask if it is pagination, then you just display at the size of every page, and then when user click next Next, you need to request, we can, we can also say start and end, and, and then from which per page, then we will fetch data by page. If we don't want pagination and we want virtual scrolling, we just fetch the size and then we implement infinite scrolling. So the question was to, to go, uh, to deep dive about— so UI, um, using infinite scrolling, using infinite scrolling, scrolling. And we need to describe how would you use it. So every time we will display the amount of data in DOM, um, in the user viewport, which means we will have a buffer. So for example, if viewport can contain 5 items, then we will have some buffer on top, for example, another 3 on top and another 3 on bottom. And every time user scroll up, we add items to the top and we remove from the bottom. Or if user scroll down, we add items to the bottom and we remove from the top. This way each time we have in the DOM, for example, 5, 3, and 3 plus buffer, 11 items. For example, it can be 20, it can— it's dependent on the viewport of the user. But for example, we will always have for example, 20 items in the DOM, and this number will never change. This is why the performance will be very high. Okay, so this is— we're going to be using infinite scrolling for that. And if we click instances, we're switching to the data, we're fetching data by instance, and then we're displaying items by instance. So here we will have— it's like a tab. And when we switch back to images, we, we already have the items that we fetched. And so now at this point the question was, but how do you manage the state? How do you manage the state? And I said we can, we can use a Redux for that. And this way we store in, in Redux all the items by images and all the items by instances, Elastic IP and Lambdas. And then like a tab, when we switch, we display the new items. And then the question was, but how do you know— how do you— how does the component know to display by type that the state is changed? And this question happened because, um, I'm working mostly with React and Redux and Context, and the interviewee was working in Angular. So in Angular, there is, uh, it's a different framework than React. So in React, you don't need to listen, um, components don't need to listen when the states change because Redux give it out of the box. So when you're using Redux, the component who use Redux, they subscribe to events. They know when the state is changing, the state that they listen to. So this question was not very clear to me, so I got, I got a bit lost because for me it was, um, it was out of the box. This is what Redux gives me. And for interviewee, it was a real question: how, how do components listen or know the state is changed? And then from here, from here, we move to the coding exercise, which involved writing Redux, writing Redux, a kind of subscriber to events, um, writing it in JavaScript. Okay, so before we move to the JavaScript exercise, I just want to recap on this design. So this was in the same interview, um, there was this question and then it led to the exercise, uh, writing a Redux component in JavaScript. So let's just do a quick recap, and I'm gonna move everything on the same page so it will be visible for us. So all, all the points that we needed to address, okay? So I'm just gonna move it. So here's— this is our question. Design a web app that displays all the resources in Azure. You need to, to understand the cloud and resources and understand what the user wants and you present. So you have the full freedom with UX. And so you need to ask the question pagination, infinite scrolling, What do, um, interviewers prefer? You need to ask the questions and you need to mention functional and non-functional requirements to show your understanding and to show that all the points, you understand all the points in order to implement this application. Then you talk about APIs that you create requests. Obviously, when— until a request is fetching, we display loader. And, and yes, and, and the main point was to focus on the state of the component and how, how other components know when the state is changing. And then it leads us to Redux. And now we're moving to implement Redux in JavaScript. Okay, so now we're gonna be implementing Redux. It's a specific version of Redux. So I'm gonna first show what are the expectations. Okay, so the expectation is for us to create a const, for example, um, stateManagement, new StateManagement. Management, which it receive value, for example, some kind of value which we can say hello. And then what we can do with it, so we can say, um, state management, um, change state to word. Okay, so it should change state and then, yeah, getState. We need to print word and we're not gonna do undo, but now we can also do state management, subscribe, subscribe. Subscribe to, to a function, okay. And, and we have, for example, we define here subscribers. We can const subscriber, which it will be— it receives a state and it console.log state, but we also and say that it's subscriber 1, for example, and this way we will know. So I'm gonna print subscriber 1 state. Okay, and I can do subscribe of this subscriber, and I can also do, uh, another one. Let's do 2 subscribers. Okay, subscriber2, and we have subscriber2 here, and we subscribe subscriber2. Okay, and what it returns to me is const subscriber1, subscriber1 state management, for example. This is what it returns to me. And the same with subscriber2, subscriber2 state management, for example. And then, so what I can do is I can change the state. Now when I change this state now to for example, uh, I don't know, Apple. Then what's gonna happen is we need to first see the state, but also what is gonna happen is that we, we should see that subscriber 1 and subscriber 2 were notified. And what I also can do, I can do, uh, subscriber 1 unsubscribe, unsubscribe, unsubscribe, but subscriber only, subscriber 1. And now I'm changing the state to, to coffee. Okay, and now what should happen is is that only subscriber 2 should be notified, okay? And this, this basically defines all the API that we need to do. And then we also do unsubscribe to second one, and when we change it to T, we shouldn't see anyone that is subscribed or unsubscribed, okay? So this is our implementation, and, and this is what was requested from me to implement in this interview. Okay, so now let's go ahead and implement it. So we're gonna implement a class, class State. Oh well, you, you can see that my lovely My lovely Copilot is autocompleting it for me, which is, which is great. And we're just gonna go ahead and talk about the state management. So we receive a state, this is a string in this case, okay, and our constructor stated the state and we initialize subscribers. Okay, we have a function changeState. Okay, and it's setState, but it's also notifySubscribers. Okay, getState just returns state. So when I have a subscriber, which is a function. Okay, so we adding, uh, we've had— we're adding a function to our subscribers, but also we return an object that have a function unsubscribe, and this function also can unsubscribe mySubscriber. And we have a function that notify all of the subscriber, which will mean we know that our function receives state and it prints it. Okay, so this is This is what was requested, and now let's run this and see. Subscriber is not defined. Subscriber is not defined. Let's see, where is it? Mm-hmm. Subscriber, maybe I need to Save. Let's clear, do it again. Subscriber is not defined. In which file? Okay, I'm gonna pause and check the issue for one second. Okay, there was some issue with the save, but the code is the same. One thing is that we need to put here subscriber 2, and I'm gonna run. So we see the, the world, and then we add subscriber, and then we change to Apple. So subscriber 1 and 2 see Apple. Then we do unsubscribe, and then we do coffee, and then only subscriber 2 has coffee. And then we unsubscribe the second one, and we change to tea, and then no one is subscribed. Okay. So this is basically how also Redux works, or how observer works. So they contain subscribers and then notify subscriber when state is changing, and you can also unsubscribe the subscriber. So this is what was required to implement in this design system interview, which lead— which led us to state management, because in Angular it is a bit different and you need to implement observer or subscribers, while in React Redux does it out of the box. And so yeah, that was a good question. I hope you enjoyed it, and let me know what you think.