Writing a Massive Angular App at Google NG Conf

ng-conf is a two day, single track conference focused on delivering the highest quality training in the Angular JavaScript framework. 500 to 700 Developers from across the country will converge on beautiful Salt Lake City, UT to participate in training sessions by the Google Angular team, and other Angular experts. In addition to the invaluable training, ng-conf will deliver a premier conference experience for attendees, providing opportunities to network with other developers, relax at social events, and engage in some of the unique entertainment opportunities available in Utah.

Discuss the main technical challenges and solutions for large AngularJS applications. Learn about the main code reuse patterns and when to use them, going beyond AngularJS' $resource service for custom server communication, authorization, conditional feature loading, and more.

[JohanSteenkampNZ]

Some very useful concepts - using interceptors, code organization (composition/services), and data transformation.

[StephenChumley]

Wow that was fast. Already posting the videos! Thanks!

[phuyem]

not satisfied. How about lazy-loading and plug-in-able architecture, Large applications require so many modules and most of the time, users only use 10% of the features, why load everything everytime?

[yaboirairai]

re: Code Organisation
I'm struggling to see why services aren't just used in every case. I must be missing something, or maybe when this presentation was given angular services/factories/providers worked very differently to how they do now.

[igorghisi]

IMHO, I would say that this presentiation is more like "Writing Angular App that is not a simple Tutorial", since any mid-sized application must have (1) a way to share features between controllers and (2) wraps REST API in logical objects (see Restangular for that).

Must say the stuff to rip off UI features based on user authorization is very smart, but not related to "Massive Apps"

[stuartbooth]

really don't like the 'helper controller' implementation, you are creating a dependency on them in the 'actual' controller but it's not 'visible' as a dependency as you are instantiating them inside the 'actual' controller..looks a lot like using Angular's DI as a ServiceProvider (something of an anti-pattern as it hides the presence of these dependencies)  .. still some interesting things to think about though

[nickcapito]

Any plans to publish the  "apiProvider" code?

[bradley]

Regarding the first section of this talk about authentication I thought the part about authenticating on the server side was an interesting idea.  But it seems to me that hiding html using the data-keep and data-omit attributes on the client side would be quite vulnerable to attack.  Is this the case or am I missing something?

[KubeckiOfficial]

Wow, that's a great talk, guys! :) You made my morning :)

[julienmeyer]

Very interresting (especially the first talk) but I wonder one thing : if we inject the user profile in the html (previously done by a post login response), how you transfer an api key ? In the html too ?

[willrseitz]

Another comment. I don't think the use of "$controller" is appropriate. You should instead use '$injector.instantiate()". It does the same thing, but it does not confuse object creation with controller creation. Although I admit it is longer to type...

[kafeltz]

I have to come here to say the is impossible to build a massive angular app. I'm being doing my second app, with a lot of controllers. And is horrible. I'm trying to leave this software and begin a brand new mvc-classic style because it works pretty well.

My issues are, horrible to: test, validation on field, to a proper mock, paginations/order by (this rely most on server side of course). Impossible to load file on demand on sane way.

Angular is not ready yet for large project, it can be "good" for some component (calendar?, todo-task? hello-world?)

I regret using it. I should give a try on ember.

[willrseitz]

I was planning on implementing a solution like the one they use for authorization where you embed application context in the index, and redirect to login page when you are logged in, but I ran into the situation of a link into my application. I would want this link to force log in and then go to this link. Since my application is using the hash instead of HTML 5 history fanciness I couldn't do this and was forced to abandon this approach. It made me sad...

[MauricioMdeAlmeida]

The speakers just read their full-text slides out loud. I don't need a video for this, just a link to their slides or a book.

[karanrajpurohit]

he sounded like Leanord from the big bang theory!

[nerdrocklives]

For Authorization, assuming your login page is loaded from your index.html you won't have your user info yet because you don't know what user is going to log in. I love the idea but I don't understand how they are rendering index.html and injecting the active user profile into the page before any user actually logs in. I'm thinking maybe they don't load index.html until after the user logs in? But then that means no angular on your login page.

I think I will implement a similar system using custom attributes and the http intercepter, but I will extend my ApplicationOauthProvider to return the user and role information.

[AdrienBeITube]

Love the way presenters rush through their examples!! ridiculous lol