AngularJS + REST Made Simple: Connecting AngularJS to a Backend with REST & JSON

By | November 19, 2019


BRAD GREEN: Hi I’m Brad Green. I manage the Angular projects–
AngularJS and Angular Dart. And thank you all for
coming, it’s a full house. I know some of you
got on the wait list and we’re happy all of
you could come who came. Tonight we’ve got a
couple announcements, like we always do. Ben from DreamFactory
is going to talk about building
apps on RESTful UIs and making it
easy– RESTful APIs. Misko will come up– Misko is
the creator of Angular– he’s going to come up and talk
about how the change detection, or the thing that we
experience as data binding, how this is implemented. And a few of our thoughts as
we move towards Angular 2.0. And James from the
team is also going to talk about how we’re
doing benchmarking. We’re very focused on
performance in the Angular team, and we’ve
got some new tools that will make it easier for us. And even for you folks to
do your own benchmarking. So some announcements,
it’s been a while. We didn’t do a lot of
announcements last time, so we’ve had a lot of versions
since the last time we talked to you guys. So AngularJS 2.9 through
this 1.3 beta 1 release. If you’re on production,
you should stay on the 1.2. The 1.3 release, we are
stopping testing on IE8. And so this is really a
forward thinking release. We’ll go through a
couple revs before we decide that it’s ready
for ready for use, so 1.2 is the branch for
you until we get that right. We’ve done a lot of things here. We fixed like 162 pull
requests and issues. There’s been a
number of features we’re supporting a bunch
of the new HTML input types now, like date, time, month,
week, all these cool things. We added a bunch of
animation support– and there’s actually a whole
bunch of different animation things in there– but one
of the things we added was form validation states and
be able to trigger animations based on if something as
pristine or valid or invalid. We added hope for DOM
callbacks from the animation. We’re using
RequestAnimationFrame for some better performance,
rather than time outs, And there’s other performance
enhancements in there as well. A lot of cool stuff. On AngularDart we
only had five releases but you can– if
you’ve been tracking us for awhile– our release
speed is picking up. We actually beat
the AngularJS side by– on the number of
PRs closed– by a lot, so Misko and a bunch
of the other folks have been super busy on this. We added a bunch
of the things we’ve been familiar with in AngularJS
like animation and forms. And there’s a new change
detection algorithm that’s super fast and Misko
will talk about that tonight. Other things we added,
this thing called ngRepeat. It also has another
super cool feature that we’ll be bringing onto the
JS side that’s actually only available in Dart
right now, which is– we’ll call it automatic
digest– where if you’re working with something
that’s on a timeout or in a third party library,
you no longer have to call, apply yourself. It happens automatically Couple cool things– not a
lot of big announcements– we got some nice kudos. One thing the stack overflow
folks– actually this is you guys– told
us that Angular was one of the top three
exciting new technologies of 2013, so thank you guys. That was awesome. Another cool thing on
GitHub, we appeared in the top repositories of most
contributors and repositories with most stars, so thank
you guys for that, too. That’s wonderful. Woo, yeah! [APPLAUSE] I’m almost at the end. Last thing, we are out
of presentation ideas. We could come up here
and talk to you guys, but we would actually
rather hear from you folks what’s going on. If you’re interested, here’s
a link to go fill out a form. I will tweet this
out later, so you don’t have to remember
it or write it down. But we’d love to have
some of you guys come up and talk about your experiences. So come chat with me afterwards. If you don’t remember it, I
will tweet and Google+ this link later and we can chat about
what you guys might do. So thanks very much and we’ll
welcome Ben up to talk about– BEN BUSSE: Great. BRAD GREEN: RESTful APIs. BEN BUSSE: Great, thanks Brad. Welcome, everyone. Thanks for coming tonight. Turn this off real quick. So my name’s Ben,
I’m with DreamFactory and tonight we’re going
to be covering I think, what’s hopefully, a pretty
interesting topic for folks. We’re going to be
talking about Angular and how to make it easy to
use Angular with rest APIs. We’ll kind of jump into it. We’re on Livestream, so if
folks want to go to Crowd Sound and there’s an
Angular room there. Just click on it and you
can enter questions in, and we’ll try to get
to as many of those as we can at the end
of the talk tonight. So I’m going to talk
about three key areas. I’m going to talk about
in the first place, provide a little bit of
context, like why REST services? Why are they good, and
what’s happening, broadly speaking, in the
world of applications, particularly as it
relates to mobile. And then I’m going
to give a little bit of a quick storyline
about what we’ve done at DreamFactory with
our open source products, and the challenges that we
face, the reasoning behind it, and why we built
this open source platform that we’re working on. I’m going to talk a little
bit about Angular and REST, generally, as well. Just the built-in
capabilities of Angular and try to point people
to some resources there, because I think
there is probably a diverse group
of folks who have different experiences–
experience levels of– Angular. And then we’re going to go
through the second half– about 20 minutes– walk
through a demo. Very simple
application, but it’s going to showcase a new open
source library that we just released to make it really
easy to consume and use REST services with AngularJS. So quick, a little bit about me. I’m a technology
evangelist at DreamFactory which just means basically I
do a lot of developer outreach, and work closely with
our engineering team. We use Angular a
lot at our company, and we’ll be showing
you that tonight. And then I have experience
as an engineering manager in the mobile space
on the consumer side, and I’ve done a lot
of product management in the enterprise software
as a service realm. And I’ve been working with
REST services for a long time, especially with the
salesfirst.com platform when they started building
that, and have learned a lot of along the way. So a little bit about this
evolution of applications. I won’t spend too
much time in there, but we’re in this interesting
time with apps, right? Web applications with
HTML, generally, click, you get a page back. You’re doing a lot of
this business logic on the server side
and the application itself is coming
through a web browser. And you’ve typically
got traditionally like a relational
database on the back end. So in that kind of world, HTML
kind of contains everything. You’ve got your graphics,
and your layout, and scripting, and
everything in HTML, and that’s coming over the wire,
which works really, really well for the web and
with web browsers. But things have changed. In 2007, you had
iPhone shipped and I would call its mobile area that
we’re in, it all sort of really began to take off. This idea of thick client
applications or single page applications is really
starting to really emerge. Here we’ve got a phone
and all these devices, not just a web browser,
phones, tablets. And you can actually
think about things– that are– it’s
actually probably going to happen real quickly
with sensors, and wearables, and things like this. Where you’re really
using– instead of this big,
monolithic application server– in the
middle, you’re really using REST services,
where that’s a really good way to
architect applications. Especially data
driven applications. And then in the back end,
you’ve got this diversity of sources like, it could be SQL
or NoSQL, or cloud deployments, platform as a service,
probably speaking. So we’re kind of going in
this world HTML to JSON, and this is
particularly relevant if you’re just building
a really simple, static, mobile application. Sure, you don’t need
a back end, and you don’t need to transmit
anything, but if you’re doing something
that’s data driven, you still need to
use all the data resources that are out there. Particularly if you’re working,
say, with a big company and you’re trying to deploy
these mobile applications. You’re not going to just start
a new database in the back end, so you need to access that. And JSON is a really good
mechanism, with REST, to get at that data and
return it to the client. What’s really cool now, is there
is all this rapid innovation on the client happening, so
a lot of these frameworks do some serious heavy lifting
for front end development. And these things are moving
really, really quickly, so I’ve just listed
a bunch here. And they all have pros
and cons and people are pretty opinionated
about which ones are great, and so forth. And there can be a
lot of debate there, but overall, they make
development– developers– a lot more productive. Or at least, people argue about
how productive they make you. But I think it’s
an asset to have all of these different
frameworks available. But what about the server? There’s actually a lot
of innovation going on with REST services. And there’s everything
from API management to really great
standards, like REST API markup language is
coming into play. We’re going to show
off a tool that we use with our application
called Swagger which is really good for basically
generating live API documentation. And so that’s kind of
the scope of the talk. We’re going to talk
broadly about REST services and then we’re going
to dig into the way that we’ve thought about
that particular problem, and show a quick demo to
access all these things on the back end with Angular. So just a quick context, I won’t
spend too much time on this. At DreamFactory, we are
a development company. We make applications. And similar to the Angular
team at Google thinking about the front
end, as an analog, we’ve thought a lot
about the back end. So we’ve done some pretty
heavyweight complex implementations with
enterprise customers, and we’ve rewritten a lot of our
code and done a lot of things over and over. We were kind of
envisioning a world of, wouldn’t it be nice if
we could write less code, if we had a flexible
way to deploy on different infrastructures–
kind of a mobile architecture– use existing data, and
then have a user management system instead of having to
write all of that ourselves. When we thought about this,
we thought about wouldn’t it be great if REST APIs were
provided, or available, and usable for you. It would be great if this
thing was open source and you could install
it, use REST and JSON as the key protocol, and
then connect into SQL, NoSQL file storage. And then remote APIs
is the other key area. And then provide
single sign-on and role access to all of
these things, so you have very granular
control over what services are available
actually to end users is the idea of
your applications. So this thing that we
envisioned didn’t exist. If it did, we gladly
would have used it. And really the
state of the art is kind of building these REST
APIs yourself, by hand. Building your own user
security from scratch, and then building user
management and all the security around that manually, and then
repeating that whole process over and over. So we open sourced
this technology called the DreamFactory
Services Platform. We call it DSP for short. Get some water here. Basically what it is,
it’s a piece of software that you install on a server. We also have hosted
versions of it. And it securely
connects, so it provides a server side connection
to SQL databases– we support a bunch of them. To NoSQL databases,
such as MongoDOB, CouchDB, DynamoDB
as your tables are adding more and more of those. And then file storage, whether
that’s S3 or Rackspace, it could be local or
remote file storage or your own file storage
that’s RESTfully accessible. So it does all this and
then it automatically generates a REST API that
your application can then use, and you can write
to with standards. With open standards. So we provide
libraries for Angular and some of the other HTML5
and JavaScript frameworks, and then also native SDKs, if
you’re doing data development. We generate these APIs,
and then we document them, and then they’re usable
for consumption or use by your application. When you think about
it, you may have APIs already that you want to use. So exposing these APIs, this
is a mechanism to do that. As well as connecting
to things they don’t have APIs, like a
SQL database, for example, that’s not a standard REST API. So this technology is
absolutely free and open source. It’s an Apache license. You can install it on all of
these different platforms. You can install it on
premises, which turned out to be really, really
popular with many companies. All the different flavors
of Linux right now. We’ll support WAMP stack soon. Google Cloud, Platform
VMware, Windows, et cetera. We also have a hosted version
that you can just use for free. That’s the technology
in a nutshell and how it can be deployed. From a developer’s
perspective, you can think of it as a single
interface to develop to. So on the right hand side are
all of these different data sources that may exist anywhere
on premise, in the cloud, on your server, in your
basement, wherever it is. And then the middleware
here, DreamFactory, provides that tier, that
facade, or that API proxy to all of these
sources securely, where generally you have
to store your keys securely on a server, never the client. And then a REST
and JSON interface that’s standardized and open
to get to that information. And then a complete security
framework on top of that. That paradigm is very simple. You develop in
Angular, for example. You make API calls
RESTfully, and then you get JSON back to the client. So the things in
circle– I’m not going to spend a lot of
time on this– but these are the things
ourselves that we had to do in our own
development, which we found lots of developers
facing these challenges, from configuring, and building
and designing your REST APIs. One of the real
challenges for us has been not only
all the integration, but all the testing
that involves. When you have so many different
APIs that you need to use, it’s just really hard
and time consuming to build those and then
test them and manage them. We’re trying to ultimately
reduce or minimize the things that are
in the circles there, and do this with small,
agile front-end teams, primarily was the idea. Bitnami– the way to get
this– Bitnami is a partner. They’re like an app
store, you would call it for open source server software. You can get the installer–
you can install it on Mac OS X, or Ubuntu for example,
or VM like VMware. And they also have
hosting models, so if don’t want to
install anything, Bitnami has a hosted
version of it, as well. And then you can also–
it’s absolutely free– so people can go and try it
out on our website, as well. Now let’s switch to
Angular, the anatomy of Angular applications. We’re not going to go
into too much detail here. One of the– a couple of really
nice things about Angular– is number one, it’s really
modular and testable, for one. And then you have all
these built-in things, like directives, for example. A popular one is
NGRP, for example. And then you can extend
those however you want, so it’s highly extensible. The area that we’re
going to cover broadly is how do you connect to
a server with Angular? And Angular provides this really
handy mechanism, broadly called services, and they come in
a couple different flavors. You can write a factory,
for example or a service. You write that
piece of code once, it could be something as
simple as a user login routine. And then you can inject
it into your controllers and reuse it, which is really,
really great for testing, and keeping your
logic, and your code implemented really cleanly. And these things
are lazy loaded, so they’re great for
asynchronous use cases, when you’re getting something
back from a server but you’re not sure if
it’s going to succeed or not, or when it’s
going to come back. Angular built– provides– all
of these built-in mechanisms. And what’s cool about that is
that you can then extend them, to make it even easier. So you have all these
libraries coming out, like Restangular is a
really good library that makes REST really easy. And then other companies
are doing things, as well, where they’re adding
these libraries and trying to simplify the
development for people. So server calls up
Angular, got HTTP, which is an abstraction of your
basic browser request, and then resource, which is great
for RESTful data models. I mentioned Restangular which
is kind of– what that does is, it’s a service to handle
RESTful resources really, really easily. And you can get that on
GitHub and check it out. All of these work
with– whether you’re using DreamFactory,
or trying that out– or whether you have
some RESTful resource that you just want to write to. These are the key
mechanisms, resource being the one
that’s particularly well suited to RESTful URIs. This library that I’m going to
show in the next few minutes is an open source module. It’s dynamically generated
when your application loads, so it’s a library. You drop it in,
you can install it with Bauer just put
it into your project. What it does is it
integrates your application with all of these services that
you’ve added on the back end. So if you add a service to
go to Dropbox or something, that service is then
available, and you can just write to the API really easily. It’s built on HTTP, so you
don’t need to use $scope.apply, it simplifies that. When you use it, it’s
instantly available. The convention it uses is
dreamfactory.api.service, which is the REST
service.method. So it’s basically like AJAX. Really nice examples of REST
calls, there’s egghead.io. A lot of people probably
know about these. If you’re new to
Angular, definitely check out the videos there. “Ng-newsletter” has a bunch of
great examples of using REST. “AngularJS Magazine” and
there’s a GitHub repo that has just a
whole bunch of links. I’ll post this stuff
up but if you’re just learning, just dive
into this stuff. I think the way
that people really effectively, is by example. We’ll show two examples today–
one that we’ve– this app that you can get. I wrote a tutorial for
people to go through it, because it will be
a little bit fast. Ari Lerner spoke here–
he’s here tonight, actually. He wrote a really good book. I picked it up and dove
into it over a weekend and read the whole thing. It talks about the
fundamentals of Angular, covers scope, really key
concepts, two-way data binding. And the nice thing
is that it gives some examples of services, and
cores, and things like this, which is all about
server interaction, and how do you do that? And these are basically
really hands-on examples, and I think that’s how
people learn the best. It’s not really theoretical,
you just jump into it and it’s very pragmatic. With that I want to
jump into a quick demo. Let’s see. [INAUDIBLE] the server. The application
I’m going to show is deliberately very simple. This is a little– it’s going
to show three things– so it’s a little trivia application. It’s responsive, and you
can get it on GitHub. I want to show three
things– it’s the ability to use an API to register,
to login, and then to call a third party API. So basically, this
little application is going and fetching
some questions. It’s using an API called Rotten
Tomatoes to get these movie questions, which are actually
super hard to answer. And then you can either come
as a guest, or you can log in. You can register
for it, and sign in. And it’s also doing some
very basic database crud, so if you get a
question right– like, I don’t know the answer to
this so I added a cheat button. Here, right? So if you get the question
right, you get points, so it’s basically just
adding to your score. And then if you get it
wrong, you get a deduction. So, really, really
simple mechanic. We’re showing registration,
of creating a user. We’re showing authentication. We’re showing calling
a third party API, and then we’re showing
database crud on the back end, and how it all works. Now we didn’t do
anything on the server, except some very
basic configuration, which is what I want to show. And then I’m going
to show the library, and how we’re then using
the APIs from the SDK. So the way that we set
this up on the back end is actually very, very simple. This is DreamFactory. This is the admin console. We built all of
this with AngularJS. This is where, as a developer
you would install the software, then configure everything
that you need on the back end to connect to all
of the resources that your application needs. The first thing
you do here is just set up an application, which
is basically an API key. So I call it this,
and we’re actually running the application
from a server– running it from my local server– so
it’s accessing this back end, but it’s actually running
on a server on my machine, or wherever. You could be running
it on the internet. The next thing– so behind,
there’s a little table here. You can actually– it comes
with a MySQL database. There’s this little
table called Trivia Score and you can import JSON, or
you can just create a table. Typically what people do is they
connect to another database, so they would have their own
SQL database running somewhere. What’s nice about all this
is the same application is written, but then
you just connect it to whatever back end you
want, and the front end code is the same. So you just call the
API, the service name, and you can connect
to a SQL database, or you can just use
the native one here. The back end is really
quite interchangeable. That’s kind of nice. The services, though–
this is the core of really what I want to show. If you want to
add a service, you need a secure way of doing that. Here, this little service,
I just give it a base URL. So it’s this API, and
then I give it an API key. That’s a secure way of
provisioning this so that end users who are using
your application, the credentials to
that are always hidden. So you just can add
parameters in here, and you can add headers, and
then make those API calls. I’ve got several set up, so it’s
similar to if you’re setting up MongoDB you just put in
your connection string, and then it lights up and
off you go with AppSugar API. Once you set it up, you can
actually go to the API SDK, and you can see all the methods. So this is Swagger running,
and Swagger is just a live API documentation mechanism
that we put in here. Movies here, just takes a
really simple parameter. I’m going to do a get call on
it, and it’s just a string. And then I can
click to try it out. And what that does is
just makes an API call. And it returns
this ugly response, which we then actually have
to clean up on the client. And I’ll talk a little bit
more about that in a moment. So here you’ve got all of these
services set up, and then, for example, the
database CRUD, that’s just happening on DB here. So you can just make
any of these calls, and you can inspect
what’s happening, and just give it a
table name and off you go to get the response back. So that’s how we
set up the back end. We just set up
this quick service, we have a DB service
that’s available, and then we’ve got
a user service which has things like
session management and registration built in. So that’s how it works. And the only other
things that you need to do to set up an
application like this is just config. So we’ve enabled cores
because, if you’re writing a browser
based application and it’s running on a server,
like here I’m running locally, you need to take care
of cross domain issues. So here a star just denotes
that I’m opening that up, or you could white list a
server if you wanted to there. And I’ve enabled guest users and
I’ve enabled open registration. And what this does is
it ties your end users to a particular role. Right? So you have to provide
security around all of these things you’ve set up. You don’t want to just
leave it completely open because otherwise
anybody can just start making API calls,
which is not good. So here in the role
system you just have some basic permissions. It governs what applications
these different users have, like this one only
has access to trivia. And then I’m granting read-only
access to this Rotten Tomatoes API, read and write on the
database trivia score, and then user access to basically–
I should actually make that read-only, so that
you can only do certain things, like create or read a user. And that’s the basic
paradigm for the role system and how that all works. So that’s a broad overview of
the back end configuration. I’ve written all this
up in a quick tutorial. Getting this application up
and running is very, very easy. The only other thing I want
to mention– people often ask how did you get
that movie service? How is that thing configured? And what we’re
working really hard on is using just a
simple JSON mechanism to encode the definition
of a different API. Here basically you add
a get movies method, and this is all
encoded in this JSON, and then you just upload
it to the file system. And so you can arbitrarily
define a rest API that way, and use it. So that’s nice. So that’s an overview of
the back end configuration that we set up there. Now what I want to do is quickly
show a little bit of code here. Can everyone see this? So what we did with
this little project is we dropped in this library,
the DreamFactory library, which has a service, and it uses HTTP. So we’ve injected
HTTP in it, and it takes a URL and an API key. That’s all it takes. Two very simple
constants that you specify in your App.js file. So in App.js I have two
constants at the top. You just specify the URL,
of whatever the DSP is, and then you
specify the API key, which is the
application, so that you know when a user authenticates,
do they have access to that application, and do
they have access to the services that that application is using. So that’s how you do that. I just want to show a couple
different controllers here. Let’s see. Clear this out. So a lot of people ask,
user login and set up can be a challenging
thing with Angular. So here, I’m not going to
show all the controllers, but I just want to show
how you would implement a simple registration
in the convention here. So really if you read
through this code, you’ve got this front end. You’re checking and
verifying a password. Somebody puts a password
in, your checking does that password, does the
string match or not? And then you’re basically
making a very simple call and passing key value
pairs of email and password when you log in. But before you log, in
you need to register. So the way we do that is we
use dreamfactory.api.user, so user is the service name
that you saw back here. So all of these things
here are in the SDK. So all of the methods per
user, for example, you would scroll down
and you can see all of the different
methods that user has. And registers here
so you can see the URL an HTTP is a post
and all that good stuff, it’s all documented. So really what’s
happening here is all that’s happening is
we’re calling that user, or whatever the service would
be called, DB or MongoDB or whatever you named it,
your service, and then the method on that,
which is register. And then we’re just passing
it in the data, which is just the user’s information, their
username and their password. It’s actually very
much just like Ajax. You don’t need to
scope.apply here. Of course you can use resource
to access any of these. These are just RESTful URIs,
so you can also do that. But this library is just trying
to simplify that for you. So that’s the
registration controller. And then login is, as
you expect, very similar. Here you just have some post
data, which is the credentials, and then you just
call api.user.login. And then the log out function
is basically just in the route. If you look down at the
route here in this code, you have when/logout
and then you resolve, and you pass in route
scope and the user service in the DreamFactory,
and then you just call the log out function. So that’s all there is to it. In general for
writing applications, it’s good to deconstruct them
and to separate your services out. So you can have your
services in a separate folder as your controllers, and
then your controllers are just calling those services. So we’ve got five
different services here. A string service,
a user service. I’m going to talk
about two of them. I just want to show how
you use Promises here. One example of that– with
this movie– or sorry, the score keeper
service– let’s see if I can get my
mouse to move here. So this service is
just keeping the score. It’s passing in
DreamFactory and in Q. And we’ve written this little
private function, create record, which is just
creating– so DB remember is the API that we’re
using, and then the method name
is create record. And this is a private function
that’s generic to this service. And then it just
passes in record data. So we’re just going to
invoke it down here, and all we’re doing there is
we’ve got this create score record, and we create
a promise, we provide the record data that’s
then going to get inserted, and then we invoke the create
record function that I showed above, and then we handle the
promise, and then return it. So this library– like Promises
is a really good approach. Avoiding call backs is good. It’s good for
testing and it just makes your code really clean. We’ve built this library
to work well with Promises, but you don’t have to. And if you go to
the readme file, we give some generic examples,
just code examples of how you can use it with
Promises, or if you just want to use regular non
promise return a function error, or a success,
you can do that too. The other thing,
this application, for those who are new to Angular
or haven’t used the testing frameworks, it has
test cases in it. So there’s unit test cases. It comes with Karma. So you can fire up– if
you’ve installed Grunt, you can do grunt test:unit, and
that will kick off some unit tests, and you can actually go
into the code and check that out if you’re not familiar with
Angular’s kind of unit tests mechanisms. And then there’s also some
EDEs end to end testing, basically what this does
is it emulates behavior that an end user might be doing. So what happens if
someone’s registering– and these are done with Karma. So it just fires up Karma, and
goes through these test cases, and there are about 20 in there. So you can definitely try that
out and see how it all works. The other thing I quickly
want to touch on– we do a lot of stuff with mobile. So we’ve built this
mobile application. So if you’re
hosting applications and you installed DSP and
you go to applications and they’re running on
a server in the DSP, we provide a mobile
application which houses those applications–
applications run inside it. So you get the full
security framework. So that’s really
useful if you just want to deploy without
having to use Phonegap or whatever yourself. This is all open
source though, so you can go ahead and use Bower
and Grunt to build it. So you can use this source
code and build an application wherever you want, and then
use it and package it up with Phonegap. The steps to take this
application that we just showed you, and turn it
into a mobile application, it’s relatively easy to do. That’s probably a whole
other topic of discussion, but I just wanted
to point that out, and you can go and
check that out as well. Everything I showed here
today is in a tutorial that I just posted yesterday,
which walks through, it’s on our blog,
it walks through how to set all this stuff up. You can go look at
the code and see how it works –do
one more thing. I mentioned the blog. The other thing, there’s
a basic resource tutorial, so if you want to see
a very basic– it’s a very trivial CRUD
application, like a to-do list example of using a resource,
just generically with a rest API, we have some
examples of that on our website, which is
also worth checking out. We’re coming up with a
bunch of new features, so server-side events
and JavaScript scripting. So that example I showed
with the API response coming back from
Rotten Tomatoes, there is a function
in this application to clean that code up because
it can’t be rendered in JSON, it needs to be cleaned up. Those are the types of things
that server-side scripting take care of, so you can
make a rest API call, and then transform something,
and then return a response. So you can think of
things like validation, based on some specific
condition of a user, don’t insert a record,
or do insert a record. That’s a very simple example. So we’re coming out with
that in a few weeks. RAML support. Record level CRUD security. So this is the
idea of the ability to specify an arbitrary
filter on things like a use case would be
never let a user do anything with records that that user
has not created himself. Things like that, which
will apply to SQL initially, and then we’re going to
do it with no SQL as well. And then we’re going
to a lot of work with enterprise integration,
like LDAP and Active Directory. Things like that. And then provide a
VM for multi-tenants. So the idea there is you can
spawn as many DSPs as you want. So a bunch of resources. Tutorial. The app cod is on GitHub. The library is all open source,
that’s on GitHub as well. The Cordova mobile
app I mentioned. We have a bunch of
developer resources, and we’re working with a
company called Cloud Academy. So they provide really
good learning resources for different platform as a
service and things like that, as well as what we’re doing. So that’s it. I think we’re at
about 40 minutes. Thank you. BRAD GREEN: We’ll do
questions at the end. BEN BUSSE: OK, thank you. –hop off here. BRAD GREEN: Good. Good. OK we’re going to welcome
James DeBoer from the Angular team to come up and talk about how we do benchmarking with the tools he has developed and where we’re going with the techniques. JAMES DEBOER: We’ve
been iterating on these ideas on the best ways
to write and run benchmarks. And so possibly by next week,
what I’m going to present will be out of date and we’ll
have something even better. But these are three things
that we’ve figured out. The first one is that benchmarks
should be real applications. Everybody can think of some
pathological test cases that you can bring a web
browser to its knees, but those aren’t
very exciting when we’re trying to help real users. And also help browser
developers build better browsers so that everybody has
a better experience. Which brings me
to the next point, it’s that benchmarks
should run everywhere. And so we’re now
developing web apps, and not only for
desktop browsers, but also for
phones and tablets. Being able to run your
benchmarks on those devices is really important,
not only because they have different performance
characteristics that your phone will behave
much differently than your Mac would, but also being able
to pull your phone out of your pocket and see
your benchmarking running is incredibly powerful. The last point. Benchmarks should
be long running. This is a little contentious,
and it took us a while to get to this idea. Because on the
Angular team, we’re really excited
about unit testing, and we want our unit tests
to be a very succinct and run incredibly quickly. So we were thinking hey,
maybe our benchmarks should be the same, that we can
just run through them. But it turns out that if you
want a real benchmark that emulates a real application,
it should run for a long time. Because if you think
about your web app, very few users will
open up a browser, go to your application,
click a button 1,000 times, and then close it. That doesn’t happen. Instead they’re spending all
day working on your application. So let’s look at a benchmark. So it’s a little small, but
this is a to-do application. You can see, what we’ve
done is we’ve instrumented it to run through a
sequence of actions. I am hoping that
these are actions that users would actually take. So you’re adding 20
items to a to-do list and then checking them
off, and then you’ll mark all of them as done. This benchmark is
running in a loop which allows us to use the developer
tools to profile it and figure out what’s going on. I have another version
that runs a single loop that you can run inside
of a benchmark harness, so you can hook it up
to a continuous build. But this is something
that you can actually dig in to and understand. So if we look at
the code here, this is a typical
Angular application. You can see we have an NG
click that does something. And there we see
todo.markalldone. And then further down
we have a little form that has an input hooked up to
NG model and another button. And this is important
because when we create the benchmark,
what we’re doing is we’re just executing
a sequence of Angular expressions. So we’re using two things. The first is request
animation frame. And that let’s us execute a
single expression per frame. Which means that you’ll
see the JavaScript, as well as all of the
rendering, together. And then the second
thing we’re using is Angular’s
scope.dollarapply where you can just pass an
arbitrary expression and Angular will run it
and update the model. And so you can see
that back here, that we have this request
animation frame loop. And then we can use
the developer tools to capture frames. And so because we’re
using animation frames, there are tools that say well,
let’s bunch all of the work together in a frame. And so this is the Chrome
developer tools frame view. And so here you can see that
each of the frames– so each of the Angular expressions
took some time. And you can quickly
identify hey, there’s a long
Angular expression. So this one took 23 milliseconds
to run the JavaScript, and then render all of the– any
DOM updates that it had to do. And we’re able to
use these existing tools to drill into it. And so here we can see
that this was todo.add, which is equivalent to
clicking the Add button on that to-do app. And we can also see
hey, it took a long time because there was a garbage
collection event that triggered during our code
to process that to-do add. And so this actually
highlights one of the things that Angular is doing. That we use efficient
data structures, that we avoid creating garbage
while we’re running your app to try to minimize the number
of garbage collection events that your application has to do. The other thing we can do,
and this is a really important point, is that you can
run JavaScript profiles. And you can do this
because the benchmark is running for a very long time. So you can collect as
many samples as you need. Where if you had
a benchmark that tries to run as
fast as possible, there may not be
enough time to collect samples to get a
meaningful profile. And so you can dig into
this and understand why your application is slow. The final thing you can do is
you can run this on your phone, and actually use Chrome’s
USB debugging to see the benchmark running
on that device. And I will do that now. This is actually built into
the latest releases of Chrome now, that if you go
to chrome.inspect, you can see your Android
device when it’s plugged in. If we go back to timeline and do
the same thing we did before– So here we’re getting frames
coming from the phone. And you can look at each of them
and see, well, first of all, they’re much slower than
they were on the desktop. On the desktop, most
frames are completing in less than 10 milliseconds. And here, we have 48 and
100 and 40 milliseconds. And then you can also
see that painting takes a significant
amount of time. So next steps, this is still
our current best thinking. So we’re not there yet. One of the biggest things
we’re struggling with is how do we actually get
the data off of the browser. And we want to be able to do
this in a cross-platform way, that we don’t want to be
tied to a single browser. And so even getting frames
per second information out of your browser through
JavaScript is very difficult. And so we’re still
working on this. And right now, we’re exploring
browser-specific ways to actually measure
the time from when you start your
JavaScript to the time that your pixels are rendered. So that’s all for me. I think, next, we have Misko. [APPLAUSE] MISKO HEVERY: Which
one’s the magic needle? JAMES DEBOER: Yeah. Plug this in. Yeah. MISKO HEVERY: How
are you guys doing? Really. How you guys doing? AUDIENCE: All right. AUDIENCE: Woo. MISKO HEVERY: Maybe
try it a third time. It’s not projecting, is it? Yes, it is projecting. OK. So I want to show you how
change detection works. So change detection is
basically the magic thing we have that figures
out if anything has changed in the model. And we do this through
something called dirty checking. And dirty checking allows
us to basically figure out if an object has changed. And most other
frameworks do this by forcing you to implement
some kind of interface and use special getters
and setter methods. And I think one of of the
things that differentiates Angular is the fact there’s
no special objects for model access. So how does this work? Well, in its simplest
form, dirty checking is simply a comparison such as
this where you’re saying, look at some value and compare
it to a previous value. So here is, maybe, a
better example right here. So you have a
object, for example. And you say, does object
have a particular property? And you compare it to the
previous value of the property. And one of the things
we would like to know is how fast can such
dirty checking be. So what I’ve created
here is what I just call and item, which is
essentially our way we keep track of things. And the item keeps things, like
the object I’m interested in, the field on the object
I’m interested in, what was the last
value, and what the next item in
that link list is. And what I do is I create
a list of 1,000 items. And I give it a random value. And I link it together. And I want to know just
how fast I can iterate over these items, right? So this is the first
question I might have. So if you run this thing–
this is my machine, it’s about two years old, so
it’s not the top of the line– but you will get a number
that might surprise you. And that is basically that the
VM– this is not just Chrome, but really all modern VMs– can
iterative a pretty impressive clip, about 221,000 iterations. The way this is
structured, because we’re iterating over a list of
1,000, it automatically divides to milliseconds. This is how many dereferences
you can do in one millisecond. That’s a pretty big
number, in my opinion. But this function doesn’t
really do anything. It just goes. And it goes to the
next and next item. So let’s make our first
naive implementation of this thing, which
would be this one. So let’s go, and
we can edit this. And let’s add. So here, what we’re
doing is we’re actually doing comparisons. If you compare to this previous
line, what we have done is we added a
comparison saying, OK, how many field references,
how many properties can we dereference in JavaScript. So let’s save this
and run our test. And I’m going to take a guess. How many people do
you think– what will the number be for the
number actually shows up? 20,000? Oh, you saw it on the
slide, didn’t you? [LAUGHTER] No. It’s actually a pretty high
number, if you look at it. And so if you look
at this thing, do you think this test is OK? Or do you think
that, the way VMs work, actually, we got tricked? Is this a real test, or not? No. We actually got
tricked by the VM, because you need to know
a little bit about how VMs optimize JavaScript code. And the thing you need to know
is this piece of code here. So when a VM– let’s see
if I can make this larger– when a VM sees a field
reference, such as here, like when you see
cursor.next, it needs to know where
exactly the next field is stored in the object. And because, JavaScript,
there is no classes, no types, it is not possible to know
this information ahead of time. And so what happens
is, if a piece of code gets executed over and
over and over again, VM does a little trick
which says, look, I’ve seen this class before. There’s this thing
called HiddenClasses. Are you familiar with this? Like you might have
heard about this. So there’s this HiddenClasses. And so it says something
along the lines of, like, if it’s a HiddenClass
I have seen before, then hard code the offset. I know that, for
this HiddenClass, the fieldA is actually
located seven bytes off from the address of the object. And I can do a fast
field dereference. Whereas, if it’s a different
object that I’m not aware of, I have to actually look up the
offset before I can read it. And this is called a slow path. And so, if it turns out that,
if you look at our code, this is a fast path, because
the object is well-defined over here. And it’s always the same
item we’re iterating over. But we’re cheating over
here, because we’re always dereferencing the
same exact field. And so this actually gets
optimized to a fast path. But it’s not actually what
happens in real browsers, so let’s make a better test. So a better test would be–
well, instead of– let’s see. Here we go. Instead of always dereferencing
the same exact field, we’re going to actually
dereference a different field each time. But we’re going to have to
change our code slightly. So we are going to
actually create a field. We had a random function that
randomly generates a name. And then we’re going
to randomly assign that field into an object. And then we are going
to read it over here. And let’s give this a try. And you will see that
the slow path is actually significantly slower. So let’s give it a
few– any guesses as to how much
slower it might be? [LAUGHTER] AUDIENCE: 10%? MISKO HEVERY: It’s actually
pretty slow at 8,000. So where is our 20,000
number coming from? Well, we’ll get
to it in a second. So what happened was
the way the VMs work– and this is basically how all
modern JavaScript VMs work– and this is one of the biggest
speedup in VM execution was this idea of HiddenClasses and
being able to short circuit field lookups–
is at this point, this piece of code here is
forced to go through a slow lookup, because every time
the VM encounters this object that’s a different type and
it cannot optimize it away. But it turns out that we can
do a trick to help the VM. So let’s do this
particular trick. Any idea what this
trick might be? So I’m going to show
you what the trick is. And then I’m going to
explain what the trick does. So first, we’re going to
create a getter function. And the getter function
simply will take the object, and we will generate a
piece of code, right? This is as if you manually
wrote a function, 0, dot, whatever the field
name happens to be. And then we are going
to copy this here. And we’re going to change
this to say getter. [INAUDIBLE] cut and
pasted this correctly. Might be a mistake,
because I didn’t copy it. And you want to
make your guess now? [LAUGHTER] So we went from– I think
the number was something around 60 was the fast
path, down to about 8,000 being the slow path. And let’s see what the
final number is going to be. Again, your mileage might vary. You might have a different
computer, faster or slower. But the number is going
to be, hopefully, 20,000. There we go, 23,000. So why is this
particular thing faster? Anybody wants to take a guess? Say again? AUDIENCE: [INAUDIBLE]. MISKO HEVERY:
Something’s getting cached inside of the getter. Right. So let’s go back to this
original thing, which was that we have our here. Oops. And so let’s look at
this piece of code again. What the VM can do is, if it
has an actual piece of code, is it can say, if I have
seen this class before, I can create this
special fast lookup. And the reason why this works
here is because we have, essentially, created a new
piece of code, new function for each different
type of object. And because we created
a new function, the VM was able to say, all
right, for this piece of code, I’ve noticed that
the object is always of type whatever the HiddenClass
for that particular type is. And therefore, I can compute the
offset in memory for this field and always have the
same exact field. So in this strange way,
by writing more code, you can actually execute
your code faster. So shorter code doesn’t
necessarily mean faster code. Anyways, the end result is that
you can get about 20,000 field dereferences per millisecond. Now if you have a
binding such as a.b.c, that would count for
three dereferences. But we have also the new version
of the dirty checking, which is now called Watchtower, which
will be available in Angular 2.0, can do coalescing. So if you say a.b.c and
a.b.d, the change detection will notice that the
a.b part is the same, and it will only
watch that once. And it will only watch the b
and d property on the last part. Now let’s talk about
the future of change detection a little bit. We are thinking about– so this
is actually already implemented in angular.dart
and, as I said, is being ported to
the JavaScript side using a library
called watchtower.js. And the way that it works is
that, at the lowest level, we have this dirty
checking change detection, which I
have just shown you. This is essentially that loop. That type loop that I
have shown you over here is essentially what this
piece of code looks like. It can dereference fields
in a very efficient manner. And it produces the
change information. Now the reason why this
is limited to just fields is because we wanted to be able
to replace this in the future with Object.observe. So there, we have an interface,
that well-defined interface called ChangeDetection,
to which we can plug in different
implementations. Right now, we have
this thing called DirtyCheckingChangeDetection. But in the future,
Object.observe can be plugged in here. Now just as we can plug
in and check the fields, in the same exact manner,
instead of calling the fields, you can actually call
functions on those objects. And so you can get dirty
checking of functions. And we think that’s
important because, in Angular expressions, not only can
you data bind to fields, but you also have
functions in there. And so these
functions have to be executed over and over again. And so this layered
approach allows us to use DirtyChecking
when possible, or rather use
Object.observe, if it becomes available in the future, or
use DirtyChecking for now, but also be able to interleave
this with function invocations. And so the end result is that
we should be having a faster DirtyChecking in the future
with all of the expressiveness we currently have with the
functions and expressions. I think that’s all I have. [APPLAUSE] Brad, shall we take questions? What is the plan? BRAD GREEN: Yeah. Sorry. Questions and comments? PRESENTER: I can run the mic. AUDIENCE: Hello. A question from me. So this is a little
bit of old news. But in 1.2, the router
module was separated. And I’m wondering what is
the future for routing? Are you going to
encourage people to use the UI router project. Or is something new in store
for the built-in Angular router? MISKO HEVERY:
Brian will take it. BRAD GREEN: Brian, would you
like to answer that question? BRIAN FORD: I really
would, actually. So sorry. The question was what’s
the future of routing? So that’s actually
my job in Angular 2.0 is to figure out the
answer to that question. So for Angular 1.0, I think,
you have a couple of options. UI router is pretty
good for now. I’ve been talking with those
guys about some of their ideas for the router in Angular 2.0. But the big thing
that I’m focused on is a better story
for nested routes, so having nested views
in there, or having, maybe, two things
that are parallel. There are some things with,
like, mobile navigation, for instance, where you might
want to swipe, use in and out. I’m considering
these sort of things. But we’re still kind
of early in this phase. The good news is that
all of the design docs for this are online. And so I’ll Tweet it out again. And anyone that’s interested
can take a look at it. You can let us know
what your troubles are. My focus is really
on implementing this in [? ES ?] 6.0, using
the new tools for Angular 2.0. But the overall
ideas could easily be back-ported to Angular 1.0. So that’s about where we are. But yeah, we know that this
is a huge area of concern and somewhere where
we’re still kind of falling short of
what people want. Does that answer your question? Or any follow-ups? AUDIENCE: [INAUDIBLE]. BRIAN FORD: All right. IGOR MINAR: I’m just going
to add that, in the doc, we are collecting use cases. So if you have any specific
corner case or special case that we might not have thought
of, please go to the doc and add a comment there. This is very useful for us. BRAD GREEN: Yep. [WHISPERS]
Thank you, Brian. AUDIENCE: Hi. Is there a best
practice to which DOM element changes
with Angular. MISKO HEVERY: DOM element
changes– can you tell me more? AUDIENCE: For them from changes
on the size, dimensions of DOM element. Is there a way– MISKO HEVERY: If you want
to watch the size of it? Like if the DOM element changes? AUDIENCE: For example. MISKO HEVERY: Do we
have somebody who knows? AUDIENCE: Because,
for example, I tried using “watch”
in a function where I am going to return
an object with the sizes. The only problem
is that the “watch” is called just once, for
example, for a change. But the function to check the
changes is called– [LAUGHS] [INTERPOSING VOICES] MISKO HEVERY: And
reading DOM is very slow. AUDIENCE: Yeah, exactly. MISKO HEVERY: And
reading DOM also causes a re-flow on a DOM, which is
even another problem, which you should probably not want to
do because, if you read a DOM and then write to a DOM
and then read a DOM again, you’re causing all
kinds of bad things to happen under the hood. Is there some events
that you could listen to? AUDIENCE: Yeah. In my case, I was writing
on another element. It was not that problem. But the problem was the reading
that was called many times. And is there another– MISKO HEVERY: Off the top of
my head, I don’t know of any. Does anybody know? IGOR MINAR: Yeah. I can answer that. So in general, you
either want to use CSS to respond to any
kind of these changes. You don’t want to
do it yourself. If you really want to
watch changes in the DOM, there is a DOM
mutation events, which are supported in many browsers. But they perform really poorly. And there is a new thing called
DOM mutation observers, which performs much better, and can
give you most of what you want. However, this is a
fairly new thing. And it’s not supported
in all the browsers. So there isn’t
really a good answer. There will be a better
answer in the future. But in general, trying to use
the watch mechanism in Angular for this kind of stuff will push
you into performance problems really quickly. So use CSS, if you can. That’s the best option
you have right now. AUDIENCE: I had
a question to Ben on the [INAUDIBLE]
example which he gave. I did put it in
the board as well. How was that session
handled in that application? I saw there is a REST API
for a user get session. I see that that is what is
in a handling session is a pure RESTful, stateful rest? Or is there any
context involved? BEN BUSSE: I’ll try to
answer your question. I’m not sure quite
sure at the end. But basically, you get
a session token back. So it’s like it’s
not using cookies, although, with DreamFactory,
you can use cookies if you want. So you get a session token
back from the server. And that resides
for your session. AUDIENCE: OK, and
that is what you will use in all the
communications [INAUDIBLE]? BEN BUSSE: Yeah. Mm-hm. AUDIENCE: OK. So I assume that I need,
for accessing [INAUDIBLE], I need [INAUDIBLE]. So will I be calling
it every time? For example, I would prefer not
to get this data every time. So is there any way? Or is it like I have to
get the data– for example, use the data for accessing
some other REST service, I need to pass some
context information. BEN BUSSE: Yep. AUDIENCE: So how do we do it? Is it like I have to
get the user every time before calling the next service? BEN BUSSE: Well,
generally, yeah. So a couple of things. So the token mechanism–
I mean, so the REST APIs, when you say other REST API– AUDIENCE: For example, to get
to our request on new REST service, token might
not be necessary. And it’s sufficient for me. BEN BUSSE: Yes. AUDIENCE: I need to pass
some additional context. So how do I get it? BEN BUSSE: Yeah. So one thing– let
me try to answer. The JSON file that
I showed, there’s the notion of public
and private, right? So you can to make
a REST API call. And then that service could then
call another service securely, for example, so you can
chain things together. That’s one use case. But generally, it’s the same way
that session tokens typically work with Angular. AUDIENCE: OK. What one use case
would be, assume that I am trying to get the
address of the particular user. Now, along with session
token, I believe I need to pass some
ID or some CD name. So this is typically a
user data, which typically, in a number of applications,
we store it in a session. BEN BUSSE: Yep. AUDIENCE: And so this,
where do you keep it? Is it fetched again? BEN BUSSE: I mean,
it’s a session token, so I don’t quite
know what you mean by adding additional data to it. AUDIENCE: OK. [INAUDIBLE] BRIAN FORD: You guys can
have that conversation– BEN BUSSE: Yeah. Maybe we can take it offline. AUDIENCE: Oh, sure. OK. BEN BUSSE: Yeah. Yeah. AUDIENCE: Sorry. AUDIENCE: This way. The other side. So a question about
Dream Factory. So what is the difference
between the online host, DreamFactory versus on-premise? Do you get all the web
interface configurations? BEN BUSSE: Yeah. Yeah. It’s the same software. So basically, the idea
is that the hosting is just– the hosting
is way to try it. So that’s all free. But the actual binaries,
the software itself, is identical, right? So you can install it on a
bunch of different places, including on Ubuntu or CentOS. Yeah, different flavors of
Linux, we support all of those. AUDIENCE: So you are describing
that JSON on a local file? So for the cloud version,
how do you edit that? I mean, the file. BEN BUSSE: So there’s
a file system. It’s a LAMP stack, so
there’s a file system in the software itself. And that would be
local file storage. And then you can either connect
to that local file storage RESTfully, or you can
connect out to other data sources, such as S3, for
example, which could either physically– that
would be a remote call. S3s running somewhere
in the cloud. So the idea is that
it’s loosely coupled. You have all of these
different data sources and it’s a unified
pallet of services that you’re using to
access all of those things. And the software itself
physically resides in a server, on either a Linux box
or AWS, Google Cloud. VMware works very well as well. You could even run it
locally on your machine. So you can spin up a LAMP
Stack on your machine and talk locally for development
and for trying things out. AUDIENCE: Do you have any plans
for app caching using Angular? For example, I think
that goes to the point where we can have a
request and, for example, let’s say the likelihood
for these data to change a week
from now is low. Have you thought
on using Angular to build a service or something
that will cash this data using nxDB or, if data is very
small, using local storage or something like that? BEN BUSSE: That’s
a great question. To be honest, we haven’t looked
too closely at Angular 2.0 yet, but we’re going to have a look. In general, our
philosophy is that we’re trying to address the
server-side piece, and so we leave those
decisions to developers in terms of the way that they
implement their applications. So I think, with
respect to local storage there, that’s not
really our realm. But if there are things on the
server that would enhance that, we need to look at it. But if there are
mechanisms by which we could optimize experience
in the client, whatever that means, sure. We would consider that. It’s really driven by what
users or art developers want. Try to listen to feedback AUDIENCE: What is the size
of the client-side JavaScript library that DreamFactory has? And is there a benefit
of using it connecting to existing RESTful
API, which is not implemented based
on the DreamFactory? BEN BUSSE: It’s pretty small. I don’t know exactly how
big– 50 KB or something, it’s little– I can’t remember
exactly, but it’s lightweight. You’re talking about the SDK,
the Angular-Dash Dream Factory? The library? AUDIENCE: Yeah, just
the JavaScript library, and what’s the
benefit– comparing just with the pure
restangular, for example, is there any benefit
of using it if you connect to existing RESTful API? BEN BUSSE: Yes, the
benefit is the key takeaway of what we’re trying to convey. The use of SDK is to consume
these services that you define. So say you had 100 APIs that you
needed applications to access. You would define
those APIs, and they would live on a server in a DSP. And then the SDK knows
about those 100 APIs. So you can write
your application and call any of those APIs. And then the roll system
governs the permissions around those APIs. So in other words,
if I’m an end user, I’m only granted
certain permissions. In an enterprise
contest especially, there’s a lot of
applications and you want to manage them all, because
users have different rates. AUDIENCE: I understand. But the server-side is
already implemented. So without the
DreamFactory server side, is there any benefit
from the DreamFactory client-side library? BEN BUSSE: The benefit is trying
to simplify the amount of code that you write, and
using simple convention. That’s all. It’s just attempting
to make it easier. And I was trying to
show there that you can use this built-in library
as well, because it’s just a standard REST URI. AUDIENCE: So what server
languages and frameworks did you use for DreamFactory? BEN BUSSE: On the front
end, we use Angular. We started about a year ago. On the back end, it’s actually
been a pretty interesting set of decisions. In [INAUDIBLE] we’re
using PHP and Laravel– or we’re going to
switch to Laravel, we’re using Yii right now. The decision for that
has been interesting. The drivers are actually–
PHPs are very mature. It’s well understood,
especially by large enterprises. The libraries actually existed
for us to do a lot of the work that we needed to do. And that was the core
decision we made there. But from an innovation
perspective, there’s a lot going
on, especially with technologies like the
OGS and things like that. So what we’re
trying to do is have our large– think of Fortune
1000 types of companies– drive a lot of the
technology decisions we make. And to the extent that those
technologies– even Java is a huge one– are needed
by enterprise customers, then we will consider that. But the main thing has
been PHP, Laravel– or Yii, sorry– in the back end, doing
all of the API translation. Or creation, provision,
whatever you want to call it. AUDIENCE: This is a
question for Ben as well. Do you have a personal
preference, restangular or HTTP or resource? BEN BUSSE: What was
the first one you said? AUDIENCE: HTTP,
restangular, or resource? BEN BUSSE: I think restangular
simplifies things a lot, so it’s just convenient. And it’s open source. So all of these
things are a decision. As long as it’s
easy for you and you think it’s something that’s
going to be around, it’s fine. I think for RESTful
interaction, resource is good, and restangular is good too. It just depends
on what you like. AUDIENCE: Going back to
that local storage question. You said DreamFactory does
not implement anything on the client-side
for local storage. But is there any
Angular modules that do any local storage
utilization or utilities that we could possibly use
rather than do it natively? JEFF CROSS: I’m not sure
what there is for Angular 1.0 for this. For Angular 2.0, we’re
focusing a lot more on offline and
client-side storage. And later on, even
more utilities to make the client-side caching
of data sets for offline use later easier. But I’m not sure what there
is right now for Angular 1.0. There’s a Design Doc, though. I think Brad tweeted the design
doc’s link a couple weeks or a week ago. There’s a data
persistence design doc that covers this
in a lot of detail. AUDIENCE: There are several. JEFF CROSS: There are
several but data persistence is the best one, so
just look for that one. AUDIENCE: I have
a quick question about performance benchmarking. So what approach would you take
for something– for example, like Gmail– which
is very complicated. It’s pulling from a bunch of
different resources, servers, and you may want to run
it for, say, six hours, just to see what the behaviors
are like after a long time. What would you recommend
for something like that? JAMES DEBOER: We do
some of this internally with much larger applications
than the to-do app that I showed. I think the first
step is isolating the client and the server. So being able to build your
application without needing to go back to the server. There, we will do a record and
playback of any HTTP requests you make. And then after
you have that, you can run your application
on your local workstation or on a continuous
build somewhere, writing a lot of test cases. And at Google, we have a very
robust production monitoring system. So we can see there’s a certain
view that users are having a really hard time with, that
is taking a long time to load. So then we may go back and write
a benchmark that just targets that view and add
it to the suite. IGOR MINAR: Also, you mentioned
that some of those tests are long-running, like
six hours or whatever, because when you want to
see how the application is going to behave. I think it’s important to
realize that you can cheat, and you should cheat
whenever you can. The important thing here is that
the application cannot do much unless there’s some input. And inputs come
in various forms, whether it’s a set interval,
or timeout, or XHR coming back, or user input. And if you just realize that
all these inputs are here, you can fast-forward the time
between when there’s nothing happening. So you can just
skip all of that. Then you can schedule events to
happen in unusually rapid pace. But it’s still going to be
very much like a production application running
for six hours. But it’s going to just
take five minutes to run. AUDIENCE: Quick question. The older version
of the Angular Docs had comments at the
bottom which I actually found very useful, because we
have different use cases– you have other people
comment on how to go about that or
additional questions. And I noticed that’s lacking
in the newer documentation. Any plans to bring that back? Or what are the
plans around there? IGOR MINAR: I wasn’t
listening, sorry. AUDIENCE: Comments in the docs. [INAUDIBLE] JAMES DEBOER: That was me. OK. So you’re talking about
the discuss comments. I also wasn’t paying
that close of attention. [INAUDIBLE] Oh,
could they come back? Let’s see, what’s the
nice way to say this? The answer is no,
they’re not coming back. But– and this is
a good but– we want it to be easier for you to
contribute directly the docs. So there’s not
some stuff up here that’s written by
this crazy guy, and then there’s
a bunch of stuff below that contradicts it. And it’s really complicated
to figure out what’s right, and which part is out-of-date,
and this sort of thing. So our hope is that we’re
going to make it easier to contribute
directly to the docs, so there’s a single
obvious source of good information
about Angular. So that was the
motivation behind it. It’s not like we hate
having comments on the docs. So, where should you
go for questions? That’s a good question. We have an IRC channel
that’s really active. Stack Overflow is really good. I personally like Stack
Overflow because the information on there tends to get
updated pretty regularly. There are a bunch of people
in the Angular community that go through these
issues and update them. It’s kind of like a
larger, crowd-sourced wiki outside of Angular. And it covers things
like different use cases better than we could
concisely do in our own docs. So Stack Overflow is
really good, I think. AUDIENCE: I have a question. What are the main
differences of using Angular with Dart
instead of JavaScript, and the benefits of that? MIKSA HEVEREY: I
guess the question is, what are the differences
between Angular, Dart– JEFF CROSS: Miksa,
if I could interrupt, the bus is going to leave in
seven minutes for the Caltrain station at 8:15. So if anyone needs to catch
that, I would head out now. MIKSA HEVEREY: I don’t
think anybody’s leaving. Everyone wants to hear
what Dart– [LAUGHTER] The difference is
basically, we wanted to make sure that you had
the choice of a language. You want to be, to a large
degree, language agnostic. So with JavaScript, because so
many languages transfile down to JavaScript, you’re actually
compatible with CoffeeScript and [INAUDIBLE] script,
or whatever other feature language. I think people
even manage to get Closure working with AngularJS. With Dart, the things are
a little more complicated, because Dart– the code is
not semantically equivalent to JavaScript, and so the
translated code cannot interact with AgnularJS. And that was the motivation
for creating Angular for Dart. So that if you wanted to
choose a different language, you certainly can. But you still have
the same paradigm. Now, given the fact
that we’re going to have to rewrite
Angular on top of Dart, instead of copying
everything as is, we tried to fix
many of the mistakes that we have learned
from ourselves from the previous version. And so you can think of
AngularDart as AngularJS++. And many of the ideas that
are going into AngularDart are now being
either backboarded, or are just directly going
into AngularJS version 2.0. So things like the
new compiler, syntax, the change detection
we talked about, the new syntax for
directives, the simplification of compile and link function. There’s a long
list of things that are going to happen in
2.0 because of the things we have learned in AngularDart. Does that answer your question? You need to get a
microphone so that it’s recorded for prosperity. Or I can repeat it. AUDIENCE: Will we have backwards
compatibility of 2.0 with 1.3? MIKSA HEVEREY: Will there
be backwards compatibility? I think if you really want
to do innovative stuff, it’s better if you just
think out of the box. And while we don’t
intentionally want to break you, I don’t think it’s
going to be compatible. So the ideas will be the same. And you can probably have
large pieces of code cut and pasted over. But it’s not going to be
one to one compatible. There’s just too many changes
that are done for the better to make it backwards compatible. It’s just not possible. You can have one or the other. AUDIENCE: In Angular
2.0, will you be able to prerender
the server-side? Maybe with not JS? MIKSA HEVEREY: Igor. IGOR MINAR: Why do I
get the hard questions? [LAUGHTER] The
simple answer is no. The reason for that
is we think that we can do better on
the client-side. And our goal is to focus on
making client-side much faster. MIKSA HEVEREY: I think you
should back up and really break it into two different reasons
why people want to do this. [LAUGHTER] Would you
like me to answer that? IGOR MINAR: The reason for
server-side prerendering– there are two reasons why
people want to do that. One is SEO. The other one is performance. SCO crawlers have to
understand JavaScript. There is no way around it. And I truly believe
this will happen soon. So we are not going to
have this discussion. for much longer. For performance, I think
there are many things that we can do much
better on the client-side, especially for leverage
things like SPDY or HTTP 2, HTTP Push, and
many other technologies that are already in
the browser today. If we do that, the
need for server side prerendering– there is
very little benefit to it, and there is a lot of
complexity involved. We built a version
of Angular that had server-side prerendering. We didn’t like it. And it would take a lot of
time to make it into something that we would like, instead
of focusing our energy on doing this, which
we think is still going to have so many downsides. We’d rather make the client-side
much faster and focus on that. AUDIENCE: [INAUDIBLE] IGOR MINAR: Template
prerendering? MIKSA HEVEREY: You
mean the thing with PS? IGOR MINAR: There
are some improvements in Angular 2.0 that we’re
doing that will make it possible to
precompile templates. Which means that there’s
going to be less work needed on the client side
during bootstrap. And that will speed up
the client side further. Is that what you meant, Brad? AUDIENCE: [INAUDIBLE] IGOR MINAR: Yeah. So we are thinking
with Angular 2.0– we’re thinking of
ways how we can run some of the
template compilation as a part of the build step,
and then extract metadata. That could speed up
the startup time. So this is one of the things
that we are already doing. AUDIENCE: This is for James. I need to measure the
performance of my app constantly. I’m looking for a decent
approximation of performance. And I was thinking the trailing
average of the digest loop. Is at a reasonable
thing to measure? Or do you have another idea? JAMES DEBOER: So, you’re
looking for a number that’s fairly stable over
time, that you can say, this is what it was
last week, and this is what it was a month ago. That’s one number. There are a lot of numbers. And the one that really
matters is how long it takes to get the
pixels onto the screen. And we don’t have a
good way of actually getting that number yet. So that did not
answer your question, but we’re still
thinking about it. AUDIENCE: So question
around– two questions. Over here. One on migrating to 2.0,
given what you’ve just said about backwards
compatibility. If I’m in the midst of a
large corporate deployment, maybe have a couple thousand
lines of code that’s deploying this
summer, am I going to have to rewrite
all that code, given backwards compatibility? MIKSA HEVEREY:Did
you say thousand? AUDIENCE: Thousands. MIKSA HEVEREY: Oh, thousands. OK, I was going to
say, only thousand? AUDIENCE: Couple thousand. MIKSA HEVEREY: As I said,
most– for this summer, no. I missed that part. AUDIENCE: Next summer. MIKSA HEVEREY: Yeah,
you have something to worry about next
summer, not this summer. But to give you an idea. The things that will
change is the API surface. And if you look at your
app, most of the behavior goes into what we
call controllers. And most of the controls
actually, if you notice, this is something that I
think we’re very proud of, is that there is a very
little API surface that ends up inside of
your controllers. So there isn’t really
a lot of methods that you end up
calling inside of it. So all of that code is safe. The stuff that will change is
the APIs and therefore things how you declare a directive. Things how you
register a directive. There will be some changes
to the templating and syntax in templating. But most of these are
going to be mechanical. I don’t want to say
regex style, but they will be mechanical and like,
oh yeah, this is now that, and this is now that. I just have to go
through it and– so it’s not going to be trivial
change, but it’s not going to be a rewrite
by any stretch. AUDIENCE: And the
second part, are you guys going to look
at, with interface, mobility performance. Because I’m doing certain
things to get around performance for mobile right now. So is mobile a part of the
focus of 2.0, hopefully. IGOR MINAR: Yes, mobile is
very much a focus about 2.0. Igor, do you want to
speak more on this? IGOR MINAR: Yeah. 2.0 is really mobile and ES6. And with ECMA Script
6, you actually have to realize that in
order to get the most advantage of Angular 2.0, you
really should be using ES6, otherwise you will have to
write a lot of boilerplate code. We’ll make it possible to
use Angular 2.0 with ES5, but it’s not going
to be as nice as ES6. So really when you
get to Angular 2.0, it’s going to be ready
when ES6 is ready. And I think at that
point, many of you will start thinking about
how you migrate your code bases to ES6. Which is going to be
even bigger change than changing from Angular
1.0 to Angular 2.0. So at that point, I think
for many applications, it doesn’t make sense to
upgrade to ES6 just because. Or upgrade to Angular
2.0 just because. For other applications,
it makes sense to invest the
engineering resources to upgrade the infrastructure,
upgrade the APIs, and get the benefits. Because it’s application
that you value, that the business
depends on heavily, and you continually update. And because of all the
advancements in Angular 2.0 and ES6, you will
be more productive. So there are always
trade-offs– again, sometimes it doesn’t make sense to update all
the code bases because it just doesn’t make sense. AUDIENCE: Question. IGOR MINAR: The mike is off. AUDIENCE: Yes. Question regarding my
day-to-day work with Angular. There is an angular-seed
that is available on GitHub that they divide the structure
basically on the purpose. Let’s say service,
directive, and controllers. And I have been
talking with people that prefer to create one
single file that would hold up the components or the features
in one single JavaScript file. So sometimes I see
myself questioning, do I need to create a separate
JavaScript for this directive, or should I put multiple
directives inside one JavaScript file. Do you have any good
recommendation for that? [? BRIAN FORD: I ?]
can take this one. So I’m responsible for
angular-seed, and the directors structure that exists there
was created on a plane from New York to San Francisco
many years ago. And since then, we’ve learned
that there were better ways to organize the projects. And inside of Google we’ve
been trying different things. Recently, I think
about a month ago, we published a blog post
about the best practices and conventions for organizing
files in large projects that we use inside of Google. So you can go to
blog.angularjs.org and you’ll see this
blog post, and also links to document
that describes what the preferred structure is. And definitely for any
serious application, functional–
organizational files is preferred, which
means that you will look at your application
and see what kind of areas are in your application, and
break down your application according to those
areas, and break down files for those areas. This is something that is going
to be more focused– we are focusing on this
more in Angular 2.0. And we are going to have
better version– we’re not going to do
angular-seed anymore. We’re going to do Yeoman or the
kind of style of a generator where you’ll just have to
come online to a level, just generate all this
boilerplate code for you. And we’ll guide you
through the process of structuring,
application, and files.

