to ensure that those instances are created reliably and securely every time for that at postman we use our collection runs to create resources with extreme confidence. So once if we have guaranteed that we have created a database securely a collection run guarantees that it will be secure in every future run and we also monitor these configurations every time using our monitoring service and keeping a track of what exactly happens and if anything major is found missing or something is misconfigured we are notified and then we take appropriate steps. So let's take a look at how we perform one single audit with with a collection. So I'm back in the postman app and I have a collection ready for you which is AWS MFA audit. This collection does one simple thing. It lists down all all the user in your AWS team verifies if all of them MFA enabled that is two factor authentication enabled and so I just go ahead and run this collection. I will choose the appropriate environment and then say run. Now this will call the AWS API with your access token fetch the users. I hope the internet works and fetching users users. And it won't return because if the internet does not work you won't be able to list users but ideally what you will have is if you open the runner you will have a result like this which is already ready for you which tells me the last line saying Ankit underscore M should have MFA enabled which is exactly what I want. I want to verify that all users in my team have MFA enabled this keeps on running constantly and if anyone does not have to MFA enabled we get a slack notification. We notify them and everything is good. One other thing which we ensure in our platform is help check once your service is ready for deployment and before it is being served to actual live traffic in production. We verify for mission critical information. This might be things like keys environment variables BB consistency your cash consistency all the things which you know might affect the availability of your service and in our applications we have a bootstrap test which performs all this and if anything fails in this a step we just go ahead bail out and prevent the deployment and if it everything looks good then yes you are allowed to deploy and however this is used as a last step of is the last line of defense preventing against major mishaps and it is definitely not to be used as a testing mechanism for anything. So you all built you we all talked about about each components which come into building a secure back-end for front-end. We started off with the service handle validation in in bound where we talk to our internal microservices ensure that content was served securely to our clients and also secured our platform which serves all these resources but we it's not a one-time thing that you do all these things once and forget it you need to ensure that these things are continued and your application stays secure over time and that is where you we perform certain software. We follow certain methodologies to ensure that our services stay secure. One of them is tracking security KPIs KPIs stand for key performance indicators and one of them is CVS scores of the vulnerabilities we detect. We track them throughout our versions. We see how often we are repeating our mistakes or are we repeating our mistakes? How long does it take to fix a issue reported by users or maybe someone from our team? It and also keep a track of issues reported by services like hacker one which are where security researchers try to break your app and these are tracked throughout our versions giving us a very quantifiable metric that whether your BFF was secure or not or has it dwindled over time or has it become more secure over time and this is all handled in a step called VAPT stands for vulnerability assessment and penetration testing. This is a post development step where we're in once a build is ready for production deployment. We send it to our security team. They perform certain tests on that it might be white box or black box testing and try to find vulnerabilities or security issues with the build if they find any they suggest changes to us and we make them change make changes and send it back again and once it is cleared by them it only then it is allowed to go to production and this step it also exists in most of the companies and is a very tedious process and very manual because the the engineers have to manually try for every keeper track of all past all past bugs re try them again saying have you not have you don't regressed for something but at postman we automate all these things using our collection runs as you just saw I demonstrated three different ways to check for various things now any bug you find let's say a user information was leaked a collection is created and is automatically run whenever a build is sent to the security step keep making process much more faster and also reliable eliminating human error from this and all these things building a secure platform a secure API layer and following some proper software methodologies ends up in building a secure API or a BFF in this case so we started off with if you remember we started off with certain security parameters saying that we want to evaluate security of our BFF under these parameters what all did we do to achieve those things to achieve confidentiality we we ensured proper validation using principle of least privilege we scrubbed our logs using various heuristic methods to ensure integrity we made sure that every request was tagged with user information so that we prevent IDOR attacks and leaking informations about other users and also implemented content security using various headers and finally to ensure availability we kept our critical path extremely short meeting our BFF is much more performant we performed constant platform audits and also consistent health checks to ensure that a bad release isn't pushed out to users and all these things combine to build a secure API in general and this is what you need to take care while building anything that your needs might be different from our needs a certain things you fell right for us and we had certain use case in mind but your API or your BFF might not have those constraints or might not have the same use case so what you need to understand is what security considerations you need to take care while building each module of your API and also keeping in mind that it is a gradual process you can't wake up one day say though today I'll build my API secure it's not going to happen in a day it will happen over time where you constantly monitor for things you measure things and ensure that your API remains that way throughout the period of time and finally it is it is very very interesting and very philosophical to say that security is ingrained in you but small mistakes which you make like say using eval or using unsafe links they go a long way in destroying the security for an application so while developing make sure you take care of these small mistakes you ingrain security as a part of your development process and don't wait for QA or security engineers to tell you that this is wrong which goes a long way in building a secure and also reliable back end for front end. Thank you very much. Do we have time for questions? Let's have a joint Q&A. Oh yeah, there's a joint Q&A. So, so seed first four speakers Siddharth, Arnav, Shyam so this is like a joint thing obviously so joint means where you guys can ask whatever you have and either of the four can you know we have runners here who will hand over your mics. So, if you have any questions for all four of us, you are free to ask at this point. Hi Shyam, so considering all the talk about security so what I want to ask it as users of a website or users of an app so apart from like ensuring its HTTPS and everything else so what are the other things we can look for before like trusting a website with our credentials. So you're talking about you trusting a different website with your credentials? Yeah, as a user not as a developer talking as a user. Good luck with that. If you figured it out, let me know because other than relying on the company and their background and how many people they have, I haven't found a good metric and even the best of websites like the LinkedIn and the Google of the world have had leaks at different points in time. So simple thing to do minimize the information you give use single sign on using some other provider that you can trust and don't reuse your passwords other than that. I have no other better tips maybe one of you guys do. Hello. Yeah, my question to Siddharth that when you talk about security and especially when JWT you talk about so everything you write in in client side in JavaScript if you want any token you have to write code in JavaScript and how difficult it is to pass the JavaScript in a browser itself and get all the information. Um, are you saying how difficult is it to capture the token on the client side? It's super easy. Yeah, it's like if you use a Chrome extension, if you use a vulnerable npm package, you should always assume that the client side token is already gone. So, so when you talk about JavaScript and security, then how it will be secure when you write everything in JavaScript, how can we make it secure? Okay, um, I can give you like a one minute revision of my talk because that's basically my talk. Um, the idea is that in the token don't store anything that you don't want people to see. So don't store credit card information, no passwords, no cart information, even only store things that are required for the session, right? So who is this person? What's his ID? Um, admin through user role, et cetera. Uh, the goal with token that leaves JavaScript web token JSON web tokens is not to hide that information is to verify that this information is is legit, right? So it comes from the server to the client and goes back to the server. The goal here is to make sure that it's not tampered in between. If it's tampered, you'll get to know that's the thing it tries to solve. So it's not hidden. It's just, uh, verified. I guess why man in the middle cannot get my private key when I'm sending it back. So while doing the authorizes, the idea is that I'm sending my private key privately to my client. No, no, never, never, please don't do that. You're only so you're on the server on the first authorization server. You're using the private key on the server to create a token and now you're only passing that token. The token has a signature which was created with the private key, but you don't pass the private key. You only pass the token. So let me rephrase it in the shared key system where the key is available to both. What happened that time? Oh, so. Okay. It's like saying you and I have a secret, right? We have a we have a pseudo language, right? That we've created between ourselves now and you're the authorization server. I'm the API server, right? He's the client. Now we can talk in our own code language and he wouldn't understand because he doesn't have the shared secret. You would understand because you have the shared secret. When you tell it to me, I can understand because I have the shared secret. But while we talk in this room, even though other people can listen, they don't have the shared secret because that doesn't go through the client. It only stays with you and me. The secret is not never in transit. Yeah. You have built both the servers, right? So you just keep the secret in both places. It's never in transit. It doesn't travel through the client. So this is regarding like how we build front end and back end in our system right now. So when we use JWT is right, like you will have to store in front end in order to like access the station in the later point, right? So one way is like you said, like local storage other ways, like storing in a cookie, right? So when you're storing specifically in cookie, like one way to secure that is of course, like whenever I like receiving the information, I should sanitize it. Another one is like to set expiry date to it, right? Is there anything else like also like setting HTTP only to true, right? So this has a way that I can secure my cookie, but is that is it enough to secure storing like JWT in a cookie or should we do more on the top of that? I guess he can answer your question about cookies. Right? I can answer that. Sure. I can answer the local storage part or the in memory part again, because you use a bunch of npm packages and a bunch of client site Chrome extensions, they can hypothetically grab your token as well, right? So that's why you can all like you should always assume that the token is going to get leaked and all of these things that we talk about setting the audience using the right algorithm, putting expires are only frictions that you add so that the hacker has to do more work, right? It's like the more friction you add, the difficult it becomes. I wouldn't say it will ever be full proof. I would add a very general point to it is that I mean something like say cookies just set it and you know that I mean anybody can read the cookies, but beyond that, like trying too many stuff. For example, like there is a excesses header field that you set on HTTP. It actually introduces a vulnerability in IE eight supposed to remove the vulnerability on other browsers. It introduces it because zero and one is swapped on IE eight. So I mean, don't do a lot of extra stuff to just make things extra secure, especially like on the client side. I mean, just think it's already exploited. Just don't like try 10 different things. You'll probably introduce some extra vulnerability. If you try something fancy on the client side, is there a way to invalidate JWT other than the expiration time? So it won't remain stateless. Then it will maintain a blacklist of that. If or you can change the private key and then everybody is logged out. These are the two ways that we usually do any other way. Use them like cookie store them. You don't get one server side logouts. Then JWT is not your option. Like JWT has a like application layer kind of thing where it is very useful. Like I was mentioning in my talk, like we use JWT is a lot in our applications, but we don't use it in our server because there are places where you want to do server side logout. You probably don't want to use JWT there. JWT token invalid or like rework the token. Like I'll tell you the basic example like scenario where we have a customer already logged in. So on his local system, we do have the JWT token, right and from admin he he now changed the customer status as like no longer valid, but the token is still stored on his local system, right? So he still will be able to access that. So how we can like handle this situation with JWT? I guess the first part of it was covered by invalidating JWT tokens, but the second information is what you store in a token. So this transient states like is a server is the client active or not? Or is something is the user allowed to do it or not? Should you really? The question should you really store it there? If you can do it on your back end and store it in your database and find out whether and change there. So you don't have to invalidate it instead. The state of the user has changed from let's say active to inactive or maybe let's say deprecated or whatever. So you you provide a way for user to say that I am this I am giving you my certain things, but on the server you figure out what is the state of this user and not not exactly push everything to the client side. I guess I'm just going to say everything in one sentence. If you want remote low if you want remote logout, don't use JWT, don't use stateless sessions. You want something that is stateful either use a cookie or just use JWT like cookie. Also in addition to one thing, I mean like maybe a general question to you guys just to clear your mind, say you have a JWT and you have the username inside it or say your server allows changing usernames. Okay. Now the user changes his username and you get an incoming JWT. It's valid because of course it's valid. It's not expired. So if you look at the username, which one would use a source of truth? The database or the JWT? I mean, I hope that answers the query for everybody. Right. The JWT should not be like the source of truth. It and it should not. It should only have very nominal identifying data. So if some data has changed on the database, then your source of truth has changed. So that is also another way your JWT is actually not valid anymore. I said, uh, so my question is again with JWT. So the way I used to do it was, uh, I used to send the JWT after the user would log in, you know, and then I would store it in local storage. So that today I got to know that that's not a good idea. So how do you take care of the flicker, which happens for the first time? And, uh, you know, when, when I want the session to stay, even if the user closes the tab, if he reopens the website or the application, the, uh, I mean, the API's work, how do you like ensure that if I keep expiring the token again and again and again? So every time you expire the token, you also recreate a new one. Yeah, I get that. But, uh, after, uh, say I expire and then, um, uh, I closed the tab, I reopened the tab, then there's a flicker. How do you prevent that? I have faced it. Maybe it's a, I don't know, like maybe it's a simple solution. I do not. Okay. So your use case is basically you want the token to be valid for longer. You don't want it to expire in every five seconds because yeah, but if I, if I do not store it on the local storage or a cookie, then, uh, how do I check whether, you know, the first API call after the, you know, user opens the tab, there's one first API call with the token, right? Oh, sure.  Like odd zero JS does that for you. It uses local storage literally to keep a key essentially that this is the user for, um, your service like odd zero and then it using that key, it gets a new token for you. So it's like either you have to ask the, uh, end user to input his credentials again and again, or you have to store something locally in something like local storage or cookie that you can use as a proxy of that. So it's like saying the token can be what do you say you're avoiding man in the middle attacks by keep deleting the token, but you're still vulnerable to things on the client with a Chrome extension or something. Right. Okay. Thanks. Uh, so I also add one thing that this is, uh, I mean, you either design your system with a refreshing mechanism in mind or you design it without that. If your system has a refreshing mechanism, it should not matter whether you refresh it every five seconds or every five days in the refresh should work either case. I mean, it should work after expiry kind of refresh. Also, you should have, or you completely don't have refresh then people just log in every time.  Some refreshes work. Some don't work kind of thing. Hello. Uh, my name is I think it, uh, my question is that when we are now, how do we secure interaction like sending sensitive data? How do we secure that? For example, like great car details at all that like JWT we understand when we said that we don't store and we don't use it for transmitting secure information. But when we are in a situation like that, we're in, we have to send users create car details with CVV both and everything. So if anyone takes that, then it's completely like the user will lose trust on the company and the size. So that is my question. How any suggestions? How do you make that secure? Thank you. So when it comes to critical data, right? And payments is definitely one of them. There are a few things. So one HTTPS well tested, not prone to man in the middle as such, then you have secondary level. So there are on the server side, you have PCI restrictions on what data can be stored, validated, logged, so on and so forth. There's also additional things that you do, especially if you use a payment gate, where things like that, you'll see that they ask you to encrypt it with a public key on the client side, send a request token, which they can validate to make sure that the request itself was not intercepted or tampered. So those kinds of cases, those kinds of cryptographic hashes and signs using public keys and private keys on the server to validate it, that makes a lot more sense. And that's really your best case for that. Anybody uses a cloudflare to provide SSL to their website or like any other DNS provider to provide SSL proxy based SSL anybody's using? Yeah, so your your actual backend is running on HTTP and cloudflare is providing the HTTPS part. Anybody has a setup like that? Well, then man in the middle already happening right there. So I'll give you an example. There was once a takedown request like I just know it through a friend, I don't want to name the company. They had a takedown request and like on a particular URL. So government actually does takedown request in particular URLs. ISPs actually cannot do that because if it's a HTTPS you don't know the rest of the part of after the domain. So ISPs cannot actually take down a page. They can only take down a website. So they usually refuse to take down the website. If the request is only for a particular URL when the government found out that the actual server was running on HTTP on a Airtel data center. So they just requested Airtel to block it from behind the cloudflare part. Okay, so I mean if you're using SSL then it should be your SSL certificate. It should not be the cloudflare kind of system. Then I mean somebody can just directly reach your data center and do meet them there. Okay, we'll cut the questions here, but don't worry. You can come to the speakers talk personally to them. Wow, nice. So we've had like three security talks now apart where we shift a little bit of focus from security to other parts of JS. So how many of you have tried or have managed to install or you know, implement service workers in production? Okay, this is nice. My friend has a very worst experience like he set up a service worker and he cannot update the site. So he has, he had bought a new site in order to update the service workers. So you end up buying another domain just so that the update works. So our next talk is by Rahul who aspires to be a DJ and play at Tomorrowland one day. So maybe if we do something like this, he'll be able to relate to it. So Rahul, the stage is yours. This is working, right? Yeah. So hello everyone. We are on time. So I guess we're on time for lunch as well. I'll try to wrap it up so that you're not late for that. And I am Rahul. I'm co-founder at imagekit.io. It's a relatively new product. I'm sure not a lot of you would have heard about it. But then what we basically do is real time image optimization and transformation. And today I'm going to talk about something which as you know, a lot of people have come up to us and ask that, you know, how do we optimize images based on the user's network, right? Let's say if the user is on 3G or if he's on 2G, how do we change the image that we are sending to them? And consider typical case where, you know, a e-commerce website loads hundreds of images on the website. They would want to up to some kind of optimization for the users who are on a slower network. So that is what we're going to discuss that.  And yes, I am from imagekit and I would be using imagekit because you know, this is a sponsored talk. You would have read in your schedule, but then what we discuss can you can implement that on your own as well. You can use any in-house solution that you might have for images. You can use any other third party that you have for images and not just images. You can in fact apply what we discuss to other more critical parts of the application, which is a JavaScript in the CSS. You can optimize those as well on the basis of the network. Right? So let's get started. This is a rather interesting start and I guess most of you, you know, who have worked on front end would be aware about this that all the new users that are coming on the internet are coming through mobile, right? And globally that's 55% of all users are coming from mobile in India. That's a slightly higher percentage at 78% mainly because of cheaper handsets, cheaper data plans coming in with geo and Airtel, right? And why am I talking about mobile, right? When I'm talking about service workers because network speed is actually a problem on mobile devices and not, you know, you guys work in your offices and you have a very stable Wi-Fi or a LAN connection. You do not have network problems there. The network problem is on your mobile devices. For example, if you step outside your building, you move into the lift lobby or let's say you move in the basement parking, your network speeds would drop, right? So our ideal target audience for this is people who are using mobile and that's a big chunk for all websites. Right? And we often believe that, you know, with geo and Airtel and everyone coming in our users, you know, they have a great 4G speed or a great 4G network. But the fact is not right. We did this study with one of the companies that we work with 91mobiles.com. What we did was that Chrome exposes the downlink speed, the estimated downlink speed that the user is observing at that time and we tried to measure that. We did that for a lot of users over the million users and this is what we see that almost 45% of the users have a speed lower than two Mbps, two megabits per second. And in fact, almost 25% of users have a speed less than of one megabit per second. So you can. So we assume that our users have a really fast network, but then the reality is that they do not, right? And contrary to this, in the last six years, our page sizes have gone up by three times. And the reason is that, you know, we started pushing a lot more JavaScript code with the client side rendering happening. We start pushing in lot to the client videos have gone up in the last last year, right? So our page sizes have increased our assumption that the network has improved stays. But then the reality is that the networks have not improved as much and the result is that our users end up with a frustrated experience. They might not even come back to the website. Right? I'll go back to the previous slide. I just wanted to focus on the green bar that is there at the bottom that basically corresponds to images and I would like you to notice that images still correspond to about 50% of the page weight, right? Videos are coming up, but the images are still the major component in the page, right? So this this makes it very clear, right? That up until now, we have been able to modify our website and our content on the basis of let's say the user's DPR or let's say the user's device with we have made responsive websites, but then not a lot of us have worked on optimizing the website on the basis of the network speed and that must change, right? We need to stop building for ourselves. We need to stop building for people who are there on a Wi-Fi connection and can load our website really fast. We need to start thinking of users who are not on a very good stable connection and we need to start building for them, right? And our target in the stock is we are going to be focusing on images. Reason being that like like we observe that they still form more than 50% of the page weight. Plus the other reason being images are the lowest hanging fruit to be honest, right? They might not have as much impact on the overall page load time as you know, optimizing JS or CSS would have, but then that they are the easiest ones to optimize and they are the easiest ones to start off with and but then you can apply this concept to any other content on your page as well, right? So now we have two requirements. One is that we need to determine what network the user is on and detect when that network changes. And the second requirement is that when the network changes, we need to change the image size that we are sending them, right? So we look at the first first part, right? How do we detect network changes? So Chrome and Chrome mobile that is what I recall from from what I last read have implemented this network information API. What this does is it observes all the all the downloads that are happening in the browser and it tries to estimate what kind of network the user is on, right? And it exposes a read-only value which can be read from navigator dot connection dot effective type. It basically classifies the user into four buckets. 4g 3g 2g or slow 2g. So when I say 4g, it's basically speeds upwards of 3 mbps, right? That's the average it includes Wi-Fi as well. So even though the classification is 4g and 3g 4g would include really good speeds, including Wi-Fi as well. Right? So we do know what what network the user is on. What kind of speeds is he getting right? And 4g obviously is faster than 3g 3g is faster than 2g and 2g is faster than slow 2g. So the logic dictates that right on 4g, which is the fastest network of all we need to serve the largest image size. And on slow 2g, which is the slowest of them all, we will serve the smallest image size, right? That's that's what we want to do now. How do we change image size? Right? We're not talking about changing the image dimensions. We're not saying that we will resize the image and send a smaller image to a slow 2g user. What we want to do is to mince, you know, compress it further, right? Compress the exact same image further. And for those of you who would have worked on images on the front end, you would know that there is a factor called image quality that is associated with an image. So very simply put image quality is a scale of 100 100 being the best quality one being the lowest quality 100 being the sharpest and the best image that you can get. So I've taken this image as an example, right? Let's say I have the image quality set at 90, which is a standard for a lot of websites that set their image quality at 90. The size is 47 kb, right? Let's assume that we will use this for the 4g network. Next, let's say for 3g network, we use quality 70, which is giving us a 40% reduction in size. Now assume that you have a website which loads one MB of images. If you are able to save 400 kb out of it, you have actually saved a lot for the user who's on 3g. Similarly for 2g, we will use a smaller quality level 55 for slow 2g we will use 40 and for slow 2g we are actually reducing the size of images by almost 72%, right? That's a huge reduction for the user, right? Lot lesser data to download. So how do you change quality? This is where image kit comes in, right? We provide a lot of transformations that you can do in real time on an image. So for example, let's say I have this image URL image 31.jpeg and let's say I want to get a quality 90 image. All that I'm doing here is I'm appending a query parameter t r equal to Q-90 it get me a quality 90 image. If I change that to 60, it will give me a quality 60 image. If I change that to 10, it will give me a Q10 image and I'm not sure if you can see it on the screen or not, but then the Q10 images is actually really low in quality. If you especially notice the clouds above the house, you would find that those are really pixelated and that is the reason why the size is small, right? So apart from quality image kit does a lot of other transformations, but for now I will stick to quality, right? That is what we are trying to optimize. So we have figured out two parts. We know what network the user is on. We have figured out a way how to change the quality in real time. You can use anything apart from image kit. If you can do that, right? I'm just using image kit as an example. Now, how do we handle all of this in our code? Right? The idea is that we do not want to be changing our code, right? We cannot have our server sending different URLs for different network speeds. We do not want those kinds of changes, right? So this is where the service worker comes in service worker is I guess a lot of you would have worked on service workers or work with service workers, right? That service worker sits as a intermediate proxy between the user's browser, the cash storage in browser and the network, right? And what the service worker allows us to do is it allows us to intercept every request and then decide where do we get the response from? Do we get it from the storage? Do we get it from the network? Do we modify the URL and that modify the URL part is what we are looking at, right? So what we will do is let's say I have in my HTML, let's say I am using image 1.jpeg if I detect 4G in my service worker, I will change the URL to use quality 90. If I find 3G, I will change it to use quality 70 on 2G. We will use 55 on slow 2G 40, right? This is what we will use the service worker for that. We will intercept the request and we will change the URL from where we are getting the response. So let's look at some code. My image tag remains exactly the same. I'm not changing the image tag. My quality parameter does not come in the image tag, right? Our image tag remains the same. Next part is obviously we install a service worker. I won't go into the depths of it. It's a pretty standard thing. You just need to call service worker to register the file name and gets registered. Now this is the main function, right? Service worker allows us to hook on to an event called the fetch event. This fetch event is basically fired for every request that is originating from your browser. What we do in the first two lines is that we it's a very basic check. We check if it's a JPEG image or a PNG or a J for a WebP, right? If it is, we continue further. We check the connection type for that connection type. We determine what quality do we need to use and in line number 11 line number 13. In fact, we create the new URL. The new URL basically would be we have appended the quality parameter. Let's say to that URL and in line 14 to 17 instead of responding with the same URL, we respond with the modified URL. So for example, if the browser sent a request for image one dot JPEG and we modified it to let's say to use Q 70 instead of so we respond with Q 70. We do not respond with the original URL, right? So let's look at an example on how does this work? So so this is a basic something which we have created similar to an e-commerce website. I've already loaded it, but then this has been loaded without without the service worker coming into picture. What I've done is I have throttled the network to fast 3G. This is something that you can do in Chrome and I will just reload the page once and I hope that the demo works. It does. So what I have done is I have also overlaid the quality number at which the images are being pressed on, right? So use if you see all images have been fetched on quality 70, right? All of them have this number 70 overlaid in the top left corner and if you see the network tab, this is the original request, right? This is the request that the browser fired. I was resizing it to 300 by 450. The service worker intercepts it. It issues a new request which has Q 70 as one of the parameters because the service worker detected that the user is actually on a 3G network, right? So this is this is what the service worker was able to accomplish. Right? So this this is very good to begin with, right? So we were able to detect the network and we were able to modify the image. We were able to send a lighter image to the user. But then there is a problem with this, right? And the problem is that the browser does not know that you have modified the URL in the service worker, right? For the browser, it's a black box. If the browser requested for image one dot JPEG and you responded with let's say quality 40 in the image, the browser does know and the browser would cast that low quality response forever or for as long as the cash control allows it to do it, right? We do not want this to happen since we are modifying the cash on the basis of network. We do not want the browser to behave as a black box and cash everything that we are giving to it, right? So one one thing that we need to do is that we will skip the browser cash completely, right? Instead, what we will do is we will use the cash storage API, which is there in all modern browsers, I guess in most of them and we will use it to create caches for different network ties. For example, there would be a different cash for 4G. There would be different cash for 3G, 2G and slow 2G. And what we will do is we will implement a waterfall kind of a lookup wherein we always look for the best resource. We know that 4G has the best images. It has images on quality 90. So we would always prefer looking for an image in the 4G image cash. Then we will go to 3G then we will go to 2G and slow 2G. Right? This is how we will structure our cash lookups. This is something that you cannot attain in a browser. That is why we need to skip the browser cash completely. So let's look at the code. If you remember from the previous previous code example, we were responding with the the the transformed URL. So instead of that instead of responding with the transformed URL, we have a new function which is a step down cash lookup. We will we will do a cash lookup and if that cash lookup fails, then we will go to the network. Right? This is the cash lookup code. I'll give I'll simplify this for you and I've shared the code on GitHub as well. I'll share the link on where you can read the code. I'll just simplify it for you line number 10 9 and 10 is basically just looking for an object in the cash. Let's say in the 4G cash. If you find it in the 4G cash well and good. We return it from there. If not, we go to the next cash, which is 3G, right? If you find it there, we will return it from the 3G cash. If let's say we do not find it from 3G cash and we look up, let's say in the 2G cash and let's say the user is on 2G right now. If if the object is not there in the 2G cash as well, then we go to the network, which is line number 16 and 17. We go to the network. If we have a successful response, we add it to the corresponding network cash, which is being done in line number 18, right? So now we have four different caches. We are adding objects to different caches on the basis of network, right? And we are also picking up the best object that we have available at that time. If we have 4G available, we will use 4G object. So let's see how does this actually work out in a demo? Right? So let me just check if I have cleared all caches. I'll start with the slow 3G, right? So this should get me a quality 50 image ideally because it's slow 2G. Everything's slow. So you can see the first image which loaded its quality 50. I'll update this to fast 3G and I'll reload the page again. Now because the network has improved, the browser automatically fetched the better variant of the image. It fetched the quality 70 image. Let's say I remove the throttling completely and I reload the page again. So basically it takes time for the network connection type to update. So like I mentioned earlier, the network information API, it looks at the download times that the user has been observing and because I was observing 3G like download times, it kept me in that 3G bracket for slightly longer. Now that I have moved to 4G, now we get the 90 quality image. Now let's do the reverse. Let's say that the network downgrades again. Let's say the user falls back to slow 3G. What would happen? Right? We still have the best image in cash and it should ideally just pick that up. It picks up quality 90 image and if I look at the cash storage, so we have four different cash storages here. Is this visible to everyone at the back? The cash storages so we have a 4G network cash. It has all the images cashed in 4G. We have a 2G cash. We have a slow 2G slow TG. We never access slow 2G. So the cash is empty. We have a cash in IKIT in the 3G cash as well. But then 4G is the preferred one. So our images would always be picked up from this, right? So basically we have implemented a way where as soon as the users network speed upgrades, the images would upgrade as well. But then let's say if the user speeds goes down, we would look for the best image that we can serve to them and you know not downgrade his experience. Now this presents another problem, which is cash management. Earlier the browser was managing the cash for us. Now we are adding objects to the cash. So we also need to ensure that we are clearing the objects on the cash for this. I've used Google Workbox. You can figure out any other way to do it. What Google Workbox allows is that you can set up rules on every cash either on the basis of the number of objects that are there in the cash or on the on the time that for example, let's say objects in the 4G cash would remain there for let's say 30 days and I can have a maximum of 1000 objects in that case, right? I can set up this rule and I can create what is called Expiration Manager, right? So this is what we do to manage our cash. We we instantiate an Expiration Manager. The the last part of the code. This is how an Expiration Manager is defined using Workbox. We specify the max age in seconds. We specify the maximum cash entries that can be there and in addition to adding the object to the cash, we also update the timestamp when the when the object was added in the cash. That's been done on line number six. Right? So that you know the Expiration Manager can see how long this object has been in cash and from time to time we keep expiring the entries. You can you can do a very simple set interval kind of a thing every 60 seconds. You just clear out all the objects that should not be there, right? So that's a very simple way of managing what stays in the cash, right? So to summarize, one thing is very clear. It has been a long time that you know we have been optimizing for different devices, different screen sizes. It's time that we start optimizing for different network speeds as well because to be honest, network speeds are not that great in India and we must stop considering that, you know, we are accessing our websites from our offices or from our Wi-Fi's for us. Everything works blazing fast, right? But then that's not the case for our users. So we need to start thinking about them. We need to start optimizing on the network speed and we talked about images, but then you can get the gist, right? You can extend the same concept to JS and CSS. You can basically tell your server that okay, the user is on a 3G network, send me a lighter version of the website, right? So this, this can be extended to beyond images as well, right? We needed two parts of the problem. One is to detect the network changes and to maintain different caches for every network for this. We have the network information API, the service workers and the gas storage. The other part on how do we modify images in real time, that is what we do at ImageKit. Apart from quality, we have real time resizing, cropping, transformation, etc. Face detection overlays. It comes integrated with the CDN. So the performance stays right up there and you can integrate it with your infrastructure as well, right? We can talk about ImageKit later, but then as I said, you can do this even without ImageKit. You can do this with your own in-house image management solution. If you can modify quality in real time or you can use it with any other third party image product. The demo page, which I showed, it's there on this link service for SWOB 1 and the code is there on GitHub in our ImageKit GitHub. It's a very basic code. I haven't had time to add the readme file. I'll do it as soon after the talk and you can contact me either via email or follow me on Twitter. If you have any questions, that's it. Thank you. So my question is in general also in context to ImageKit as a service to say I'm on a slow network and I have images which have been loaded in poor quality, right? But as a developer, I want my user, so my images to be upgraded. So what I'm talking about is progressive enhancement. Right. Like so is ImageKit giving me something or in general, there's a solution for this? So what we discussed was a very general solution, right? If I see that the network has upgraded, that let's say the earlier the user was on a 2G network and you loaded a low quality image, but then the network upgraded to 4G, the service worker automatically fires a new URL, a new request, right? So the images automatically get updated, right? So that depends on your application logic, right? What you want to configure. I configured it in a way where it upgrades instantly. Let's say you do not want that to happen. Let's say you want, let's say you will wait for let's say five minutes before the user is on a better network to make a new request. You can implement that in a service worker, right? It's a very generic thing. It's not related to ImageKit. Like I said, it's something that you can change in your service worker itself that do you want to instantly upgrade to a better image or do you want to wait for some time or, you know, on some other logic? Do you want to upgrade to a better image? Right? It's something that you can do in the service worker itself. Hi Rahul. Yeah, we are right here and see me. Okay. Yeah, hi Rahul. My name is Shashank. So your talk was quite informative. So I am working on a couple of products in which I have to support users on IE 6, 7 and 8. Good luck with that, sir. That's all I can say. I mean, in the best case scenario, see if you if we go back to the code, the image tag basically doesn't change and if let's say the browser does not support service workers, even then the same experience gets delivered to your users. So in any case, the experience is not getting hampered. The only thing is that if the browser does support service worker, then we do something additional. Otherwise the experience on IE, et cetera, would remain the same. The image tag would load as it is. Right? Is there any alternatives because I've seen couple of GitHub projects where there are a couple of alternatives but the options are a lot. I cannot hear actually. How about now? Is it clear? Not yet. Can you hear me now? Yeah. Okay. So I was just trying to fix this and on GitHub, there are a lot of basically repositories which have this solution, but the as in the solution, there are a lot of products out there. So I'm finding it difficult to choose the right one. So a lot of products for network based optimization or image optimization or replacement for service workers for IE 8 and 7. You mean something like a polyfill for service? Yes, that's right. So I haven't exploded to be honest. I mean, I haven't come across these polyfill so I cannot comment on it as well. But then if there are, maybe I look into it and maybe I'll update my presentation and talk as well. Thank you. Hey, hi. So Chrome provides this API to the network like 2G or 3G. So what about Firefox, Safari and mobile applications? So as of now, the network information of the API is available only in Chrome and Chrome mobile, which is basically almost 70% of the users accessing normal websites, right? But then I will update my presentation. I recently came across an implementation which is done in service workers. So basically what the network information API does that it that it is calculating the effective downlink on the basis of the download speeds that the user is observing the service worker does the same thing, right? So so your support for network information kinds of get extended to other browsers with support service workers, right? So that's that's a slightly wider range of browsers than just Chrome and Chrome mobile. But then beyond that, like I said, it's it's a progressive enhancement. It's not something that, you know, if if the browser does not support, let's say network information or service workers, the experience still remains the same. But if it does support, we do something better with it. So this is a basic elementary question. So can the same approach be extended to switch the format of the image? So if I'm using Chrome and my browser supports WebP. So can I intercept a PNG image and instead serve a WebP? Right. So so in image kit, in fact, we do that automatically, right? So that is why I didn't cover it because in image kit, when we see that a browser or a device supports WebP, we automatically switch it without even changing the URL, right? But then yes, it can be extended to other browsers. If you can detect that the browser supports WebP, you know, through content negotiation as such, you can modify the URL to fetch a WebP image as well. So there are no restrictions around the like if the result mime type differs from the requested image format. So there are no restrictions. For example, you would have seen cases wherein the URL ends with dot PHP, but then the response is image, the same as slash JPEG, the content type is a JPEG image. So that that works perfectly fine because the browser is actually looking at the content type header. And in fact, the actual content that is being sent back and it tries to determine how to display that content on its own. So it doesn't matter what the original URL has in the extension for WebP. In fact, you don't need to actually go to the service worker. It's a very, it's a much simpler way in which you can, you know, implement WebP, which I can talk about, you know, after this talk, it's not related to this, but then you do not actually need to go to the extent of using service workers for it. Thank you. Hi, I have a question. Can I use this image kit? I, if my image is not uploaded on the your domain. Yes. Can I use yes, you can integrate it with your own storage or your own image server. Anything right? So we'll get it from there. We'll do everything in real time and send it back. Okay. Yeah, thank you. Hi, I have a question. Uh, as you said, that network type is returning 4g or 3g string, right? So I'm not able to hear it again. That network type is returning 3g or 4g or 2g, right? Like that. So what happens if 4g is returned, but actual speed actual downlink speed is low. Yes. So there are the two, the two observations, which I had when I was actually working on this. Yes, there are cases where the actual downlink speed is low and the browser still reports it at 4g. So in fact, if you look at the code that we have uploaded in GitHub, we take that into account that the speed is less than one megabits per second. We do not use the effective type that is being returned by the browser. We automatically set it to 3g. That is one way of doing it that you look at the downlink speed instead of the effective type that is being returned by the browser. But then, uh, there is I read it in another place that these downlink speeds and they're mapping to the effective type. It depends on it varies from browser to browser and it can change in future releases as the network speeds improve. The browsers would update their method of tagging as well. So for example, what is being tagged as 3g today? It may not be be tagged as 3g. Let's say two years down the line. So either you can rely on how the browser is tagging it or in certain exceptional cases like we have done if the downlink speed is really low, then we do not actually rely on what the browser is using to tag that. So it's it's something that you would you would need to take a call on it. Right? If you want to go with the downlink speed or if you want to go with what the browser is telling you the effective type is. Can you hear me? Can you hear me? Yeah. Yeah. So, uh, can you just quit me quickly run us through how image kid would integrate with my infrastructure? Because I think in most use cases, I would serve it from my infrastructure, right? Images offline. Oh, yeah. Thanks. That's it. Yeah. So does this image kid works only for images or it works for 3d models as well. It works for more than images as well, but then again, not in the scope of the presentation. So maybe we can catch up outside and you know, we can talk about it. Okay. Yeah. So, uh, since it improves the network optimizations by compressing the image. What if we pass the data out of the image and show some business data? Sorry. The when you compress the images or models, the data are being lost, right? Okay. So you're saying when I compressing the image, the data is being lost. Yes, but then see it's a trade off that you need to decide on on the basis of your application. I think showing a slightly lower quality image. Let's say which is 30 to 40 percent smaller, but then at least showing that image to the user with let's say an option for him to be able to fetch the original image. I guess that is still much better than not loading the image at all. Now imagine a e-commerce website where the image does not load at all versus you are at least able to show, uh, let's say a slightly lower quality variant, but then where the user still gets an idea that okay, this is a black t-shirt that you know that I'm looking at. So if the user gets some idea, I guess a fair bit of you know, reduction in quality. Obviously you would lose out on detail. That's a part of it. But then the user still gets a fair idea of what is the object that he's looking at. And I guess that turns out to be favorable for a lot of use cases. But then again, it depends on your application. You may want not to go for it at all. We pass the data of the 3D models as well as the 2D models. Sorry? We pass the data based on the e-mails or the 3D files. We pass it and show the business data to the end user. So for us, it will be not relevant to that, right? I didn't get your question. Sorry to be honest. Hello. Yeah. So for us, we pass the data out of 2D or 3D models and show the business data to the end users. Okay. So for this, if you optimize this and reduce and compress the data and send it to the end user, it won't be that much efficient for the end users. Maybe. I mean, that depends on what application you have, like I said. So this is very effective for a lot of use cases, but then maybe not in your case. Okay. Thank you. Yeah. Hi. So how the lazy loading of images, how is that different and or should it be used in combination with image optimization? So lazy loading of images is basically you're not loading something which is not visible on the screen. But then when that image is visible on the screen, you still load the highest quality variant, right? You you do not take into account that the user is on let's say a 2G network. You still attempt to fetch a larger version of the image. That is what the difference is versus network based optimization that, you know, lazy loading is something different. Lazy loading is let's say you will lost load 10 images and leave the rest of the 90 out, but then network based optimization is that when you're loading those 10 images, you would take into account that the user is on a 2G network and that you would load a lighter variant for him not load the, you know, the best quality image. So they're different concepts actually. Okay. Um, so, uh, my question is on the lines on on her question. I'm here.  So, uh, say, for example, I have the image image as, you know, lazy loading. I create a hook after like, you know, 50 80% of the scroll the next 10 images should load. Okay. But if the speed is too low, sorry, if the speed is too low, can I have the service worker, like a change the quality and the and and how much time does it take for the browser to understand that the network has changed and they need to like, you know, right? So, okay. So basically there is no lag in terms of what the browser tells you the network type is right. So it's, it's instantaneous. It's when you were refreshing, uh, something happened and I was like, okay, it was slow because actually the page was still being fetched from the server. Right. So the page load is still slow. All the JavaScript that is being loaded that is also slow. Only the images have changed. So that is why I said that, you know, images is the easiest bit, but then the actual performance gain would come when you implement this thing for your pages and your JS and CSS. That is where the performance bottlenecks usually are. Right. So images though is the easiest bit in terms of if there is a delay when the service worker is modifying the request or not. Uh, to be honest, I haven't seen, uh, you know, any significant delay. It's probably just a few, a couple of milliseconds extra where the, you know, the service worker is actually modifying the URL, but then I guess it's a very, uh, it's a very small time and it doesn't really matter. I mean the user on a 2g network would probably end up loading an image in four or five seconds. If we can make him load it in three seconds by serving a lighter variant. So that kind of compensates for the extra time that has been spent in the service worker. Okay. Uh, one more question. Um, so say if you are implementing this, uh, you know, service worker to, uh, for image optimization, uh, you've seen how medium does it, right? I mean, they send a first, uh, a blurry image, which is very low in size so that the user can get the idea, you know, like it's, it's loading. And then, so would you choose that over this? So are you saying something similar to what we see on, let's say, medium dot com? Yeah. They're images. Yeah. See, it's, it's again a call that you can make on the basis of your business, uh, if you want to serve, let's say, you know, a really blurred out image. Yes, that would be the smallest image that you can serve to the user, but then that's a call that you need to make that, you know, whether it suits your business or not for an e-commerce company, it might not suit the business for a content company. It may be fine, right? If, if let's say you are loading the image of an actor, let's say in a, in an article, right? It's fine if that image shows blurred up initially, uh, but then that might not be true for an e-commerce image wherein you are loading, let's say the image of a, of a t-shirt, right? You would still want to show the actual object in a slightly more detail instead of loading a blurred image over there. Let's again, depends on your business logic, right? What do you want to achieve? Hello? Yeah. Hello here. Okay. Yeah. Please, uh, let's cut this questions. You can speak directly to this. Yeah, I am there outside. So we can discuss life. Yeah. Yeah. You can discuss outside. So we have a lunch break. Uh, let's meet at two, two 10. Thanks. Also, if anyone wants to give flash talk submissions, please do. There's still open. Yeah. Only two slots are left for the flash talks. All volunteers, please come front. We have some work to do. All volunteers. Hello, hello.  Hello, hello.  We're raising our hands confidently. Okay, so just before we start a few announcements, the Angular BOF session is being held outside. There's a workshop on Alexa, which is in Audi 3, next to next. So just a quick thing of what a BOF session is. It's mainly like a discussion. You have a couple of panel members and you can put forth your questions or what an open discussion is. In addition to that, for the Flash Talks, we've got like five speakers already. There's like probably one more slot left. So just whoever submitted for the Flash Talks, if you can probably be seated in this area because after this we'll be having them the Flash Talks. So it'll just be easy to communicate the entire thing. Okay, so the next talk is on the most starred front-end library. What is that on GitHub? Okay, good, that's nice, I'm one-sided react. Okay, we actually even have some of ViewScore contributors here in the audience. He also has a workshop tomorrow, Raul is sitting there. So if you wanna learn about View or the first time thing, you can talk to him. So our next talk is by a speaker who's in one of the top 10 of India in PUBG. He's, that's an achievement, I guess. He's also an ex-Flipkart guy and he's here to share his experience about View. So Ashret. Hey everyone, I am Ashret. I work for OlaCabs as a tech lead in the Consumer Web Division. Today I'm going to speak about how we use OlaCabs, how we use UJS at OlaCabs. So before I begin my actual content of the talk, I want to set some context. So basically last year, I gave a talk at JSU about how we built a PWA for OlaCabs. And so during that talk, I covered a lot of parameters on how we chose our framework, or what were the benefits and what the journey was. So you can go and check that out on YouTube. So the reason I'm mentioning this is because this talk is sort of a continuation on that. So I'm going to highlight on the key aspect from the last talk that was which framework did we choose and how did we choose it. So first we considered Angular 1 at that point. Angular 1 was a good framework, but it had problems rendering large lists. It also had digest loop problem. But we had good in-house expertise in Angular. So that is why we had considered it first. But because of its problem, we thought we cannot go ahead with that. We'll consider something else. So next choice was React. React was a very good framework with unidirectional data flow and also virtual DOM. So the render performance was also really good. But at the same time, Angular 2 came out. So Angular 2 had incorporated unidirectional data flow, but had retained two-way data binding, or as you call it today as reactive programming within its component. So that was best of both worlds for us. So we built a POC for the OLA PWA using this. And we ran performance tests on it. So what we found is that it was a good framework, but it was very heavy. It had around 30 kb of polyfill and 198 kb of Angular 2 code, that is library code, and our sample application that we had written, it was around 50 kb. So this was a very large size, considering that we wanted to deliver this application on a mobile platform. Of course, by AOT and tree shaking, this size could be reduced. But still, the abstractions in Angular 2 made the render performance difficult. So we were looking for something lighter. That is when we looked at Vue.js and Polymer. So between Vue.js and Polymer, there was a very tight competition. They had very similar performance characteristics. We could, it really boiled down to how we wrote code in this framework as opposed to the framework itself being a bottleneck. But we went ahead with Polymer. So the rationale behind this was that our historic traffic pattern, that is we didn't have to worry about old browsers. And also for OLA, the PWA was supposed to be an experimental futuristic and the acquisition only channel because of which we didn't have to worry much about supporting old browsers. So with this, we built a very good PWA and it was showcased in Google I.O. as well as last year JSO. So let's pause this recap here and take a look at what happened after that. So OLA as a company found that web is a reliable platform. It has a very good performance and the time required to ship a application to production is significantly less as compared to Android or iOS platforms. So that is where the mandate for web generated. So what we wanted to do was replicate the capability and best practices that we found while doing the OLA PWA across all projects in the organization. So that is when we took a look at how our web stack was at OLA. There were the fragments, there were the whole frameworks were fragmented. So there were different teams using different frameworks. Even in a given team, there were multiple projects using different frameworks. So we felt that we need to have a common framework. So it was an effort to streamline and standardize the web development process across our consumer vertical, across our supply vertical and all other internal websites. We also wanted to use the same framework across our desktop and mobile and app web use. We wanted to give our developers a way where they can develop test and deploy applications at scale. So we didn't want the developers to go through choosing a framework cycle every time they develop the application. So with this in mind, we could have started to, we thought, what can we do? Of course, we can start writing our own framework or we can write some vanilla JavaScript to and enhance on top of that. But all of this is like a large cost to the organization. So what we did is that we thought there are a lot of good frameworks out there. So why don't we leverage them and not reinvent the wheel but we'll just tweak them to our needs. So one of the main thing that we learned is that web component is a very good architecture in terms of delivering web applications. Next came intercom component communication. So with our web experience, we found that if we are doing something like unidirectional data flow that is parent to child props and a child to parent events and use a store for business data that is a very good scalable architecture. Next is data driven reactive coding within the component. So we didn't want to lose out on that. Also the mobile web performance should be out of the box. That is an individual developer should not be worrying about how to deliver a performance web application. Also we should be able to leverage the lazy register of a component that was present in Polymer. So with this, the developer should be able to code and run and but at the same time, he should make conscious decisions regarding to the page load performance. That is he should not be sending down additional JavaScript which is not necessary for the critical rendering path. So he has to choose how to load the files. So this is a choice that we will give to the developers. Next, we also had a buy-in from the design team. So what we communicated to them was that we were going to have a central framework and we want to reuse libraries across the multiple projects. So we want your support so that the design that you give will be so that we can leverage on previous projects. So other minor requirements were something like we wanted to leverage HTTP too. So we had infrastructure support for that. So also Ola is supporting local languages and we are also going international. So we wanted to have that support as well. And in case we wanted to make a PWA, the same tool should be able to support that as well. And we wanted to integrate it with our build infrastructure so that developer doesn't even have to worry about how to get it to staging, how to get it to production, how to debug, how to set up the logs, how to scale up and scale down the number of servers. All of these components were also part of this. But this doesn't pertain to view assets. These are general framework, which is framework agnostic. There was also one another requirement. So now that we were writing a unified framework, so this had to be compatible below Android 5 web views. Because our traffic pattern indicated that we had a significant amount of users coming in on web views below Android 5 as well. So now these were the requirements. So the key points that we were looking was that the framework should be of a small size. It should also have less abstractions and complexity. So obviously we had seen other frameworks and we were in, we liked the philosophies of view and polymer. And so this time we had to choose a view because of the browser support constraint. And this is how we are going forward in securing our web future. We will write our code in Vue.js and we'll develop it in a web component style. We are using Vue.js in a single file component style and that we will deliver applications like a traditional compiled JS. And once the browser support for all the web components come in, we will still be writing our code in the same way we do. And at that point of time, we can reevaluate our position and see if there is, Vue is also supporting web components build by the way. Is it Vue or Polymer or any other web component library in the future? So this way I will ensure that my development pattern doesn't change by much. It's only a little bit of syntactic sugar that individual frameworks introduce. Other than that, my development style, my performance patterns, all of this remains same. So Vue, so to talk about Vue, Vue is a very good framework because it was inspired from Angular, React and Polymer. So it took best of all the frameworks and gave a good default and gave a good default build system. So if you're interested in knowing more about how Vue compares against your choice of framework, you can go to Vue documentation and check out that section. So it is a very well documented section wherein you can read a lot about how it compares with your frameworks, with other frameworks. So single file component is a development style wherein I can write the template and that is your HTML and your script and your style in a single file. So this sort of development has a lot of benefits. It's easy to use because everything you want is in a single file. You don't have to switch between tabs. You don't have to wait for a lot of compiled or complex CSS to be rendered. Also, Polymer and Vue, that is basically web components library, suggests that separation of concerns need not necessarily mean separation of file types. You can pack all the CSS and JavaScript and templates in a single file and still have a separation of concern with respect to the business components. But you don't necessarily have to separate out file types into different silos but rather have a compact single functional unit which makes debugging easy and the best part of it is you can pick and drop it into another project. Next, as I mentioned, that our developers will have to make a conscious call about how to load the assets required for the performance for the page to perform. So first I will load Vue runtime. So Vue runtime is the one which does all the framework related tasks of Vue. Vue router is a client-side routing library and Vuex is a state management pattern. So once this is loaded, next I will load one web.js. So this is something with Ola specific code and certain Ola specific modifications on one web which is particular to us. Next I will load router, store and app.js. And once app.js is downloaded, we will decide what are the components that will be loaded next.  So this way of loading ensures that in my critical path, I am making a conscious call and my page performance is guaranteed in a repetitive way out of the box. So every project that we do implements this. Another feature that we are using from Vue is the declare first load later which is present in Polymer as well. So I'll explain it with an example. So you will have your root base component. There will be a first parent top component, right? So in that you will declare some component like which is necessary, not necessary for the critical rendering part, but it still has to be in the parent component because for it's a reusable piece of code and child components send event to that and it will be utilized. So it may not be in the, for example, Ola notification web component which is not used in the first critical rendering path nor in the first usage by the user, but it still has to be in the root component. Now what happens if I include it in my beginning only? So it will hamper my critical rendering path. So I can declare it in my main component and I will not download it in the initial part, but I will rather download it later. And once I downloaded it later, it will, the moment the download is complete, it will react, the component will get activated and start performing its functions. So this is not going to cause any console errors. So in a typical day, we don't have any decisions to make when it comes to framework. So whenever we get a new project, we just clone our starter pack and we start writing our application logic and we don't even have to be worried about performance because performance patterns are, the best patterns are baked into the framework. And we have a shared design language and component library across teams which makes our development speed really fast over a period of time. So initially we took some time building a critical mass. That is we had to build a certain amount of library, common buttons and various other components. But once that was done, now we are at a place where in now we are delivering applications at a very good turnaround time. Also, because now we have a unified framework across Ola, the engineering folks can move across teams and contribute in terms of crunch. So this framework initially was used by, we made a POC of it and we tested out in production in one or two applications. And now it has been, and it was well tested and then it had a org-wide adaptation. So everybody in customer and supply and even the internal teams, web portals are on one web now. So there are around 20 plus projects which are running one web along with Vue.js. So let's take a look at some of the pages. So the first one is a single sign-on website which is powered using a web view, using one web. And the other, the next screenshot is your track write screen. So when you book a cab, you will share your write details with your loud ones and there is a track write link over there. So that link is powered using one web. So after this, we wanted to reduce the time taken for turnaround in Android and iOS applications. And we started to use web views instead of developing it natively for certain screens which were not in the critical flow of the booking. So this view is for merchandising view wherein we show the features and facilities that are available in the given city. So this is powered entirely using web views, built using one web. So once we built this, the organization got confidence on web platform and we started getting more and more web views to be implemented. So here you can see that donation and insurance web views which have API functionalities as well also implemented into using one web. Furthermore, we have launched new categories in both Android and iOS platforms by developing the flow, booking flow on web first and then implementing it on native. We also got a permanent like place in Android and iOS apps for certain critical flows like GDPR. GDPR is the regulation of data protection in Europe and UK. So here this particular flow is built using web views. Also the two factor authentication which is a critical component again is also being used via web views. And of all the integrations, food panda integration was quite a large one with respect to scale. So as you can see along with the category you can see a food panda icon and also the food panda information bar. So when you click on that, a full fledged food panda website is loaded in the web view and you are able to order inside Ola app. So this was a very big project wherein we built an entire website using one web. So now let's talk about how the performance works on. What is the performance metrics of one web? So Google performance standard says that you can effort to send only around 130 to 150 KB of JavaScript on a median internet connection and at median internet, medium, median phone that is your slow 3G connection with 400 KBPS speed and 400 RTT and a Motorola G4 phone. So our, let's take a look at one web footprint. So the common library is around 33 KB, some lazy loading and Ola specific library code is around 3 KB GZIP. All the values are actually in GZIP. So that is around 36 KB of library files. After that, this leaves us a healthy 100 KB of application code that we can send during the critical rendering path. So this way we ensure that all the performance patterns are baked in. So now let's take a look at some numbers. So if I ran webpage test on various websites, so the e-commerce website that is PWA, which had some performance that was perform out of the box performance, no special efforts. It had a start render of 3.2 seconds because it was using AppShell. It was interactive by 15 seconds and document complete that is HTML was pass was completed by 40 seconds. And the page size that was sent down was around 1.2 MB. Next, Ola website built in a non one web framework. It had a start render time of 12.9 seconds and it was interactive around 16 seconds. So next Ola PWA, so this is a website wherein we put a lot of effort in optimizing the performance and that had a start render of 2.4 seconds and rest parameters are also very good. Our regular view PWA, which was built, it didn't have any special performance tuning or tweaking built in. But even then it had a good start render of 6.4 seconds and interactive by 10.21 seconds. So on a one web website, which has different Do you have any other major points like comparison rights? Yeah, so what I understand is you're asking we chose Vue.js because of the browser support criteria. Is there anything else that made us choose Vue.js? Yeah. So the Vue.js components are loosely similar to polymer components. So which means that, so basically we believe in web components as the future. So web components give you benefits because it is a web components can be understood by the browser and a lot of rendering benefits are granted to you because the browser can understand what is going on in that HTML element, right? So it was the similarity of I mentioned that, you know, what were the challenges? I'm not able to. Hello? Yeah. So you did not mention what were the challenges that you faced Okay. So what were the challenges that you faced while you were creating this? I'm not able to hear you. Sorry. What were the challenges that you faced while developing this app? While developing one web. Yeah. This when you were integrating Vue in your food partner. Into food partner. So that was what you call it was after effect. Like we had already developed one web and food panda was developed, food panda app was developed recently. But to answer your question, like before that we had to understand the benefits. I mean, sorry, the performance patterns for Vue.js and create a skeleton app starter kit to replicate all the best practices and hand it out to the developers. So there was a certain amount of learning curve and also build modifications. That is adopting the Vue compile function in such a way that we can do a web comp. We wanted to be as close to web component development style and file distribution style as close as possible. If tomorrow we are using web components. So we had to face challenges in tweaking the build that is given by Vue by default. So we used the Vue v5 and Vue compiler and we had to write some modifications on top of that. You mentioned that you choose to going for Vue.js because it draws the best of other frameworks. Is it applicable, you know? I mean, universally it can be applicable irrespective of any requirements or any other needs of the application. Or we should know how other thoughts in mind before going for this Vue.js. Can you repeat it? Yeah, I told you, you mentioned that you went for this Vue.js because it draws the best practices from other frameworks. It has? It had draws, it took the best practices of other frameworks. So it can, can this be applicable irrespective of any, you know, requirements or should there be any other thoughts before going for this Vue.js? Yeah, so to phrase this question, he's saying that we have taken Vue.js because it has best practices from all frameworks. So suppose, is this sufficient or if the requirements change, do you have to reevaluate? That is the question, right? See, so that is why we have control on how we distribute our application. So we had that in mind. The benefits that it took are like, that is the reactive data system and unidirectional data flow and store. So now these are the best practices. The other best practices come in terms of, in terms of loading the file. So that is a place where you have scope for optimization because build optimization is one part and network optimization is another part. So network optimization has to be treated carefully and we built, we chose a pattern which we found that will be satisfactory for most of the use cases and we replicated it in case. So also we have given flexibility in this framework that the developer, if he wants to, he can deviate from the best practices given as well. So for example, in one of the projects, the certain type of bundling was different than all the other one-web projects. So what we have given is, we haven't implemented a very extremely strict guideline so that developers don't have any flexibility in terms of evaluating their needs. So in this case, because of one-web, the way it is designed, I can implement the best practices that are there and yet if I see that, if there is some other best practice in distributing the file, that is there. That is available. And in terms of framework-related components, so if there are any new components, I'm sure you will pick it up and it will be available to us as well. Hey, so is this one-web framework open source? Are you planning to do it? Oh, it is in consideration. Okay. Hi, thank you for your presentation. So you told me, told that with one-web, you could essentially reduce the amount of, or rather break the Mythical Man month paradox, right? But how much time did it take for you guys to actually develop the framework in the first place? So I don't have a, I mean, I think it was around a month, less than a month of effort. We were around eight engineers working and we were already had the past experience in web performance tuning. So we were able to get it out. Actually, I think it was around two weeks. So we had one week of discussion and around one week of writing the build system and all of that. And third week and fourth week, we just spent in writing out a POC application and running performance metrics, I mean, checking its performance metrics. Hi. So I worked on React and Angular, both Angular 2 Plus. So thing is like the way you're saying like web component driven project or unidirectional data flow, that can happen in both of the technology or framework. So I never had experience with Vue for sure. So I know there's pros and cons of both the framework for sure. And there's a theoretical or bookish knowledge which I have regarding Vue also. How is it better? Or what improvement has been made, you know, in terms of like while developing the Vue. So thing is as your personal experience with this one-way project, what's your take on this particular frame? How is it different in terms of real exposure or experience? How is it different from these two particular frameworks? Or if one has to develop a project or start a new web project, why one should consider Vue in contrast to React or Angular? So to repeat this question, so he's saying that Angular, he's using Angular 4 and React and he knows it well and they also have certain features that are mentioned here. So suppose I'm going to create a new project. What is the difference of learning curve in terms of adopting Vue or why should I adopt Vue?  So is your traffic going to be heavily mobile? First traffic. So if that is the case, then you need a framework that will, like I mentioned, you have 130 to 150 kb of data to be sent. So you can evaluate whether your given framework will fit that budget because you also need to send application code. You cannot send 150 kb of your libraries and then again ship another 100 kb, 200 kb of application code. So you need to evaluate that parameter first. Next, you also need to see developer experience. For example, some people like developing in JSX. Some people like TypeScript. Some people like raw HTML, CSS and JavaScript. So it also depends on your development speed. What sort of engineers do you have? Do you have time in spending some time for performance tuning? Do you have, or you want, I mean, even if it is slightly less performance, it's fine, but it should run out of the box. So if that is the case, like, so that is where you'll have to create your own matrix and decide. So I wouldn't say that, you know, only this framework is good or that framework is good. You need to come up with a matrix and then develop on that. What remains same is that your development philosophy. So that should not, that for me, that wouldn't change. So the way we distribute and all of that, that is based on certain research, well-researched performance guidelines. So based on that, you would be able to choose. So as coming to UJS, how easy is it to adapt? It gives a lot of healthy defaults and you don't have to think a lot. So if you consider Angular or React, the one non-functional difference I would say is that you need to know a lot and understand certain aspects before jumping into Angular or React. But with Vue, it gives you a good amount of healthy defaults so that you have a decent amount of web performance right away. And also the Vue is a progressive framework wherein, like I told, even our single category launch web page, wherein I have to put certain small components, I use Vue. Also a large-scale application, I still use Vue. So Vue is versatile framework that scales well with the various needs. So Vue has certain advantages compared to others. Excuse me. How we can bring the concept of CSS pre-process like a source less with this single file component? Sir, we're out of time. The speaker will be available offline. You can continue there. Okay. Let's thank him. Okay. Thank you. Okay. So we're starting flash talks. Simple rule, five minutes each speaker. You can do what you want. So our first speaker is Riyaz. I'm not introducing the topic. Let that be a surprise. I was not sure if this is, this is called a flash talk or a lightning talk. So I have both of them on screen, right? Between both of these. My name is Riyaz. I head the offensive security team at Apsaco. Essentially my team hacks into apps and servers host on the cloud and stuff. That's our blog. That's my Twitter. That's the company Twitter because I have five minutes. I'll quickly go to the topic. The topic is go home JavaScript. You're drunk. Okay. I'm not a developer. My essential role at the organization and all the experience I have in breaking stuff. Right. So let's see what I'm talking about. This is going to be interactive. Okay. All of your developers here. I need answers from you folks. Right. JavaScript has five essential object types. Right. The strings, bullies, integers, objects and arrays. Right. Let's start with numbers. So if I have an integer two plus four, what do you get? I mean math. What do you get? Six. Everybody says six. I have two minus four. What do I get? Minus. Okay. If I have not a number, which is, which belongs to according to the ECMAS spec belongs to the integer category. If I have NAN minus two, what do I get? Okay. If I have two minus NAN, what do I get? NN. Okay. If I have NAN minus infinity, which is also a number. What do I get? NN. If I get minus infinity plus NAN. Okay. Numbers are clear. Let's move to strings. I have the string ABC. Okay. I say ABC plus I do the same, but the change the order of the operands. How many is the object of it? By now you'll have realized the answer is not going to computer. You get zero, which is the expected answer. Now all of us, most of us, even from the security community are very familiar with the alert zero. It's the common POC that is used to show that you have XSS in your app and stuff. Now, when you, because, because it's JavaScript can be used to compute these strings, like literally character. Wow. I just wanted to give me, I'll just type out the whole internal typing and just copy out the whole thing. I have 10 seconds. Is it okay? I should have submitted this as a talk. Is it? What do you think this is? What do you think this is? It says alert zero. So I can choose to evaluate this. Okay. We also have a BOF session on Vue.js, which is starting about in the next five minutes outside. So, you know, it will be like a continuation, anything related to Vue.js if you wanted to ask, which you couldn't ask, you guys can ask. Next up we have Ashish. Hello. Yeah. Hi guys. Okay. So I have a very simple use case that we are solving. Like we were just coding and I came across a simple use case. So I wanted to just discuss since it's a flash talk and only five minutes I have. So like it was like, okay, I'll show the multiple timers at 60. Yes. So I'll show you what is it about. Okay. Okay. How much time is left? Okay. Where did my browser go? All right. What is happening? One second. I am not able to throw this. Okay. I'll do a duplicate screen. I'll do a duplicate display. Okay. I'm really sorry about that. Yeah. Okay. So this is the kind of use case we were solving. We were, you know, making this widget. So it's a pretty common use case, you know, like e-commerce website. We have this widget and there are multiple timers running, right? So now a naive approach will be, you know, to just set interval, like user set interval and like multiple intervals running. The problem is that, like, if I have around 20, you know, products and 20 timers for those products, they'll be like multiple callbacks running at every second and there'll be multiple layouts and pains within a second for the browser to handle. And that will be too much for the browser to render at 16 milliseconds. So yeah, the performance does matter. And especially now that we have released a PWA, we really need to focus upon, you know, achieving that 60 FPS. So what is the solution? Like, how do we manage so many timers? Like these can go to 40, 50 timers. Like how do we manage so many running so many timers at the same time? And yeah, the solution is simple. It's intersection observers API lights, like newly launched in Chrome. And that's what we used. So I'll just quickly show you what is happening here. So if you see the timer, right? It's 1137. I move it here. All the time has stopped. Only the timer that is currently in the viewport that is running. And then when I go back, it updates. So 10 seconds it makes a jump. But yeah, it didn't run for that interval. So the only timer that is in the viewport is running. So that way I can have thousands of timers and it will be 60 FPS. So like these are the small things we need to take care of, right? Especially now that web has to match the performance of the apps, PWA is around and these all kind of things that we really need to look upon. And we just cannot, you know, because if you don't use our intersection observers, the FPS will drop to around 510 FPS. So that is the use case I had which I had to share with you. Okay. Next, an ultimate flash talk by Siddharth. Is it already on? Is it already on? But now you can't see anything. So here's a free startup idea. Make a projector that just connects and start work. How do you... Okay. Thank you. Sweet, finally. Okay. Everything's super small. So I'm going to bump it up. Okay. I'm going to put five minutes for myself. Who here uses React.js? Just like a quick raise of hands. Awesome. Most people. So it's not a JavaScript conference unless we talk about React, right? And nobody did until last. I'm like, cool. Let me be the guy. Let me be that guy. How many people don't work with React? Like any other framework folks? Awesome.  So there's something that the React team launched just yesterday. So I'm quickly going to show you what it is. The idea is, I hate classes, so I don't want to write a single class ever again. This makes that possible. So it's cool. Okay. I have this number badge thing. It's like a plus minus, right? It doesn't really work because you have to write code to make it work. So feel free to shout at me while I make mistakes. So what, how do you actually make that work state? Cool. So to use state, I need to use convert this into a class components. I hate class components, but I need them. So I do this and then I need a render function. Right. I do a return. I copy this gibberish. I delete it. Hopefully it still works. Awesome. So yeah, then you need a constructor, right? So that you can declare state. So I'm going to declare a initial state of count zero and something broke already. Can you even tell me why? Super. Yes. Which I shall never remember in my life. So now I can delete the zero put this dot state dot count. That's cool. Now I need functions to add and subtract. So I'm going to have a function add. Let me use other functions. Oh, this is a class. Sorry. Add in add. I'm going to do it. This dot state where I can say count is this dot state dot count plus one. I'm already tired. Subtract. Subtract is I can copy this minus one. Awesome. And now I can say on click is this dot add. And on the other one, I can say this dot subtract. So this is how you build a counter component. This is like the hello world of handling state or handling data. So you do plus one and it breaks. Oh God. Yeah. So you can do bind this.  Or you can use this fancy auto function thing. Awesome. These work. Awesome. So I do a lot of beginner react workshops and imagine explaining what a constructor is. Why do you need super? What is binding? What is this? Right? Explaining this to people is super hard.  So yeah, I'm going to basically just discard all of my changes and we're back to a simple function that doesn't work. So they launched a new feature yesterday, which is called use state. Right? They used a, they launched a bunch of hooks called use state, use effect, use, blah, blah, use state. How you state works is inside your function components. You don't need class to have state anymore. You can call you state and give a default value like zero. It gives you two things, a value and a set up a value. I'm going to call it count a setter. I'm going to say set count. And so now I have state in my application. I can change the zero to count. And I'm going to write add function. So once add is a function which says set count to countless one. That makes sense. And subtract. I can say subtract is count minus one. And now I can use this ad over here. Say on click on click add and click on the other one. I'm going to say subtract and it works. So you can use state inside a function component and it looks super pretty. You don't have this. You don't have a constructor. No super.  And it's super easy. So I can actually confidently teach this to people and it won't be a pin. Um, now you're like, yeah, so that nobody writes code like this anymore. Come back from 2005. Everyone's doing redux and reducers now. So cool. I have a reducer over here. I'm going to use use reducer, which is also a state hook. And in my component, I can say, um, I can say const state and dispatch with a use reducer where I can pass the reducer reducer and pass an initial state for me. It's count zero. And then I can use state dot count. And instead of add, I'm going to say read a function and dispatch this whatever over here is. Do the same for subtract track. And you can have reducers and they still work with this stuff, right? So you can go to react.js.org slash hooks and you'll get an intro to hook. There's like a huge awesome thing. You probably never have to write a class again. I mostly am not, um, also I'm out of time. So thank you. Okay. Our next flash talk is from our MC, Nitesh. He wants to talk about the types of people you meet at conference. So let's get round of a plus by the time he sets up. So perks of being an MC. You get to do this. Uh, so I'm going to talk about types, not the types we use, but types of people you end up meeting at a conference. Okay. So we had a lot of tech talk today. So this is like more of a people talk, person talk. And, uh, over the last whatever, uh, few years that I've attended, I've like sort of categorized people, no offense meant to anyone, but, uh, the types of people you meet, you know, at these conferences. So the first, uh, what I call this, are the intrigued, right? The people who come for the first time, uh, get to learn a lot of stuff from the speakers. Uh, but the thing for you guys is what you can probably realize is if there are people talking up here, you can also be one of them. Uh, if they're implementing something in their company, it's probably you have also done it, but, uh, these guys are here on stage. Uh, a number of times, uh, first time speakers are, uh, scared because they feel you know, stage fright. There are going to be so many people, uh, you can get rid of that. Uh, you're in Bangalore. There are meetups in almost every language, every framework. Uh, you know, all of them have Twitter handles, contact, uh, some of them, you know, get started with that. The next, uh, is who I call the Gyan Baba. Uh, you will have people who will give you opinion on everything. Even if you've not asked for it, uh, you will meet people like that. And, uh, for someone like when I first started talking initially, this can be very intimidating. Uh, so for people for you, Gyanis out there, uh, if you've realized that a speaker's probably made a mistake or has not, uh, you know, stuck to your architectural design patterns, uh, rather than asking him a question, counter questioning, counter questioning again, maybe you can go out, meet him outside, have a healthier discussion. Uh, you know, it's a lot better. Uh, also gives more confidence to first time speakers. Next, uh, the personal favorite of the category that I belong to are the trick or treat, the guys who come for the stickers, the t-shirts, the, all the good stuff that is outside. The cupcakes also today, which were very nice. Uh, the next one after this is the Godfather or the people who want you to work for them, trying to tell you that, hey, uh, we're doing this thing, maybe you can work for us. Uh, you'll find them also outside. If you're planning for a career change, whatever it's a good time. Um, another one, you'll always find the manager who will be there. Uh, silently, probably while discussing something with him, just slip it across that he is engineering manager of some team somewhere leading something, hoping that you've caught on to that. When many times you don't, and then, uh, my favorite, or I hope I think most of you guys might also be in this thing, which is, uh, work from home, right? Uh, everyone's put that in their office today or something like that. And, uh, they're over here. Uh, oh, it's a nice escape route. Plus you have to, uh, like a Friday and then you get a long weekend. So yeah, that's about it. Uh, that was very short and sweet. My name is Nitesh. Uh, it's my Twitter handle. I do a lot of ranting on Twitter also to end with a note. Nice. Okay. We have time for like one more flash talk. Hey, just give me a sec. Yeah. So, uh, my talk is about, uh, just a little thing about, uh, an integration test that I wrote with, uh, Kukumba just in perpetrator. Let me quickly introduce these terms. Kukumba, right? It's just a simple collaboration tool, mainly. What it looks like is this. So imagine you have a login feature, right? Your product manager comes and tells you, I have to write login features. How will they tell you what the login is? They'll be like, I'm a registered user. I log in with some ID and password and I'm getting redirected. That's my login flow. Or for example, Google search. You search something you should land on the login page on the search page. Right. So this is all very natural language way of writing your features. Right. Now, uh, what I do is I convert them directly into code. I will take this, put this into my code base. So you see right there. There is the login dot feature file. So it will show you like the same text written in proper three lines with these keywords, given when and then what this converts into in the end is this. So it will look like this. Given I'm on Google.com. So you can just launch a environment of Chrome. This is something I use called puppet air, which is made by the Chrome team. So what you can do is just go to that page page. You can define here as Google.com. You wait for an input box. You can enter some text in that. So let me show you some actual live example running. This is a quick video I made of the example. So this runs the test and shows you. It opens the Chrome. This is happening on its own. The Chrome is controlled by automated software here. As you can see. So it opens the Chrome. It will go to the website. It will wait for the input box to appear. It will enter the text. Click on login button. Take you to the URL test that the URL exists and then exit the test. As you can see, it's happening a little quickly. The test failed here for some reason. We'll have to investigate. But yeah, what you can do here. What I've done basically is I did this. I have an input selector. I use CSS to select it. I enter some text here. I expect the page to fill this. And in the end, I expect the page to contain this. So all I'm doing is testing the URL right now. You can do any kind of test. You can test for any part of the page, any CSS. And what lets you do this is two things. Cookomber and Puppeteer. Puppeteer is just a headless environment. Runs in node.  If the test breaks, you can ask it to take a screenshot for you. You can ask it to tell you what exactly broke. And you can see a diff between the two things that broke. So you will get two screenshots showing what has to be and what will be. What is the actual thing happening right now?  Make sure nothing breaks visually also. Not just your unit test. So this is how we write integration test at the place I work at. I work at this company called Locus. So just a quick look. And yeah, the Puppeteer also lets you have, capture all these metrics like performance test or network calls. You can test your APIs using directly this. So yeah, it's a very quick tool that you can. This I came up with this in like a couple of days. So doesn't take too long to implement is very useful for your pipeline stuff. That's all right. Thank you. Thanks, Kalash. So our next speaker is a polyglot and he loves cooking. So he right now so far we have seen so many front end, one web security and stuff, right? So you might be wondering, what are the back end, how it is getting developed in nowadays? Like there is something called GraphQL serverless and order the ES6 features in node back end too. So let's see how we can develop scalable NodeJS applications in a back end. Shahid. I'm Shahid. I work at Hasura and I tend to shamelessly plug my Twitter handle everywhere I go. So please follow if you like what you see here today. I'll be writing more about these things. Cool. So I work for a company called Hasura. Most of you might have got Hasura stickers and would be wondering what it's about. I'll come to that towards the end. And I would like want to start the talk by reducing a problem. This is something that everybody would be aware of or you have seen in your life at some point. Before that, can I see how many front end developers are here? Just raise your hand. Okay. Awesome. Back end developers. Cool. Is there any other category of developers here that I'm not aware of? Full stack. Okay. Who is full stack? Okay. Grass stack, jam stack, a lot of stacks are there. Okay. Any GraphQL users here? Serverless functions, function as a service. Awesome. Okay. So most of the stuff might be new for a lot of you, but that's the whole point, right? Cool. So let's see how we can build a typical application. You have mobile app or website or something of that sort. And you will be contacting an API layer, which will be talking to a database, which will again be talking to multiple other microservices. Or as always, there's the monolith where everything is there inside. I'm not going to that part because hey, we are in 2018, right? Like monoliths are what, 1990s maybe? Anyway. So you have this microservices talking to each other and this particular microservice that I'm introducing here, we'll be using them throughout the talk and towards the end of the also. So just keep them in mind and you might have guessed already what this application does, right? Let's you order food. So any, any thoughts? What kind of issues this architecture can have? I'll give you a clue. Two of those issues are in the title of the top. Any random shout outs? Huh? Yeah, scalability, resiliency, but why? Why is it not scalable or I'm assuming that it's implemented in a naive way. Okay. Of course, you can make this scalable. I mean, all of us can do this, but I'm talking about the naive way of doing stuff where you make a request from the application. It hits the API layer, API layer does everything that has to be done in this case. It's it makes an insert into the database validates the order or process the payment and assign a delivery agent. And after doing everything, it returns back to the client. Right? So this is a synchronous action. You are doing some something on the client application. It's going through the entire flow on the back end and then coming back to you. Okay. I'm talking about this scenario. This particularly is not scalable as always. Do we all agree to the fact that synchronous actions are inherently not scalable? Like you can't do thousands of them at once unless you allocate the required resources, right? We agree. Anybody disagree to the fact of all of you don't have very strong opinions or trying to be very liberal, post your nice snap after the lunch. Which one is it? Okay. Anyway, so resiliency is something that you build into the application there. Right? So what happens if the restaurant microservice your interaction with the restaurant microservice fails? Like you need some that microservices crashed? Like how do you start the process again from that point it failed? Right? This is something that you typically build into the app. You'd write code to do this. Now a typical solution to this problem. When we see that most of my issues are due to synchronous things happening in the back end. What is that golden hammer that comes to your mind? Let's make it. I think, right? Let's make it a sink. So now I'm making it a sink. Let's see how an asynchronous architecture look like. So you have the IP layer again. You have the database and you make a insert. Let's say an insert in the database. You have something like an event system. Like you will keep inserting events. Other microservices will consume these events. They will process what is meant to be done. Right? Any of most of you are familiar with this architecture. Right? Yes? No? Yes. Okay. Awesome. Cool. So this is the typical async architecture that we see where you have, you interact with the database. Your state is stored in the database and you execute certain action based on events happening on the database. Right? Nice. But microservices are again like monolith. So 2000, right? Maybe like last year. What is that about serverless? So let's talk about serverless a little bit. So my aim is to replace my microservices with serverless functions so that I don't have to take care of a lot of things. Right? So I saw there are very few serverless users here or functions as a service users here. So let me just introduce what serverless is or what this lets you do. Right? Typically when you need to write a web service, you need an API which tells you hello world. So this is my express code for that. Typically you would write this function and then you will have something like app.use or app.listen and you will maybe run this on a typical VM with PM2 node whatever just write it right around it. Or if you are fancy enough, make it a container, talk a build, talk a push, maybe put it on Kubernetes. Right? So serverless functions or serverless frameworks or serverless platforms, what it lets you do is this. You typically have a command line tool or a UI where you just paste this function or you just execute one command which will take this function which is in one index.js file and it will give an endpoint to trigger that function. So this will give me this URL and I can just call that URL and I get the response. So it's scalable by default or scalable by nature because you are not managing any CPU RAM or anything. There's no ops. You did not deploy the code. You did not access it into any VM. You did not create any servers. You did not care about CPU or memory and it just works. Right? So there's no VM to manage. Don't need to worry about scaling and all serverless platforms are scalable by default. You will only talk about the pricing page. You look at the pricing page and you'll say free for a million invocations a month that itself sounds like scale. Right? You can trigger it how many of the times you want concurrently. You can trigger it once twice or 10 times at once. So scale for free. I said most of the cloud cloud platforms like AWS Lambda Google Cloud Functions Azure Functions all of them are very generous free. You will be able to deploy these two very generous free tier which is like a million invocations per. So this is freedom. Right?  Full stack developers are here. I just want an API to be available for my app to work. I exactly know what it does. I don't want to go to the hassle of creating a VM deployed and do whatever. Right? I know the function. I know how to write that code. I just want this code to be running somewhere so that I can trigger it using an API call. But is it resilient? So we talked about scalability. Is it resilient? If some serverless function fails, how do I restart the same action? How do I trigger the same action again? Right? Serverless functions by themselves are not scalable, not resilient. So what you have to do is you need to throw in some idea of state because they themselves are ephemeral. You don't have any idea of state. So you store your state in the DB database. For example, in the earlier case, you say payment done or not done. You store it in the database and whenever something changes in your state, you trigger events. You trigger the serverless function on this database events. So what that means is you when you have this event system and you try to trigger the serverless functions on this events, you and add interest to the mix, you get resiliency. Let me explain that by taking an example. So here in the earlier example, we have this food ordering app, right? You have this schema. This is your table. This is what your order table looks like. And now you create a new order. This is the state, right? Now there are four steps here, which is very important. One is valid. Where the restaurant does the validation. Another one is paid is approved and is agent assigned. Let's look at the flow using the serverless architecture. A new order is placed. Now this is the database state, right? Everything is false. This particular database state will trigger an event which will trigger a serverless function, which does whatever logic is required to validate the function. Now that will do the act, whatever logic that is required and comes back and updates the database and says he's related to this particular action or this particular event of is validated being updated through will trigger another serverless function, which will again come back and update the state and which this kind of these things. This continues over all the steps, right? And finally, when everything becomes true, your order is completed. Now your client just created an order, right? You may place an order from the client. And what happened is you replaced your earlier synchronous microservices architecture with serverless function. Your microservices become serverless function. Serverless functions are asynchronous and scalable by nature. And when you trigger them using database events, you get resiliency. But what is the cost, right? You don't get anything for free. You can do all these things. But what is your cost to do this? Nickloos, like you talked about event system and all, like select something that is available on the road. You can pick it up off the shelf with it, right? What you did was you moved specific error handling or failure handling logic from the API layer of yours to another system, the generic failure handling system, which is the event system, right? The cost is in this asynchronous architecture. You need a generic event system which will be able to trigger microservices or serverless functions or whatever, some webhooks or some logic when database actions changes. And you need asynchronous serverless functions. So what we did was we took this architecture, we took the synchronous portion of it. We made it asynchronous by introducing this new architecture. Again, what's the catch? This is still a problem, right? Your client made an order earlier whenever the order was completed, the client got an update back. Now, whenever something is happening on the backend, how does the client know whether the order is validator, order is placed? You get a response immediately when you place an order. That's what we showed here, right? You make a database insert, you get a response back. So how does the client know what is happening in the backend? So how do you send this asynchronous thing that are happening in the backend to the front end? So GraphQL is like this new person in town. So very few people knew GraphQL, so I'll just make a small GraphQL intro. So you have a typical rest, in a typical rest scenario, you will have this product or this particular endpoints to which you do get, post, patch, all these requests, right? All these methods. And you get response back. So if there's a product and you only want to get the name of the product and nothing else, you would, the backend has to implement something like columns equal to, customer columns equal to name or something similar, right? So using GraphQL, the query looks like what is there on the right-hand side. You write something called a query and you say what is it that you want to query and you get what exactly you asked for. And if you want to query over multiple relationships in a database, this is how you do it. You test them inside the same object and you get that response back. How many of your React developers? Angular? What are the rest of your views? View? Vue.js? How many? Okay. How many of you? Still jQuery, huh? It's 2019 almost. So React has, React and all these modern UI frameworks have this UI or component-based architecture, right? You write a component, you use the component everywhere, you reuse the component. So when you have a component, let's say you have a profile, use a profile component. You need to know the user's name, a link to a profile picture and let's say the user's location. There are three things that are needed to render this profile component. So you can write a specific GraphQL query to only fetch this information. Profile, name and the image link and the location. And you can wire it up to the component and that's it. Your library will take care of everything else. You don't have to get the response from your REST API, transform it to what you want it to be to pass to the state of your component. All of these things go away.  They were like sleeping or I'm on vacation, I'm on leave, I'll do it as soon as I'm back and your work gets put on hold because of that, right? All these backend front-end interactions will go away in this scenario because there's one endpoint which exposes everything, of course everything that is allowed to be exposed and then the front-end can decide what they want to see exactly, what they want to query exactly. So this kind of puts UI first. You decide what your application needs to see or what your application needs to show on the front-end and depending on that you do the database modeling or you write the right query to get the correct information. The amazing thing about GraphQL is subscriptions. Now we talked about all these things that is happening in the backend where the order was being validated and you need some way of sending this back to the client, right? That's what we stopped earlier. So you need some way of consuming Essing information from the backend without worrying about too much stuff. So you know that REST has a watchword. How many of you have seen this watchword or used it somewhere? Squinting at the Kubernetes users out there. The Kubernetes has this watch method. It's not a standard spec, I guess, but they have implemented it. It let you watch over a resource. Basically it will open a web socket connection and sends you updates over that web socket connection. GraphQL subscriptions are exactly like that. You have a database. You will be able to send information to the client. Not when the client asks for it. That's how REST works, right? The client asks for it, you give it back. The client uses, let's say the client opens a subscription. It's like a web socket connection. It is a web socket connection. And you will be able to send data from the backend to the front end using GraphQL subscriptions. For example, this is our food ordering example. You had payment. This is the order table. You had two fields. Payment is payment and dispatched. Over time, both of them becomes true. You want to show this on the UI. Hasn't when it happens, right? What would you do? All the front end developers? Like you have no idea about GraphQL. Like how would you do this? Polling. First solution is polling, right? You keep polling the backend, REST API at a particular interval. Somebody said sockets. Now sockets are not something the friend developer alone can do, right? Polling the friend developer alone can do. Pardon? Real-time DB, yeah. Can you name one real-time DB? Firebase. Anything else? A lot of your couch, couch DB, reflex, rethink DB, a lot of real-time databases are there. How many of you are all actually using that? Firebase, I agree. Many might be using. But other stuff? Firebase is a non-SQL database. We need to take that into consideration. So, the second solution is to use web sockets. There should be a contract between the front end and the backend. Both parties need to decide on a common contract to send data across, right? Again, the same problems of REST API comes here. What if you want to get one more field in the web socket response, right? You need to again paint the backend developer. So, you do polling, you do web sockets, custom API, but those who have implemented web sockets would understand community is really fragmented. Socket.io and all is there, but still have you tried making a JavaScript client talk to a... maybe the other way. So, integrating different frameworks and different tooling is very difficult because the community, there's no set standard which says this is how information should be passed around through web sockets. It's up to the developer to decide, right? The front end and backend developer decides this is how we are going to do it. Or most of the times one party decides, right? Other one has to just do it. So, with GraphQL, this comes down to very simple mechanism. So, the spec is standardized. Everything is set on or in one GitHub. Where the spec is written, this is how the client should interact with the server, this is how the server should send the information to the client and all clients implement this spec. So, all clients are compatible with all servers. If the server says I'm GraphQL compliant and the client says I'm GraphQL compliant, it works. This means most of the work is already been done by the open source frameworks and libraries out there and you just have to implement it. You just have to use it. This is what boils down to when you have when you have to do the thing that I showed you earlier. So, it just becomes this. Instead of the query, you will say subscription. That's all. Your React framework or your React library it's called Apollo in React. Most people use Apollo and it will be it will get the update from the backend and will refresh the component automatically. So, whenever any of these things happen in the backend you will be able to get that update in the front end. Now, of course, you need a GraphQL server with subscription, right? So, we took our simpler architecture earlier and made it so complicated and we need all these new things to be done. So, going back for a comparison this was a traditional architecture. We said that that is not scalable because it was synchronous. This is my asynchronous scalable architecture and this is my GraphQL and serverless architecture. So, you have an application and you have something sitting here. You have it interacting with the database and you have GraphQL client is interacting with the server with GraphQL. Server is also triggering serverless functions based on the actions happening on the database. Which is again updating the database back and forth and so on and so forth. So, some fun, right? A lot of theory, some practical stuff has been done. Cool. But I hope this works. I heard there is confidence Wi-Fi. Myself, I am connected to it. So, let's see how it works. Why don't you go and scan this QR code? You will be taken to a page which says order app, analytics app. Preferably go to the order app and we will come to the other ones. So, how do I do this? So, what I am going to do is this is an example application built to demonstrate this scenario. So, I will also do one. But it is already messing with the some. Okay, so I will keep this on one side. Other stuff on the other side. So, guys, so when I place a new order what happens is I will be able to see the status in real time. Whoever is placing this, thousands of orders please make sure you pay for the order. Okay. Otherwise it will be just stuck there. Nothing will happen first. So, this is the number of orders being placed. And now this bottom graph are the number of orders being validated. Okay. And then the payment happens. Then so and so forth. The validation and the restaurant approval happens. Now, while this is going on we can stop ordering and please listen. So, I would just like to show you what's happening here. So, this is the code. This is a react application where you are placing the order. So, there is this place order.js function where you are just doing this thing called mutation which is inserting an order item, right? When you place choose the item, it is inserting into a database. Now, all I did here is to write this query and this on click function is bound to we saw that like me talk how this happens. So, whenever the order is placed this is how it happens. So, this is how the items are loaded. So, you say query and you say return you will render the item name in a checkbox. So, compare this to how you would use a rest API. You would use fetch, call an endpoint get the response that responds back into the state and then render the component, right? So, here you have a component called query that is available and it just have works right away. And this is how you are placing the order mutation is place order and the order gets placed right away. So, whenever you want to see the status of the order this is what happens. You have a subscription. This is the live status. Your order keeps getting updated. This is these are the fields that I want to show and these fields are mapped to the component right away. So, here you can see payment status is shown and the subscription component is being used here and based on that I am rendering this template and the status is rendered by this one. Now, when you place that order wow nice please please play for these orders otherwise it won't move over. Okay, I am being generous. I will pay for all of you. So, this is what is happening in the back end. There is an order table and whenever you place an order send me who is L-E-L-L-O-O-O I want to see this person please raise your hand the one who is messing with my demo reveal yourself please No? Okay, we will find you. So, server. So, when you place a new order what is happening is this serverless function is getting triggered. So, this function is hosted on Google Cloud where you can see validate order you can see the number of invocations for the last one hour. So, it is going pretty high right now. So, whenever you are doing any action here the corresponding serverless function is getting triggered and you can see it is climbing slowly. So, this is partly because Google's invocations per seconds are very low like 16 server requests per second and you can see that as I know it gets time it happens. So, let's try to pay for all these orders oh my god this person So, I am going to pay for all the orders. So, what I am going to do is I am going to update the order table and set is paid to true where is validated is true. So, those who are familiar with GraphQL will understand what this is and once that is done tell me how many rows were updated. So, I can execute this query and it will tell me how many rows were updated. So, 18200 orders have been paid for. So, you can see this massive jump here right this green jump is due to the orders that have been paid right. The valid order function is still being very slow in getting invocated. So, I will have to resort to my videos because of our said question who is placing infinite orders. So, we saw how we can place one order and whenever we make many orders this is the ideal situation would look like. So, this is what happens right when you have a system and you didn't design for the kind of scale that you expect even if you call the even if you call it scalable resilient whatever you need to have an anticipation of that scale last time I did this demo I got around 40,000 orders and I was under the same impression but yeah you guys are really awesome. Not you guys or everyone that one person. I will find that one person.  So, the idea is whenever so this is the ideal scenario the validation will go on. So, I only managed I only configured this to handle such a number of scale. So, you will be able to see the validations are going on and whenever all of the orders are pending payment so when you pay all orders suddenly the payment thing jumps and the other step which is the restaurant approval continues to happen and once that has reached a particular state the next function which is the delivery assignment will continue triggering. So now, imagine building an application which can handle 50,000 orders this kind of scale and all if you have to handle this you have to work I don't even know how much this is just like front end hacking just a couple of react lines and one database model that's it done. So, let's say when your network breaks down that I don't really show you that on Google system because there's no way of turning off the function. So, I'm making some orders so I have paid some 1000 orders and the validation is happening and payment has also happened and this is my restaurant approval function this is on AWS Lambda this is button called throttle throttle button and the function just drops execute you cannot execute it anymore. So, these many approvals have been done and this many approvals have been done and the function has been throttled by this time and this many restaurant this many delivery agent assignments also have been done. After that just flatten or nothing is happening because this function cannot be triggered anymore. So, once that so everything is stuck at restaurant approval so once I have I make the function run again where is 10