Application State & API

[00:00:00]
>> Evgenii: Now let's talk about the API. So our application is expected actually probably the let's first talk about the state. So our application is expected to work on the mobile devices. And we need to make sure that we use optimize stay structure. So let's think about what are the properties we can store in the state.

[00:00:24]
So first of all, I will store the stories.
>> Evgenii: And I would apply the normalization, the first and the second normal form, to optimize the story. So my story can be accessed by id of the string. And each story will contain the text content, which is string. And it also will have an id which is also type id.

[00:01:01]
As you can see, we don't have any content in this story entity related to the comments. So this means that we need to have one more field called comments. And here, we'll use the story id to give us an array of the comments, and also we'll store the attachments array.

[00:01:35]
So we can access all the images attachment that we're planning to utilize by the store id. Okay, this is the attachment array. So the attachment is pretty simple since we're just using the images we can use the simple URL for that
>> Evgenii: And that should be it. So now we have this state, let's look what are the API methods that we can use for loading the story data.

[00:02:07]
So let's create a new section called API.
>> Evgenii: And if we think about the API, then we actually need just a single endpoint which will getstories. And now we need to decide, decide how we're going to load the stories. So first of all, we could potentially.
>> Speaker 1: Sorry, there's a bunch of questions, but maybe you want to get through this section before we take questions or.

[00:02:39]
>> Evgenii: I think we can start with the questions now.
>> Speaker 1: Candidates said I would use react window for virtualization. What would you say to that?
>> Evgenii: I think it depends on your company. Because some companies actually prefer candidates to use some modern frameworks how they will resolve that problem with using the modern frameworks.

[00:03:00]
But on average, I think the idea of system design interview is actually, or evaluate the fundamentals knowledge. So if I would be evaluating the fundamentals knowledge, I would ask the candidate to be kind of framework agnostic. So we have just a Vanilla API, so what would you do with the Vanilla API?

[00:03:23]
Maybe I'm the company and I want to develop my libraries, and what would you do? Yep.
>> Speaker 1: And in this state, where do you keep the chronological order of the stories? Is it a list of story ids?
>> Evgenii: Because the story they come. So usually you expect that this list will be connected to some global state, and we define this global state here, so we can always provide the stories in a sorted order to the virtual list.

[00:04:04]
So virtual lists can manage actually the array of the data because it renders the array. Because we're rendering a very limited subset of the data, we can basically extract the ids that we are going to render from the global state and then sort it out by the timestamp.

[00:04:24]
So the thing is that the story right now doesn't have a timestamp, so it's very, very good suggestions. So we also need to have the time when the story was posted.
>> Speaker 1: When describing data structures, how do you know when you've gotten too deep into the weeds? For instance, if you're in this case, you could be debating whether to use a JavaScript object or a map, or sets and that kind of things.

[00:04:54]
>> Evgenii: I think, the map is actually the same as JavaScript object. It's just the very fancy wrapper around the JavaScript object. I don't think that you will have a discussion about the differences, to be honest. So I don't think it's very important for this specific design to discuss the difference between the object and the map.

[00:05:16]
Yeah, I would not focus on that too much.
>> Evgenii: Okay, so let's continue. So we design our state, we have the stories, the comment, and the attachment. Now we need to understand how we want to load our stories. And there are, as we discussed in the workshop, there are three ways how can we do that.

[00:05:37]
So the first one is we can use sharp pulling.
>> Evgenii: Second thing, we could potentially use web sockets and the third thing is service and events. So if we try to compare all of this, yep.
>> Speaker 2: Sorry can I ask a question? So earlier during the workshop, one of the things he talked about was long polling.

[00:06:05]
How would you differentiate between what's considered short polling versus long polling?
>> Evgenii: Okay, so the short polling is usually has the timeframe around 5 seconds is basically the short pulling you keep your TCP socket open because the time passed from the from previous request is not enough to close this by default.

[00:06:29]
You can also instruct the server to keep the connection alive but it's not very efficient from the client bearer perspective. So long polling, you always initiate a new full request, so you will set the full metadata. And usually the timeframe is around 20 or 30 seconds. So if we compare this method specifically for the fetching purposes, so the short polling will definitely work.

[00:06:59]
So it's very simple, it utilizes the HTTP protocol, it's very simple to implement. But the issue with the short polling, because it keeps your TCP connections, so TCP socket open, this means that we're having additional battery drain. So let's use the minus here, battery,
>> Evgenii: Drain.
>> Evgenii: Then it's not very efficient.

[00:07:30]
>> Evgenii: The huge pro is that it's very simple. But the issue is that you may have the latency. And the latency comes from establishing the full connection again, when you do the reconnection then also you pay additional cost on implementing the infrastructure to how to handle the reconnections.

[00:07:58]
So you may expect that the latency will decrease, especially when, you're on the fast train or when you need to reconnect to a network towers. The problem also with the short polling is because we are focusing on the mobile devices a lot, and the short polling will utilize the duplex antenna of the mobile device so it will drain the energy again.

[00:08:20]
So here we can put two minuses. [LAUGH] Yeah, so let's go to the WebSockets. So the WebSockets provides us with a real time communication. So it's super fast. But do we need real time communication to fetch the stories? I don't think so. So it has the very huge infrastructure cost.

[00:08:42]
It's very hard to implement in a good way. So I guess we can just remove the web sockets from the consideration completely. So let's consider the service side events. So if we speak about server side events, let's list the pros of the server side events. So first of all, they're very, very efficient.

[00:09:00]
And they also have a very comparable performance to the WebSockets. They are slower, but still they're pretty fast. Also, because they utilize the mono antenna of the device, we can expect that the energy drain will be much less. And also, the service side events are based on HTTP2 protocol.

[00:09:21]
This means that HTTP2 will be able to establish us the much better performance because within one TCP connection we can establish hundreds of parallel requests being loaded. Basically our application will be able to utilize just a single TCP connection for every request. So I think the service events in this case, we can actually use the combination of the service side events plus the simple GET request because if you scroll down, you don't wanna wait for the server to give you the result from service end events.

[00:10:02]
So we can just create a new, simple HTTP request via the GET and get the data. So the answer will be the combination of the GET request plus service end events. And if we think about the parameters that they get, stories can accept. So the first thing is the API token to access the server API.

[00:10:32]
The second one is the limit. So we need to distinguish the, we need to know the limit, how many elements we want to load from the server. So because, for instance, for the for large screens, we'll be able to load more items on the screen. For smaller devices, such as mobile, we may limit this to just five or four elements.

[00:10:59]
So this third parameter will be the previous page. So the previous page pointer will tell the server to load the data from specific place. So if we're returning, so we floated some stories then we closed our application and then we open it again. So we want to load the stories exactly from the place where it stopped.

[00:11:24]
So we'll be able to utilize the previous page. If, for instance, this is our first time we're loading the stories, then we'll just load the stories that are relevant to us with the current time step.