45 thoughts on “AngularJS + REST Made Simple: Connecting AngularJS to a Backend with REST & JSON

  1. Jon Post author

    It really start at 17:52, the part before can be sum up as "We provide a tool for REST backend"

    Reply
  2. gal avidan Post author

    can you please upload the presentation so wecould see it 

    Reply
  3. Cuong Vo Post author

    James presentation starts at 38:27 and Misko's is at 50:55

    Reply
  4. schlogen Post author

    Whats with the sound starting with James' presentation?

    Reply
  5. frusfromus Post author

    Indians should not be allowed to ask questions. Annoying and confusing.

    Reply
  6. vidhyadharan D Post author

    Hi Frusfromus .. why Indians not allowed can you please explain ?

    Reply
  7. ilusha pichugin Post author

    UM AM UM AM AMUM UM AM UM angular AM UM AM UMAMAMA UM

    Reply
  8. Dan Cancro Post author

    I would recommend putting a clear notice on the page where one downloads angular seed that this is not the recommended app structure and include links to the style guide.  I think it's easy to assume that a seed application contains all the best practices unless it states otherwise.

    Reply
  9. Vishal Sakaria Post author

    I don't want to know about Dream Factory I just want to know about AJS RESTful examples! 🙁

    Reply
  10. savvyAx Post author

    @frusfromus i think fucktards should'nt be allowed to comment on videos either…

    Reply
  11. g0dbel0w Post author

    Is there something interesting on the ceiling? 

    Reply
  12. elenelena elena Post author

    I am almost agree with frusfromus
    "You can safely skip the first 38 min of it. "
    But I think that only 36 min, because on 36.01 there is a link to angular code,
    how to use $resource with parameters. 

    Reply
  13. Rubén Sospedra Post author

    Well, you speak about all except "AngularJS + REST Made Simple: Connecting AngularJS to a Backend with REST & JSON"

    Reply
  14. Ricardo Ibarra Post author

    This talk is about everything but angular rest and json. Im on min1:04:12 so to late to abandon ship 

    Reply
  15. Ricardo Ibarra Post author

    No one can answer anytthing or are the questions wrong lol

    Reply
  16. Angel X. Moreno Post author

    What am I missing from the comments? I found the part on DreamFactory to be very good. I'm currently playing with Parse and Firebase. DreamFactory seems to be a great free and open source alternative. The service is free for crying out loud.

    Reply
  17. Victor Tiamson Post author

    I spent 28  mins before got  bored because AngularJS + REST Made Simple is nowhere to be heard.  

    Reply
  18. R A Post author

    Same here yo thanks comments haha wtf lifetimesaver  10/10
    But it's true. Using Json and Jackson with AngularJS is neat

    Reply
  19. Jeff Lane Post author

    You want your Unit Tests to "be succinct and run incredibly quickly"… How about making that a goal for these videos?

    Reply
  20. Daijyobanai Post author

    Nothing like putting a huge black border around the screencast so that the  code is tiny and unreadable in 720p. Are YT and Angular both google, because it  says a lot that one can't make a decent video for the other.

    Reply
  21. Ian Juma Post author

    shameless promotion, and a waste of time!

    Reply
  22. Pedro Henrique Ramos Souza Post author

    Just a cheap marketing about Dreamfactory…
    Don't waste your time.

    Reply
  23. Laura Richter Post author

    Great preso, covers an open source mobile platform and how to call services from Angular

    Reply
  24. TKollaKid Post author

    That's Google? It looks so ghetto. Why are they filming it next to some random emergency exit? lol

    Reply
  25. Pinned Post Post author

    I can't imagine being stuck in a meeting room with these guys

    Reply
  26. Leandro Rodrigues Post author

    It is not useful to people who are learning due to the fact that these guys didn't do a good job, it should have been baby steps and well explained. Therefore, I do not recommend this video.

    Reply
  27. Slam CS:GO Post author

    At least i know i have something in common with these google guys. we both have no idea what they're going on about.

    Reply
  28. Zvika Dror Post author

    Everyone who are complaining about the content – you are missing the point! To see Ryan Gosling (PM presenting) and Yermi Kaplan (guy on the left at 1:13:00) doubles together in a single video… wow shocking 🙂 and they sound smart! 🙂

    Reply
  29. Ima SuperPerson Post author

    If it takes an hour an 38 minutes to explain it, then it's not simple.

    Reply
  30. Mr. Gaia Post author

    For those interested in having an easy start for the concepts discussed in this video (Angular), there's a couple of videos about using Hyper IDE with Angular. Hyper IDE is an Open Source web based development environment, with strong Angular support, also providing a mature and secure backend for those wanting to go "full stack" 🙂

    Check out the "Videos" section of my channel for details …

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *