Desarrollando aplicaciones AngularJS gigantescas

Extracto de la transcripción automática del vídeo realizada por YouTube.

as Mark Jacobs I am the engineering manager for a Google product called double-click campaign manager double click campaign manager is a product out of Google that's focused on giving the world's largest advertising brands and their agencies the ability

to create their display online campaigns using our tool these people can upload their creative artwork for their advertising campaigns and they can set all the metadata that configures where their advertising and shown to whom when and under what circumstances

so I'm not here to talk about advertising I'm here to talk about large applications so double-click campaign manager began we're out of the New York office how many people here know that Google has a New York office good in fact New York office

is the largest development center outside of Mountain View it's huge we knock you PI an entire city block and its really the home for a lot of great products Google Docs and lots of advertising products so the why are we here talking today to you well

me and my team are here because DC M is one of the oldest and largest angle er applications we believe in the world so we began back in November 2010 so we've been using it over three and a half years pretty pretty much since V 0.9 we're going through

lots of teething and growing pains along the way we currently have over 20 JavaScript engineers working on a single product we've got over 71 thousand lines of just actual business code another 133 thousand lines of test code twenty-six thousand lines

of markup 130 controllers approximately directives services it's big and the reason why we're here talking to you today is because once an application gets to a certain size you begin to expose fault lines that you probably don't see in smaller

applications fault lines that have effect velocity reusability software quality and so me and my team are here today to talk to you about some of our experiences as we scale up large applications and talk about some of the solutions we come up with along the

way after the talk me and my team will be out by the Google desk we have some additional swag to hand out to people who ask really great questions we happy to talk to so with that we hand it off to ito thank you mark hello everyone so the first topic we're

going to talk about is authorization and conditional features so let's start with authorization so when you have a smaller application maybe you don't really need authorization but as your application grows larger used to you need to start dividing

your application into sections and decide which users can see what parts of the application we do that by basically returning an active user profile for every authenticated user so the active user profile is going to contain a name permissions language email

address a bunch of things about the user that help us figure out like what the user can or cannot do in our application and we once we have this information we basically to store it somewhere in the application wherever all the other parts of the application

can access it in case the user is not authenticated then obviously we have to redirect into the login page and then once they were authenticated they're gonna go back and we're going to have their profile information so originally when we started the

application we did that by well we did basically did everything on a client we didn't really have anything on a service side we just served static files so our index dot HTML was our main page and the way the load sequence worked is like we loaded the

index dot HTML page and then once the browser got that page it started doing everything that you would expect we would load all the scripts to stylesheets the images parse all the JavaScript which seems maybe like not a big deal but we have like 1.7 megabyte

of JavaScript code takes you know a few hundred you know milliseconds and then bootstrap the angular application and then finally request the active user profile and then at that point if the you know if everything is okay and user is authenticated we just

stored it in the app scope and we loaded a default route if if that wasn't a case and user wasn't authenticated redirecting to the login page and point they had to restart all over again so they had to put their log in and then they would issue a second

request index dot HTML load everything request the active user profile so while it worked with the application was small it wasn't really efficient so the few problems we came up with when we when we dealt with it was that we basically spent time loading

a bunch of resources and bootstrapping the app before we even though the user is authenticated and then you know once we got the active user profile information and we put it on the app scope we we kind of like messed up because like now we basically have

a dependency between our app scope and all the child scopes that are in there in your interviews this makes it very difficult to test so like basically you're running to write a test now you have to create the app scope even though you're testing the

controller within it and the apps book really is more of a shell for the chrome of the application we don't really need to create dependencies between the shell of the application and the actual business logic the third problem was that we couldn't

really pass the active profile around efficiently and we couldn't pass it to services during the contouring the configuration phase and that's because by the time we issued the request for the active user profile the D modules are already like loaded

they're they already configured so we can't really pass in let's say the language information to the let's say we have a help directive that shows health information and we want to say that like the language of the user is Japanese we want

to shorten Japanese so the solution we came up with is basically using server-side rendering only for the index dot HTML page and obviously like you can do server-side rendering in many many ways so you can do it to it I like with node and Jade if you use

it was that for templating where you can use App Engine or you can just reuse those templates so the way we did that is like when the user requests in index dot HTML we inject the active user profile into the page as a simple JSON as a simple Java Script object

and once we load angular the information is already there so at that point we can basically take that information and wrap it in a soon an injectable constant and then send it through you know the entire part of the other parts of the application so the benefits

are well for one we have one less round trip because we don't have to do the get active user profile request the second part is that like we're only you're loading in exile HTML user is authenticated because the checking whether user is authenticated

[ ... ]

Nota: se han omitido las otras 3.428 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.