 So, I am Amarjit Singh from engineeringteamoflipka.com. So, basically today's talk will be about how we deliver a solution for ebooks, so that they can be rendered on web browser. So, it will be more of a implementation kind of talk where other talks were like UX and product sense of a particular application. So, this talk will be quietly focused on the implementation part of that. So, as the name suggests, it's a book plus browser, but actually we'll be giving the examples specifically to the disimplementation, but we'll be talking the problems in general. Like if you are developing a common web application, what are the things that you should take care of? What are the implementation options that you have? And which one you should prefer all the others, and why? So, starting with that, so thinking about, I mean, what is it about? So, basically it's about like, say if you are having a ebook, so there are multiple ebook readers available in the market, like on iOS, Android, Windows, you'll see like iBooks, Kindle. These all are the readers available for the Android, iOS, and Windows thing. So, if you are delivering a solution to the browser for the same thing, what are the problems there? Like it's absolutely fine for the app native application, like they have a usage of a lot of memory they can use. They can directly use the processor thing. They do not have any foundation provided by the browser itself. So, they have a much freedom there. They can use the cache right by the, I mean, so they can use the storage directly. So, basically what they can do, they can download the book to their local storage and they can use it. It's very simple for them, like they can directly, I mean, go from first page to 100th page because complete book is there. So, if you think about the same scenario in another web application. So, they might be the same things, like you are having a, say, any store kind of application where you are selling something and they are, say, 1,000 products in your, in your catalog, fine. So, in, if you are developing a basic native app, so they might be a scenario all those products. Some of those products are already in cache or already on the local storage of the, that particular platform. So, in that case, I mean, developing the app on that particular device and developing the app on web is completely different. You do not have such privileges. So, I'll be mapping one to one these examples that I have faced during the development of the web reader at Flipkart and to the generic things, fine. So, it will be mostly regarding the architecture of a web design. So, you will be having a various modules in the web application, like security layer, UI layer, and client-db layer, and data transportation thing. So, how should we target? What is our problem? How much data we are transferring? And how much client-side work we have to do? What are the possible solutions to that? And which one we should opt for, okay? So, just as I said. So, I mean, initial part of the talk will be like addressing the problems first, okay? So, basically, I'll be telling you what are the problems that we have faced in the, say, developing the eBook reader, what are other problems that everybody will be facing in the developing the web application. And then I'll be taking you to the example of real implementation of that part, how we achieve something. And then I'll be giving you some technology related aspects like, yes, this is a kind of technology that can serve this kind of purpose. So, let's start with the eBooks first. So, I'll just brief you about the, so that you have the context of the talk. I'll brief you about the, what are the possible eBook rendering solutions that can be used on the web or any application. So, eBooks basically are used as a EPUB plus PDF format. So, one is a format called EPUB, other is a PDF thing. So, EPUB is something like, it's basically a zip file. So, it is having all the HTML, all the images, CSS, and all the resources stuff. Fine, so it's just like a web page that is local to your machine. Just you click on, say, some index.html page and it is referencing all the resources from there. So, EPUB is mostly like that. Where PDF, you all know that PDF is a set of commands that whatever document format that tells the render that I want to draw, say, a rectangle here, I want to print this text here and there. This is something about PDF. So, when we were developing, so if you're developing a reader, so you never know about the customer use case. Some would say, I have iPad. Why would I need a web application? I'll go to the iPad and I'll read every book there. But, especially in India, you'll see the customer base for the laptop and desktop is a lot. Plus, academic books are, I mean, they mean a lot. So they can be a real source of your getting from startup to a real established product. Okay, so you'll see a number of students are reading the books on the laptop and desktop things. So you need a web solution for that. But, there is specific problems to this thing. So, as I told you, it's a zip file and you never know what could be the size of a book. It can be from, say, 500 KBs to hundreds of MB. Fine. So all the native apps, like iOS or Android or Windows app, they will be downloading the complete book at once. They can't do that. So basically, what they are telling the user, just download this book once and read it after that. Fine. So this will be no pain for the user. Yeah, fine, I can download it once. But if you are making a web solution, you are telling every user every time that download the book again and again. This is not a solution. And same problem that you can have in other apps as well. Like, so say you are dealing with a store kind of thing only. And there are, say, 1,000 products in your catalog. You are never going to say, yes, I will downloading 1,000 products at once. You'll be using some approach like some pagination caching kind of stuff, some chunking of the responses from the server so that it can be rendered fast. But the problem was a little severe in this case. The reason is, so this is a basic structure of an EPUB as I already discussed. So the reason what is the problem in chunking of an EPUB or a PDF? Is this, it is using a number of resources. Fine. So a book might be like, it's a zip file. But say, first chapter is using a resource from, say, that is also used from, say, 10th of the chapter. It is a possible scenario. So what will happen in that case? So basically, you have to take care of all the resources should be served with the chunk itself. It should not be like some user is reading on the first chapter, is not able to see the font, is here for reading a Hindi book just because the font is not there, he's reading it some other language, which is actually some fresh thing. So managing the resources is one of the problem. Other thing is something that is very cool with the native app is annotation thing. So annotation thing is like, whenever you are reading a particular book, so most of the user would like, yes, I want to bookmark this thing. Or I would like to highlight this thing. I would like to make a note out of it. So these kind of things. So again, if you are chunking something, if you are breaking a book, breaking a zip file into some chunks, then you are always having this problem. Where should I go? Where should I sync this thing with other things? So you need some kind of sync platform in between as well. Fine. So then there is a high chance that what should be the corresponding solution, like I'm a user, some user would say, I don't care if it's a web app or a software. You gave me this platform. I want to just download it once and read it after that. There might be a scenario, say, you are in a matter of fresh, I mean, you are not having a very good network. You would say, yes, from home, I'll download the book. I'll come here and read it, meanwhile. So there is a possible solution they are asking for is offline solution. So basically, if you are developing web apps, you would know that today we are having some option to make an offline thing, like we are having HTML5 application cache. We are having this web SQL thing, index DB and SQLite. But all these are in very new stage. And so you will be taking care of a lot of stuff, like some browser support SQLite, other sports, index DB, so all that stuff. So we will be looking into that as well. So again, I told you, is this problem with this app only? No. Actually, this is the problem with most of the apps we'll be facing these days. So the presentation that I'm showing you is build on a web application as well. So that is slide is, it is slid.es. So if you talk about this application only, so say I'm changing something, and meanwhile, I'm off the network, what will I do now? I'm not expecting to be staying on internet forever if I'm refreshing the page, it will go away. So there should be some backup scenario in meanwhile, like say, if I'm changing something, it will be in my store, in my say, local browser's database, and that it will be syncing to the server. If that kind of solution is there, your customer will be really delighted. So it's all about delighting the customer at hand. So you can, I mean, map n number of problems with the n number of web applications with the same problems. So how we should approach these web applications? And so if you talk about the generic web apps, these are the basic problems that any web application will be facing. Like, so if it's a web application, say it's a thing like Stoke Exchange. So Stoke Exchange, there will be a huge data that will be transferring, say, 10 times a second even. So price fluctuation will be there, so data has to be transferred, and it has to be synced at max level. I mean, there should not be any delay. So if that is the case, there will be a huge data to be transferred. So then you cannot expect every customer to be on, say, 16 Mbps or 32 Mbps connection. It can be on, say, Edge. How you'll be dealing that? So browser can't process this much of code. So if you see, you never know which browser or which machine client is on. So you might be expecting everybody on a Mac machine or with a 8 GB of RAM, but it is not, actually. So how you decide how much data should I compute on the client, and what rest should I compute on the server? So drawing a line in between is very important here. Then there is a content security. So if you are making a web app that deals with, say, payment transactions, or some, say, with the credit card or the debit card of the user, you need to provide the credentials from the client to server, or the simple thing. If you are dealing with the book only, no publisher will going to tell you, yes, you can transfer the content itself directly. You have to use some kind of encryption, decryption, kind of stuff. So for that, I know that if you are asking about a security from the web app, it is actually a lot. You cannot hide anything from a web app. But still, there should be some level of security. And what is that level where you are satisfied? That level has to be maintained very well. And what are the options that we are having in JavaScript to use these things? Like you are using some, say, AES encryption on the server using Java, PHP, or any other language. They have a lot of libraries available there. But if you are talking about a JS solution, they are very few available. So I'll talk about a library called CryptoJS. So CryptoJS is a library provided by the Google. And it deals with a lot of security-related stuff, like they have the implementation of AES, SHA, and AVK, and all that stuff. So it is a very well-stable library. And as I told you, I myself have tried encryption, encryption, and vice versa using Java, and then to the CryptoJS, and PHP, and all that stuff. It really works very well. So it can be handy if you are talking about this kind of security solution on a web app. It can really help you there. And it's absolutely fine if you are saying a user that, fine, man, you are running my web application on a browser. What else are you expecting out of me? I'm delivering the content in 10 seconds. But actually, this is not the solution that you are providing to the user. You should take care of every step. So caching, how you will cache a content. Caching is not only the content that you are storing on the storage itself. So it is absolutely fine if you call it to a particular service, and response time remains the same. But it does not look same to the user. What is that? So say I'm reading on a particular page in a book. Fine. As I told you, I'm sending a chunk responses. I'm reading, say, first chapter. As a user, it will take, if he is actually reading, it will take, say, 10 minutes for the user to download that. I mean, to read that. Fine. So if I say, as soon as the user will go to the last page of the chapter, then I will download the book. Say, next chapter. Then it is like, user will wait for, say, next one minute or two minutes for the downloading stuff. But meanwhile, what you can do when user is spending 10 minutes of his time, when he's reading the first chapter, meanwhile, you can cache the next response. So some kind of tricks like that, that is actually not a, I mean, technology thing. It's just a smart code that you are making like a user should not wait. They are always a number of solutions. It cannot, maybe, that it's not feasible by the technology, but can be feasible with a smart move. As I told you, the difference between mobile apps and these web apps are like, they have a privilege of going to the, storing the content, storing to the directly use of the, all the resources that a web, all the resources that a mobile have. So it does not have any foundation like browser gives to us. So, oopsie, so again, internet goes away. Sorry for that. So basically, say, this is a basic thing that I was targeting about. It's a EPAP reader for web. So it's a web reader provided by the flipkart.com. So basically, what happens just now is I just tried refreshing that page. So there are a lot of books in my library. But as the internet is not working, so I'm on the offline thing. So this is a very much problem that a user can face. Fine. So this book might be like, it might be as long as, say, 5MB. But actually, means to the user is it's just a book. And if I bought a book from you, it should render in, say, two or three seconds. Fine. So if it is on, say, online thing as well, I'm here. Fine. So if I am noticing that if a user is actually reading, he will spend some time on this page. What will I do? I'll cache the next page. And so on. But what happens if a user goes from here to, say, here? You can never expect, I mean, you can never cache every possible scenario like user can go from second chapter to the 10th chapter, from the 10th chapter to the 15th chapter. But if your response is chung in this case, you are not sending the complete thing at once, then you are again saving a lot of time on the client side. So this is another use case of this chunking of the HTTP response or whatever kind of response you are using. Other thing is this client side database thing, as I told you. So what you can do is like, say, I'm downloading this book. Fine. So when I'm downloading this book, as it's a web application, you have to take care of all the cross-browser things and what are the web storage things that are provided by one browser to the other browser. Obviously, it's a new thing to the browser. So you have to take care of, I'm supporting these browsers and I'm not supporting these browsers. But it's always good that you are providing something to a particular section of the client if they are ready to move to the new versions of the browser. Rather than telling everybody, yes, we do not provide an offline solution because every browser is not supporting it. So what I think is like, we should go for at least majority of the people rather than going for none. So like, say, you are searching something. This is another trick that we have used here. So basically, what you can do is like, these days, browsers are actually very fast indeed. So they provide you a lot of computation skills as well. But again, that is specific to the machine to machine. So you have to consider everything. But you can do some kind of tracking as well. Tracking is absolutely fine with the product sense as well. But tracking can be done for knowing the machine that your code is running on. Based upon that, on runtime, you can take the decision. Yes, my server is on heavy load, but my client is having, say, very good processor there on. So it can actually, if I move my code from server to client to render, because it's JavaScript, it can also compute some of the things. If I can move my code from the server to client, it's absolutely fine. Because I know my client is very enough of doing the computation in time. So now I will, so basically, as I told you, these are the problems and these are the solutions that we have, how we have provided there. So I'll be talking about the technologies now. I mean like, available libraries and all that stuff. So one is that I came across this phantom.js. This phantom.js is basically a headless browser. So what it does is, it has this V8 and WebKit thing for rendering the HTML and computing the JavaScript thing. So basically, what you can do is like, you can give a, say, actual HTML thing with, say, you say, run this JavaScript on this HTML thing. It will give you the exact output as a browser does. So what you can do with it? So in this case, say, if I need to make the content fluent, so I would need that. It should be rendered on the browser so that I can see that this thing is renderable. And I need to take care of this in Crunchrunk and how much height and width it's taking. All that stuff. But if I do all these things on the client, what will happen? It will take a lot of time. It can easily hang the browser. But this thing you can easily do offline. Offline as in, not on the runtime. What do you do? You can use this library to render all the things in offline ways, offline as in, and the user is not accessing it. Process it, save the things, and then use it. So now your problem space from, say, 100% is narrowed down to 5%. And your client has to deal with only 5% of that. What is the other use case of this phantom.js? So these days, all the web apps will be using the Ajax stuff. Fine. So basically, most of the stuff will be transferred after the page load. So what happens, these kind of scenarios, if you are talking about the search engine optimization, this will not help you. Like, a Google crawls your thing, and there is nothing in there, so that it can index, or most of the user, if they are searching for something, they will not find that there. Because the content was not there when the Google was crawling it. Fine. The reason is, it will not run your JavaScript, for sure. So how to tackle that scenarios? So what you can do, you can check for the show. It sends you different HTTP agents, just all the crawler things. You can check for the agent, and then you can say, OK, fine. So what I'll do, I'll pass the complete code to this page using phantom.js. What it will do, it will run all the JavaScript for you. It will give you the actual HTML out of it. Now you give this HTML as a response to the crawler. Fine. So now, now crawler knows actually that these are the things it can index. So this is a very good, I mean, helper in these kind of scenarios when you are talking about the SEO thing. Other is the content security. As I already told you, using the crypto.js, it's a well, it's performance is actually very good. So as you target the server side things plus this JavaScript solution, actually it is very comparable to all these things. Next is using server for high load work. So I'll give you example of that. So say there is a thing that as a developing web application and if you target every specific area, say if I am checking for the course stuff of the website, it's a, yeah, my servers are very not on that much load. They can process on behalf of the client. In that case as well, you can use this phantom.js thing to process, to pre-process the page that you're going to give to the user and then give the pre-processed thing to the user and then it will, I mean, that will be partially processed for sure. Then it can process the next thing and your page rendering time will be much faster as compared to the other one. Then there is a, how you identify the task and categorize them. So it's like, if you are, I mean, before starting the developing of a particular web application knowing that, yes, these kinds of scenarios can happen. This piece of code, this piece of work would need a lot of computation. Can I do it offline? How will I do it offline? What are the things that I would require there? Can I partially process it? All that stuff. You should take care of these things first. Before I'm starting developing, starting developing everything on, say, client first. Then you see, oh, it is not helping there. Then you move to the server. So there can be an intermediate solution as well. There is another very good solution provided by, so if you have used the templates like handlebars, so handlebars are templating language basically. So basically what it does, it has their own syntax just like any language. So it says, yes, this is the if condition. If this if condition matters, if model have this thing, then render this HTML and put the values inside. If else, do this thing. Fine. So I'll give you a very good example with that. So say, all of you would be using REST clients these days. So REST APIs are like, they can give you the complete HTML as well. They can give you the JSON as well. So say, I have an API that can give you, that can give me the exact renderable HTML or the model that I can feed to this template to get the complete HTML. So there are two scenarios there. Fine. So say now I know my client is heavily loaded, it can process that, it cannot process that, but my servers are very free at the current scenario. So what I can do is I'll make the call to the server, that other API, which is giving me the exact HTML out of it. Fine. And I see if client is lightly loaded and have service is heavily loaded, I'll ask for the JSON. The same template will be available on the client side and I'll put the model to the client side and I'll generate the actual HTML out of it. So handle bar do this very well. So what they have is they have a, so saying you have some hello dot HTML file, which is having the handle bar template thing. So you can pre-process that template. It will generate your JavaScript out of it, which is just a function call. You just pass your context and your model to it and it will give you the complete HTML out of it. So basically what you can do, you can directly move this JavaScript file from the server to the client and let the client do the processing for you. So there is like, there is too much data to be transferred. So first of all, we should always think about, do I need every data? Is every data useful for the client at once? Can the client wait for the, I mean say two seconds? So consider a thing like you are having a scroll stuff on your page where say you are showing say it's a browse page, fine. A browse page will be having say a hundred of products, fine. But for a client, you know only the 10 of the products will be visible at first go, okay? So you make a decision. I'll give only the 10 products as soon as he'll reach the end of the first page, then I'll ask for the next page and I'll render that. So try thinking about the other solution before going for yes, this is the final thing I have to send to this client. There is no other way. So we have to make these decisions offline as well. Then there is a new thing to the HTML5, these are web sockets. So everybody is actually excited about that web socket. What are these web sockets? So web socket is basically a two way communication between the client and server as the other sockets are. So basically other ways you have to continue to be pulled to the server. Yes, do you have anything to send? Just like a store exchange thing, as I told you. So it needs say 10 calls per second to the server checking about anything change, anything change, anything change. So server cannot tell the client directly, yes, something has changed. Now do the processing. You have to do callbacks only, early to the web socket. So now web socket is giving you a two way communication thing. So if you open a socket between client and server, server can send you the data. And then client can make, yes, I got some kind of message, I need to process this data and all that stuff. But before directly diving into the solution, like I want to use web socket, that's it. Just because I want to learn it. This is not the correct way to produce, I mean go to approach to a problem. So consider this scenario, I check the performance with this thing. So say I am delivering the online reader. Online reader as in client has not downloaded the book, he's just directly coming to my site and then clicking on the cover page, he wants to read it online only. Fine, now if I give the web socket thing there, what will happen? I'll open a web socket that is using the server resource for sure, because I'm opening a socket between client and server. A user is there to read two pages. He's a very slow reader and he reads two pages in 10 minutes. After 10 minutes he goes away, he goes away. What happens? My source is consumed for 10 minutes without any use. Just because I said, yeah, I want to use web sockets. So we have to figure out how frequent I'm sending the data. Does this require actual two-way communication? They might be a case, it is not requiring two-way communication but still the results can be good. But what is the rate of data transfer? What is the idle time that you are letting web sockets to be open? You make a web socket for one hour. That means you just reserve the resource from the server for one hour. Out of one hour say 50 minutes the socket is idle. What is the use of that? So we have to make these decisions. These decisions are specific to the problem. So say, if you are downloading a book, so internet is not working, otherwise I would have shown you that. So if you go to this webreaderflipcard.com, there will be books with the download icon there. You just click on the download icon, it will show you the progress thing. So all the chunks and everything will be getting downloaded on the client. It will be sending to the client machine. So in that scenario, so this scenario is completely different to the online scenario. Why? The online scenario was like, in 10 minutes on average, I am sending a particular chunk, that is of 10 KbC. But in this scenario, it will be like in two minutes, I have to transfer 10 mbs of data. What is that? So in that scenario, if I checked, so it was like on a average connection, so sorry. So when you are sending the web socket, when you are making a web socket between client and server, the server is sending some packet to the client. So you have to, first of all, you have to make a particular number, average number, that is always making a web socket busy. Fine. So say I push five messages in two minutes to consume the complete bandwidth of the socket. I need to come up with a particular number. Fine. So that I do not let socket to be idle for most of the time. But again, that depends on the bandwidth of the client. So you have to try with a, say go with the three packets at once, go with the five packets at once and try to come up with a particular average number that yeah, this is fine. If I go with this number, I will be not wasting the web socket there. Fine. So I tried to say five packets at once with web socket. So basically I am sending five different data at once from server to client and saving that to the client machine. Say like that. So if I'm doing that, it was like, I achieved four times performance as compared to the simple HTTP request I was making. That was really good and good stuff. So basic point is, basic point here is like, you have to make a call if you are using a particular thing while you are using it. It should not be like only the learning purpose. It should also serve the product purpose. Then there is this client code measurement and speed. So if you are a front end developer and then you'll obviously notice that thing. You started developing something. It was having say 10% of the features. So most of the time you'll have it from the product guys like we are making this product but at the initial stage, we just want the 10% of it. So you write the code as per the 10% of it. Then you see, okay, now we are going to the 20%. Now you write the code from 10% to 20% and this thing goes on. So in the end when you see your code itself, you'll see, oh, it looks like I haven't wrote this code. Actually you would have not wrote that code basically but it was a step by step process. So you just forgot about taking the time care of the next steps when you were on the first step. Okay, so you will end up saying, yes, why I'm rewriting again. I wrote this function earlier on. I wrote this class earlier on. I can reuse that one. It just lacks say two or three features that are required in the new thing. So basically what I'm saying here is we should picture the complete thing once. Picture the complete thing once. Say what are the use cases? According to that, architect your UI thing as well. It is not like JavaScript. So basically if you have learned this JavaScript for the two days, you can write JavaScript. It's that simple. Write a function, declare a web, use it. It's that simple. So most of the times it will be like but if you are developing a web, there is a quite different between the website and web application. So web application code can grow like exponentially. So you have to take care and you have to think first then start coding it. Then this JavaScript MVC. So basically MVC is something like model view control thing. So that helps you a lot basically. Managing the code, that was the first thing. Second, I gave you example of this handle bar say. This is very well managed using the MVC. Just have the MVC thing on the client as well on the server. Let the things talk to each other. Let them decide which way they should go like. Should I use server thing or should I use the client thing? So there are a number of frameworks available for the JavaScript MVC as well. Then there is a new thing. This is web workers. So web workers like earlier on the browser was just giving you one thread to process everything. The reason was quite straightforward. It was just like you are dumping some HTML page on the browser. But nowadays it is not like that. You are doing a lot of computation stuff as well on the client. So if you are doing computation stuff, there might be a case you do not need DOM. DOM thing. I mean you are not interacting with the HTML elements, but you are doing some computation stuff. If you are doing some computation stuff, then you can do it in some other thread as well. This is web worker. What is web worker? So, but important thing to take before using this web worker is like you should divide the task. Say I am making a feature. There is a view of this feature. And this view is actually interacting with the DOM, with the HTML elements. This is the computational part. So I get this response from the server. I need to process this response. Then I need to feed this response to the view. So that part feeding the response to the view is only possible in the DOM. So you have to be on main thread. But on the other hand, if you are converting that partially computed thing from the server, you can do that computation in the other thread as well, because you are not dealing with the DOM. You can go away from the main thread. So at that time, you can go to the web workers. So the best approach is like, you should divide the things first, then start using these things. If it's really bad if you are in middle of something, if you have wrote 50% of the code, then all of a sudden you realize, oh, I can do this thing in web workers. You just directly jump to the web workers. Actually, you wasted half of the DOM things in the 50% earlier on. So things should be like, think first, then do it. So next is managing client DB layer and persistence. As I told you earlier on this client DB is very new. There are two basic options available. One is index DB, other is web SQL thing. So index DB is something like, you can directly save the JSON objects or JavaScript objects into the database. You can create the index on that. Say you are having a collection of particular, say student kind of student objects. You can say, I can query on the student name. I can query on the student role number kind of stuff. You can create index directly. Other approach is web SQL thing. Web SQL is simple SQLite. What it does is like simply SQL things. You just, it's a relational schema. So you can directly save everything as a relational thing. Then you have to take it out, convert it into JavaScript, then use it. So basically now W3C have made this index DB as a part of its specification. So this web, this SQLite will be, I mean, gone away in some time. So what is actually the basic reason behind this, if you are dealing with a client DB, you are dealing with the JavaScript only. There is no other language available. So there is a extra overlay. If you are using the SQLite or SQL kind of structures, why? You will be converting your JavaScript to the SQLite first. Then you will be seeing the SQLite. When you are reading it, you will be converting from SQLite to the corresponding relational schema. Then you will be converting that to the JSON object or JavaScript object. So there is a extra level of work that is, that was required there. So this webkit thing, webkit browser, they started implementing this SQLite first. Now everybody's moving to the index DB. Internet Explorer 11 also has this index DB only. So, but the only problem there is like, they do not support multi indexes. So say, if I'm on a student thing, I want to make a primary key association with this name and roll number. It's not a realistic example, but say I want to make a primary key association with the roll number and name. You cannot do this thing in IE 11. They still have to implement it. So just to give you, you should take care of these things. So this is a final architecture. We came after thinking about all these things and that really helped for us. So I'll just brief you about all the things that I spoke and everything, how they were related in actual implementation. So there was a EPUB thing. EPUB, as I told you it's a zip thing. Then there is a chunker thing, which is saving this thing too. So here's some storage. What is this chunker? Chunker, as I told you, this phantom.js thing can actually perform a very good offline processing for the JavaScript thing. So there is a lot of tasks that has to be taken care by the client only, by the browser only, but that is actually too much for the client. You can do that with using phantom.js. So something like that. Then it is going to the storage. Then this client side will be having offline cache and client dv, everything it will be having there. Security part, then there are some of our internal terms like flipstream, flip sync and CDS. There are other platform application like Android app, iOS, Windows, ADAP. So basically this flipstream is a internal service, what it is doing is like, so say you are using web reader on the browser, you make a annotation, you make a highlight there, you go to our iOS app, you go to our Android app, the same thing will be available here. You left it on the first chapter, second page, you'll find yourself on the same page on your iOS or Android app. So this thing is really dealing very well with every other apps. There is a flipstream. Flipstream is just a content delivery, sorry, it's just a delivering of chunks and all resources for the book. Then there is a CDS content delivery system for us. So it's dealing with the static resources and all that stuff. So that's it for my side. Any questions? Well, welcome. Yeah, please. So you were saying about the WebSocket, right? Sure. Have you tried the WebRTC data channel? That is also for transferring now. It's saying like it's... Your voice is breaking, can you please hold it still? WebRTC data channel, have you tried that? It's saying like you're more faster than WebSocket. Have you tried that, compared that or something? Is it faster? So there are a number of things that can be in draft at a particular stage. So these Mozilla, Mozilla organization, these Chrome organization, they are continuously developing new things in the market. But they are all experimenting it. So this is a WebSocket, something that HTML5 actually considered into its draft, working draft, that is actually converted to a... It's on the final stage only. So it should be like you should be using something that is for sure going to the final stage. So that's why, just to make it that way, we are using WebSockets. Yeah, and one more thing I want to understand, like PhantomJS uses it, right? So it's acting as a kind of mediator, right? So rendering and all it's making... So... Pre-rendering it's doing like that. So PhantomJS is like, obviously, what will you do with rendering a particular HTML page on server? It is not visible to the client for sure. What is the use of that? The use is, like I gave you an example of the crawler, where you have to run the JavaScript to generate a HTML page for indexing only, for the crawler. They can be the same example. In my case, there is a... Every possible thing in the web is HTML only. I cannot go to the details, what I have used, what I, why I have used, but the actual use case is just when you have to render HTML plus JavaScript on the server. So it will take care of all the CSS resources. It will refer everything. It will actually draw it, but if it's a headless browser, it will know it is not visible to anybody, but it can actually process it. Yeah, I have a question regarding the chunk size and the screen size. Is one chunk size is equal to the content on one screen or multiple chunks are required for one screen rendering? So, there is a call to that. So basically, as he's correct, absolutely right there, like the screen size can vary. How will you decide a chunk size? So you have to come up with a number. Yes, at max, this can be a screen size of the user. Say, fine, about that, I partially process something, then I send that partially processed thing to the client. Now, say, I targeted a particular screen resolution, which is the maximum one, say, now the current screen resolution is, say, one-tenth of that. So now I'll process the partially thing to the final thing. So actually, the chunk can be of one screen size or ten screen size. It varies. So basically, it's just about making a call. So that's what I said, use of Endom.js. Partially process the data if you can on the server or offline thing so that your client do not have to do a lot of stuff. And the content is actually very, very fast visible to the user. OK. And regarding devices, has this been tested on TVs also? Smart TVs? Yeah. So basically, we tested on this Samsung TV. They have this inbuilt browser, which is rendering very, very smoothly the same thing on itself. So it's really good for the user if you are giving the user such experience. So user can go anywhere. I mean, it's very good for the user if he sees, OK, fine. I'm in front of this big screen size now. I want to read something on that. He has bought a 1.5 lakh TV to do something else. But he wants to read it. You should not say, oh, we made it for 1,024x768 pixels only. So it's just about delighting the customer. For our case, it actually renders very smoothly. Thank you, everyone.