 So basically, I'm Debbie, I'm one of the founders of Weeper Technologies, we developed cool location-based mobile applications towards off-line commerce. So basically we want to help you find, basically engage with the off-line brick-and-mortar retailers. So through basically the mobile applications, through websites, by SMS, it can be anywhere. So that's what we developed. And yeah, we developed DirectCircuit, which is a location-based shopping app, which is available over Android, Blackbird, Android 4 and 5, as well as on SMS. So based on my experience in developing client-side, I mean, so we have developed a DirectCircuit web app as a basically client-side application. So everything is done client-side. So based on my experience, so these are some of the pros and cons, I figured out why developing a deep client-side app. So firstly, I mean, I want to give you the basics of what is client-side, templating and so on. What happens in typically, like, so there are different ways of developing a web app, right? So in many of these applications right now present, so basically the server renders all the HTML and then is sent to the front end. And the clients are just done, they just basically render the markup. So the HTML is not actually rendered in the client, they're basically all the HTML is rendered in the back end with back end templates or rendered in the back end. And just the markup along with the data and everything is sent to the front end. But recently, many clients at NBC frameworks came up, so we basically want to change the way we develop web apps. So what happens in the client-side templating? Basically the server sends the client templates, which are also the static assets. These templates are nothing but some snippets of HTML, which basically once you give the data to the template, it basically renders the view with the help of the template. I'll give you examples once I go more inside. I'll give you an example of our application. I'll just show you the code of our application and show you how it actually works. So server sends client templates and the application code, which is basically the JavaScript code. And then the application code is the view, which is the initial view. And then as the user interacts with the front end, the website, with the other website. So he clicks, he basically does different kinds of image. So the requests are sent to the back end and the response are again come back in the form of JSON. And then the JSON data is again basically rendered in the view by basically applying the data to the templates. So I mean it can be more abstract right now, but I'll just show you once I basically show you the example. So what are the downsides of server-side templating? So before we go to client-side templating, so why should we go away from server-side templating? Because it's coupled. So in the basic, the difficult server-side rendering approach, so everything is coupled. In the sense that the client code as well as the back-end code is coupled where you actually... And a single person has to work both on the client-side code and the back-end code. I mean the response is not shared. That is one big problem with the coupling design. And that results in actually a lot of problems like you. One example is basically the client-side code becomes updated because of basically it's very coupled design. One thing is actually if you look at the other problems of server-side rendering. Let's say a simple post on Facebook, which is along with the comment. It basically results in 9.1 KB of markup. Because though the data is very small, with the markup along with it, it becomes basically very big. Because it has a lot of HTML and then the events get up and everything has to be sent every time the request happens from the client. So there are a couple of things. First thing is, let's say there are 1000 requests per second happening from the client. So then every time the HTML has to be rendered in the back-end, and then it has to be sent to a friend. So even if the templates are simple, every time I have to do this step. So there are a lot more processing to be done on the back-end than on the friend-end. Even if the clients, basically the browsers, are very much more powerful, though we are doing the rendering on the back-end, and then the infrastructure has to deal with, has to scale with that. And then the other thing is the caching. So if you look at client-side template, if you do the client-side template, because all the assets are static, so then these can be cached. Whereas in the sub-side approach, these templates can't be cached, and every time you are rendering always in the back-end. So though there are some kinds of caching in the back-end, the templates can be cached, but it's also the best way. And mainly the final point is the transfer of data based markup for every request. It's not the efficient way of doing things. Which is going to dump clients. There's a lag in the request response times. And also, which also is a link in the optimal experience because the user has to pay for every request. Are we talking about a full-page report or caching data acts with the snippets coming up? Yeah, so basically there are different, yeah, it is, so you can say 100% client-side or 100% sub-side, right? So there are two differences. If it is 100% server-side, it's completely fresh. So that is completely unoptimal in the experience. And if it is some part of it is server-side and some part of it is client-side, then it can be better. So here I'm actually leaving the complete server-side, right? And yeah. Full-page. When I take an action, it's... Everything happens. If I just get these people snippet for what needs to change, and then run it then. So there are two different things. So there are a couple of things. I mean, yeah, actually I think the things which I mentioned actually contain both partial thing as well as the complete one. Because in the partial thing, let's say the complete thing is basically, you have to do a complete request. Where you basically, for every request, you do the complete request. There's a partial thing where you say that when it comes to an event, I get the response from the back end. But the response from the back end is not in JSON, but it's again in HDI. So there again there is, there you are rendering the templates in the back end and then sending the HDI. So these are partial. And then the complete 100% client-side approach is basically, you send the data in JSON, then rendering in the client-side. So there are the three different approaches. So here, I mean, yeah, actually it's a mixed up, the partial and the 100% and I can show you some of the client-side code which I can actually basically, so I mean in our applications we have used two approaches. I mean basically we have two platforms, one is merchant platform and one is front end application. For the merchant platform we have used back end rendering, we have used back end testing. So I'll show you one code, I mean some part of the code which we actually use. So these are back end server-side template. So these are basically server-side HTML. And then I write, so these are HTML, though it's a front end HTML. So these are client code looks completely ugly because I have to write all the back end stuff also in the front end HTML. So the guy has to write, I mean the front end guy has to write both, I mean the person who is implementing these has to write both the front end code as well as the back end code character. Otherwise if I use it, if I complete it with the client app, so I can say, I'll give you the API to the front end guy saying that these are the APIs that you call. You just need to make these API calls and then do the rendering. So then the client code actually looks much more better which I'll actually show you today. Even these server-side implementations have to be much better than this. Like there are things that you can use on server-side which can suffocate the logic out of the... Yes, but then there's a problem is that This is one part of the implementation. It can be done. It can be done, but the fault is there also you're also rendering but there's a bug here as well. So I'll take that, but you can't show this code and say all the server-side has to be this way. Exactly. I mean, we have two parts of this, the same thing actually. So we have used jQuery templates also where we have done that. So then what is the possibility of the client? I mean the client. One is decoupled design as I mentioned. So basically the complete back-end and the front-end are completely complete. And then that results in a good application because in the back-end you just say that through back-end you write these APIs. You say, okay, let's say we are doing something else to do this time. So you need to write that, basically the APIs for this, okay, get all the tasks, add a new task. For all these things you just write all the basically the APIs also. In the front-end you basically say that there's nothing you need to do except to use a back-bone or MVC any kind of framework which can actually sync with the back-end automatically. So that's what you basically share the responsibilities and then this guy only leads to the front-end and this guy only leads to the back-end. And then the best part is the we are best part of that. Actually, I mean, I would tell you why we used, I mean, why did we go with client-side application for client-side because we we instantly developed a client-side application. And then we wanted to develop API-based platform approach so that right now, if we can go with mobile app then basically we have a web application and we have a mobile web app. Tomorrow I need to expose the APIs to someone else outside. So right now I mean API-based approach is very much basically we are getting popular if we have the vision of basically exposing the APIs to people outside. But there are cons of using a client-side application which I'll come back and which is leading to better structure separation of responsibilities and since if you use a client-side application all the assets are static even the HTML, JLS, CSS and the template all are static. So what my web app server has to do is basically it can use an engine server in which basically just direct it to a friend without doing anything. So it can be a simple server and most static assets results in easier performance I mean better scaling approach and simplicity and power. And why should I use a template engine? Why not just write using JS? I can write using JavaScript like use push or direct array list and all like render the HTML why should we use a template engine? The template engine is much more regular maintainable basically good since you keep the templates after it will automatically change and then automatically change and then it's usable and then it's understandable, that's the main action. So what are the cons of the client? So these are some things which we experienced is one thing is the main thing is performance varies with the browser it's a big problem because you don't have a client's application but you don't actually the performance varies with any user who basically uses from a different browser, that is the main issue. I mean a person who is using from Chrome 10 or like Firefox basically the performance varies because it's a client's application you don't know whereas in a server that is rendering, I do everything in the background, the browser just has to basically render the HTML in the background. So that is the biggest issue with the client's application and the other thing is a build process is generally required because I can show you some because there is a lot of tasks which we use like ours there is a lot of tasks that we use and then each JS you write it so basically why do you need a build process? because you need to have HTML, you need to verify the CSS you need to verify the JavaScript, you need to combine it together and then make it such a way small so that it basically otherwise it becomes the first thing is to let this amount of HTTP be caused to make it to your server the second thing is the overall size of the Gmail such to be reduced to a less so that the complete JavaScript actually can be caged even in the front end and another biggest problem is the search engine indexing so I mean you can't there are pretty good hands-off indexing pages to search engines but the problem is this Google has basically provided this format you have this hash format which makes the JavaScript websites but the problem is if you are using a client application where the JSON is sent from the back end where not the JSON is sent from the back end the only way you can do is basically you have to generate an HTML snapshot every time you get a request you need to identify that a request is coming from the search engine and then you would basically write an HTML snapshot from the view of the back end basically using a headless browser like HTML or something you need to generate HTML snapshot and then send it to the front end this promise won't actually execute the JavaScript promise won't execute the JavaScript so basically you need to have to use a headless browser to execute the JavaScript and generate the HTML and then send it to the search engine so this is the biggest so I think there is one problem so many people who basically I mean generally that's the reason many client applications are basically more SaaS based applications like Asana and these kind of people who are not consumer oriented applications but there are pretty facts about these 5 buttons history books bookmarks all those things yeah yes we will do that I mean I tell you once we go to the framework I will show you the code so basically yeah all these back buttons and the exact bookmarking and everything there is no issue because the MEC frameworks have basically came to the attention that they had it on them but it's still very complex to do it I mean use backbone books and the game actually mentioned for generating a scale I think it's not made to be good it's not made to be good no that's what they there is a clause which says what you show to the user should be what the search engine says exactly but I do the same right you are not doing the same you are sending different content no that's what they mentioned in the standards basically our communication is JSON we need to do it this way that's what they mentioned as long as you are showing the same thing for the user as well as see here I am basically using headless programming and I am making the same API called to my web page generating the same thing what about all the interactions the names when I click the next page should come out your site should be discoverable not just the page should be visible to the search engine every action that I want to perform I want the search engine to perform the action and go to the rest of these yes exactly when you render it so again if you keep in touch with the good anchor tabs then you are basically doing handling again by your task if you use anchor tabs again the search engine will go through them have you looked at using the same templates on the server side also or is it like two different implementations one for the browser and the search engine no no for the search engine so you are using the browser yes in the search engine what I do is I get a request to my engine so I get a request from the search engine I identify with the step target and then I send it to the headless browser with a different server and the headless browser makes call to the same URL which basically puts time to index generates the html basically by excluding the thousand and then send it to the and basically this is what basically we have this 100% server side or client side so which is the best way so most of the server side rendering plus JSON browser has a client side template can be the best path we can do the first thing is that this is the number of requests and shares rendering load between client side and server side so you can use the handle model of things so I mean now I would like to show that demo it will be more creative so basically our app features like we use in front of this background or with moustache template and then because we have written our background basically on adb, uwjs server which basically expose a and then we use front end to basically consume this so we use the adb platform approach our web app is nothing but just on the client so I mean we can also use platform so it's a proven client side and basically we use it by many other startups and then moustache is used for client side template and then jQuery for normal integration and then this icat has which is a jQuery library which basically works well with both jQuery and moustache because moustache has a different kind of syntax so basically I can basically separate it so I would go basically for minutes I'll show you a flow of how our application works I'll show you the code what structure is it so this is a typical background application so in a typical background application so I'll tell you one important thing is there's nothing in so I mean in html there's not much I'll show you let's say this is our index on html I'll show you one cool part in our complete index on html if you look at our body there's nothing in the body these are production application of course there's nothing in the body everything is in the templates so these are all the templates these are all the moustache templates so in this we add all the templates and actually we use require or something to basically download templates whenever required the industry is downloading all the templates at the time these are all templates and these are all our java scripts these are all our java scripts and then I'll show you a structure of this and there's one thing this inshades application so this is the first thing we basically execute and this is inshades application to show you the structure of a typical basically I mean basically the planche app we use something similar so there's a structure I think if you look at there are many of these background applications so you must be actually because we use background MVC so we have models, we have views, we have controllers similarly like we have MVC approach in the packet so the models views and the controllers we have so I'll just show you a typical flow let's say the application is initiated and then there's this inshade which calls and then there's a router so these are the routers basically basically giving up on these routes the corresponding functions are called so I say let's say oh it's called actually that is the controller let's say load offers to give an example I just want to show you an example of this page where basically I want to show you how the offers are already loaded so here basically the function which is getting called is basically this load offer search so when you look at your search slash offer slash so basically these are the functions which is getting called load offer search so this gets called and then this basically invokes the function load offer search basically depending on where it is where it is in so this is the function which is getting called so in the terms of like frontend testing where for all these JavaScript do you use jasmine no no we haven't done verification, task verification verification and then basically we modify customers and then also pass the syntax I mean that is the main cross we will do that later so this is the API call which is the API call it takes an attribute and the query which basically makes the API call so we have written a registrar which basically makes the API call to the server like the given parameters once it gets the data it basically calls back the data I mean if you look at this callback it takes an API offers so this is the registrar request which basically sends the request to the server and then once it returns the data it basically keeps it in a de-selection de-selection is basically a modal which is the collection of files so in backman you basically have it have models and then collections so I keep the API offers in a collection and then basically it calls back which again which here you get app.views or offer collection item so this is a view there are controllers controller basically calls basically to the server and then keeps it in the models which is basically a collection and then again it gives to the view to render the view and that view basically renders it so that is the read path so this is basically and then when that's ready good things we could do with backman which is the same path which is the same path where you actually like let's say you have to do this type so where you basically have all the backend API is basically for the task and then you have frontend APS I mean frontend views for the task let's say I remove a view basically I want to delete the task so you can hand in an event for the view saying that this event has been removed automatically so when the view when it is removed from the view it basically involves the model it is saying that this task has been removed so then the model it is also removed from the model automatically when you basically write it in such a way then the model is removed and then what backman does it also it automatically since that's how it works so I am going to say that this that task has been removed and then basically the server basically syncs in the data so that's what happens you basically say again if it's a task then the model is actually refreshed when it refresh the model then you actually again you can refresh the view automatically so backman works in either ways so you can either write events write events automatically for the views you can write events also for the models so you are not using views so yeah we are not using these things we are using because we didn't actually writing that if you could have developed in the client's application in the web app afterwards from the start then you would have if you could have developed it so there is one problem in the crossing provides so we basically our web app is in so our backman is in api.religit.com because we need to isolate both the frontman web app as well as the backend web app because there is one thing because we want to keep the production isolated from the backend setup isolated from the frontman and the other thing is it's also a secret matter of secret so how do you basically cross the provides is it basically difficult because you can't actually make api because of one domain call even if it is subdom I actually browsers don't deliver that you can't actually make api but for deluxe it will do api so what we did basically like we kept an iFrame on the packet and then this iFrame source which is in the packet and that iFrame embedded in the web pairs of deluxe so when the basically the deluxe and the web pairs loads it loads this iFrame and the loads clears the data from this server which basically says that document.domain is deluxe api. so that way in that iFrame the document.domain is set to deluxe api.com and what I do is to the magic of same origin policy I use this I create a XML certificate request object in the iFrame and then I share that iFrame XML and use the XML certificate request object of the iFrame not basically install the iFrame template in the web page that is a simpler option make your nginx proxy request to the api nginx you can go you have an nginx reserve static content can I act as a proxy and forward it to api for the server side no no there are multiple concepts one thing is we want to make a session session basically like we want to make a session from front end to back end so what we do in back end we create this XML in this iFrame so we set a session in the front end so the session has to be the same I mean because I allow to use a session to basically to make the epaples I basically set a session for dot deluxe api so you will have to set it over and for this session so we have to that is how in the server side so we made it work through the concepts and I think it will work that is a much simpler solution so all your requests will go to deli.serpent.com slash api and on the back end you forward it to api or deli.serpent.com with the deli tool and a mod proxy to api which you have already used so you don't basically say to the machine policy you don't have to do all this you don't have to do all this you don't have to go to deli.serpent.com another thing is this iV there is only one option because whatever use case there was only option is cross there is cross or jim where you can set it in the back end but the problem is that I mean not all pros are support there the cross or jim where you basically set right that is a different spec another way that you can do this is jim it's basically the idea is any time you set script SRC equal to 6 bar right that can be crossed to me so you basically use that to so only requirement is all your server settings here they have to when the renderer is script they have to render it as a call to a client set function so let's say you are featuring a json so what the server should render is something like callback of your json and you callback to be defined on the client set but does that be a decouple design sorry that will not actually be a decouple design actually just for any line so typically what they do that is they distinguish json calls versus non-json calls we have some corresponding parameters for instance even google maps, facebook they make those calls they provide a very patient-marked json callback then it becomes yeah but see we can take this discussion I am trying because yeah so I mean you can download the realising app for your mobile when we have got fantastic reviews on our applications search for realising apps one minute we have time we can show you one minute we have questions the twitter that is yeah because of the same reason the twitter uses the same approach like many of these they have this API based platform which uses the line app but twitter faces the same problem because their performance is basically varying from different products across different users they want to basically have a similar experience across different users that is why they are going from client side to server side recommend the hybrid model recommend the hybrid model I myself say that I made mistakes in my some of them so I am actually trying to fix it so first it gets extremely and the interactions afterwards is yes I mean what you could do is some part of it where you want basically the c o or whatever the performance where you can show minimal gap of loading there you basically can use json you can use the client side at least till all our users become good till all the users all the users will have to use a hybrid based approach so it is not just logic there are two problems they have it will just download a static content and it has to make one more request to get the data so there is two requests and by the time it is showing a signal there is no data there okay so you have to rate your application in such a way that they degrade gracefully when you don't have javascript so I will interlate a case called dupato we do not have a very javascript heavy application the web page is in a very javascript heavy application but even for search engine and other such activities you always have to make sure that you load some content in your html which the search engine wants to avoid and if a html or your server packet always has to render the same information that of javascript or client side will render so that whichever user is accessing whether with javascript or without javascript they can get the same experience yes they may not have the same user interface but they get the data so you need to work on both the sides but they will be very hard one thing have you had a mistake after when we were talking if there is no question maybe you can take it offline have you ever been looked at? yes I have I have not