Articles, Blog

Creating realtime apps with Angular 2 and Meteor – Uri Goldshtein

December 6, 2019

Hi, everyone. My name is Yuri, and I’m a
core developer at Meteor, and I’m also the weird guy
from yesterday’s keynote. I also owned– before I used
to be a Meteor developer, I used to be an
Angular developer, since the [INAUDIBLE] 0.9 days. So the fact that
Angular 2.0 is in alpha is not really scary for me. And later on, I wrote the
Angular-Meteor project, which actually, I started
before joining Meteor, and I’ll talk for a bit about
this project, as well today. So in yesterday’s
keynote, I talked a little bit about the concept
called the connected client architecture. Today they’ve given me
a little bit more time, so I can dig more
deeply into it. And why I think this is very
important point that you should get from this talk and from
this conference at all, and you should get the
point to your own stacks, doesn’t matter if you
use Meteor or not. And then I’m going
to talk about Meteor itself, and the relations
to Angular, and Angular 2.0. What is the connected
client architecture? In recent years, we
all know about it. The web has changed
our mobile apps. Our web apps are now apps. They’re using mobile UI. They’re not using pages,
and less of links and forms, and more, like,
modern UNIX and UI. We use it to mobile. There’s no Refresh button. The user is not hitting
refresh anymore. And we know all about it, right? We use Angular in our
modern frontend frameworks are already adjusted to it. But the thing is
that those types of apps that are– actually
this UI and this change started from the large players
in the industry, right? Like the Facebook
web app, or Gmail, or applications like that. They use a different
type of architecture. And they don’t use arrest
for a restless server, a stateless server with
a request response. They use a stateful server
with publish subscribe, and somehow our frontend
frameworks, until now, try to compensate
on linking those, and us working on rest
types of backends. But we are still missing
this type of connected client architecture. And the thing is
that our clients need this type of– our users need
this type of architecture, and they’re expecting it, even
if they can’t verbalize it. So what is a connected
client looks like? First of all, the backend
of this connected client architecture is to push
live updates from the server all the time. So it’s not like the
client is sending a request and getting a response. It just updates in real
time, all the time. The second thing is that,
when a client makes an update, let’s say, Like button
on a Facebook page, you don’t have a spinner. You don’t send an HTTP call,
and wait for a promise, and then respond to the user. The user will leave
your website today. He expects more. So with Facebook, the delight
is happening instantly, and then when it goes
back to the server, and is sitting there,
tough syncs happens. The user don’t care about it. So even if you
clicked now on Like, and now there’s like two
Likes, but in the meantime, there are 50 other
Likes on the network, the Facebook infrastructure
will take care of them. And right now your backend
servers don’t do that. And if you are doing that,
you’re doing a lot of work. The third thing is that you want
this new type of experience. You want it on all the devices. You want it on your watch. You want it on
your mobile device. And on your IOT devices as well. Our users don’t want to
wait for spinners anymore, or for request response. So how does Meteor fits
into all of this picture? Meteor is based on
three big concepts. One, Meteor is built
as a framework. It’s a completely
open source framework. It’s built on that
type of architecture, and I’ll show that in a second. The second thing is, Meteor is
big on the course of JavaScript Everywhere. And we are in a point that we
can write JavaScript anywhere, and more than that,
it’s the only language that’s gone anywhere. So if you’re going to create
a platform that would truly solves everything for us, we
have to write it in JavaScript. The third point is that this
is a complete open platform. It means that it takes
care of everything for you, but it’s still open
source and decoupled, if you need to change stuff. So I’ll dive a little bit
into each of those concepts. So about connected
client architecture. So the first thing we
need is to push updates all the time to the client,
every time a change happens. Now if we’re writing it
today, on our own servers, we would need to
somehow recognize that there was a
change in a database, and write a lot of manual
work to then propagate this change to the client. But with Meteor, which
was built by engineers that came from Facebook,
Asana, and Google, this type of architecture
is built in from the start. It means that on every
layer of the platform, there’s something
that’s handles that. And I’ll just touch on
few meaningful points. The main thing, if you’re
working on the server, is livequery. Instead of now– you can think
about it as, kind of like, watch on the database. Doing a watch on the database,
but in a performance way. You can just define
your database query. It can be a mongol
query or a SQL query. And then this query
will self update it. It will notify when something
has changed in the database, and it doesn’t matter if this
is a change from your app to the database, or
either a third party change from another
server to your database. So it saves tons of code,
and tons of potential bugs. And it’s, kind of
like, the way Angular changed the jQuery world. So that’s livequery. And this is just one concept
that exists in Meteor, and probably in like regular
rest type of applications, you don’t use it. Or you need to
write one yourself. Second concept is
sync client cache. Sync client cache hides
behind that concept like two different jobs
that you need to do. The first thing is to
propagate those changes that are from the livequery
to your applications. And in literary,
you can actually– you can write– like you
wrote your query just once on the database, it
will automatically propagate this data with publish
subscribe to your clients, with one line of code. And you could obviously
change it and expand it, but the thing is that this
cache will sit on the client, and it will save you a lot,
lot of code for writing syncing services, and all kinds
of stuff like that. And think about it. If you were working as a
frontend engineer at Gmail, you would expect to get
this type of infrastructure. A frontend engineer
at Gmail would never cause an HTTP request,
and wait for a response. It has an infrastructure
thing that takes care of that for him. And that is the same thing here. The second thing that
connected client, we talked before
[INAUDIBLE], if I’m now pressing the Like
button in Facebook, or if I’m writing
a draft in Gmail, I want it to happen
instantly, but I don’t care about network latency. I want it to save instantly. There’s a lot of syncing,
and tough syncing mechanism, that I’ll show in a second,
but you don’t need to do, if you have this infrastructure. The second concept that
Meteor is right about is JavaScript Everywhere. Meteor takes care
of your server, and your web clients,
your mobile clients. It connects to IOT devices,
and also to watches. And in all of those platform,
Meteor runs JavaScript. And that’s the only
language that you are going to actually use. Meteor is built on
JavaScript, and it’s also completely open source. If you looked at the connected
clients that we talked before, some of that code already
exists, like the frontend code, and you’ve probably heard about
f.lux, and GraphQL, and relay. Some of the code is being
outsourced, open source from the large companies. But none of the
large companies is going to open source the
backend infrastructure. Meteor is your open source
backend infrastructure from that type of
infrastructure. And you should understand
that your users demand that infrastructure, even
if they don’t know that, because the user use Facebook,
or they’re sharing photos on Instagram, and they
don’t care that you are a small development team. They want the same experience. So if we combine,
let’s say, just for example, we’re
combining two concepts. One is isomorphic, completely
isomorphic is JavaScript. You can run really JavaScript
Everywhere, and use your code any where with Optimistic UI. Optimistic UI is
the concept that I talked about the Like
button, where you press Like, and it happens instantly,
and then later handles all the tough syncing latency
compensation with the server. So how does it look? Everyone is talking about
isomorphic JavaScript, right? We can write
JavaScript Everywhere and everything is fine,
but when you actually work on the MEAN
stack, for example, then you have your
particular user has a different name on the DB. It has a different name on
the server and the network. And it has a different
name on the client. You can’t really
share code with it. You could maybe share
some of your T-code, or something like that, but
that’s not working actually. But with Meteor,
you can– actually the API is the same
throughout the stack. It doesn’t matter, on the
database, and on the network, and on the client,
it is the same code. So I can really use the same
language, the same database API, and I get true isomorphism. I can write any method, and I
can run this method everywhere. And this is fun. And this is nice. And it maybe saves some
time when you write code. But the true way that
it makes a difference is when you combine
it with the syncing mechanism in Optimistic UI. Just an example, let’s
think that the right now, we are clicking on the Like button. So we clicked on
the Like button, and then we execute this
method, that’s called +1, or something like that. And this method is–
we write it once, but it runs both on the
client and the server. And when it runs on the client,
it’s happening instantly, and it just adds from,
I know, let’s say, we had two Likes to
three Likes, and then it updates the UI instantly,
and for the frontend framework and the
frontend developer, that’s very easy, because you
don’t care about promises, or something like that. It’s a local database. So it happens instantly, in real
time, and you just now have +3. But now, the same
thing, the same request comes to the server, and the
server runs the same method. We wrote this method once. And when this method runs on
the server, then let’s say, maybe I don’t have permissions
to do that, the thing, or maybe while I was
little clicking the Like, and there was a
latency on the network, there were 30 other
users, like adding a +1, or maybe blocking my post,
or I don’t know what. Meteor would take
care of that for you. It doesn’t matter if what
you did was exactly the same, or there was a
problem on the way, Meteor would then
send the right data from the server to the client,
update the local cache, and get you the real UI. And for you, the
user, it just happens. And if you look at applications
like Inbox, or Google+, or Facebook, that’s
what’s actually happening. And you can write
this stuff yourself, but think about
how many edge cases you would need to handle
to handle this complexity. The Gmail infrastructure team,
and the Facebook infrastructure team are really, really big. If you were going to
do that for yourself, you need to understand
that it’s not as easy, Now like I said, it’s not easy. But the actual code is very
similar between those cases. And if you look at the
strategy that Gmail uses, and the strategy that Facebook
uses, it’s pretty similar. Meteor– and you can write
that stuff yourself– but Meteor is doing that
for you out of the box. And it’s completely open, so you
can change everything inside, but out of the box you
get a complete platform that works for you. And when you think about
it, most of the code today is not written in node, not yet. Most of the code today is
written in .Net and Java. And the reason is because
those are platforms. When you write .Net code, you
can expect most of the stuff to work together out of the box. And then later, you
can change stuff. But the problem is in
the JavaScript ecosystem, we don’t really have
something like that. Everyone likes mix and match
stuff, and that’s good. The JavaScript
ecosystem is amazing, but if you just want
to write your code, you don’t want to do this
mix and match all the time. I mean, every second
day there’s a new build process, and
a new thing, and you don’t have the time for it. So we need JavaScript platform. And the JavaScript
platform needs to be a build from small parts,
but that are loosely coupled, but out of the box,
it works great. And someone is taking care of
for you, like an infrastructure team that takes care of
all this infrastructure, working for you. And that’s Meteor. And the difference between
Meteor and .Net and Java is that Meteor is, also because
of the power of JavaScript, runs everywhere. It takes care of everything
you need, from the mobile, and everything from the
mobile and IOT devices. But also based on
what I said before, about the connected
client architecture. And your users want it. Then your next
project will probably be a connected client project,
because your user expect that. Meteor is also not
a new thing anymore. It’s like, just recently, it
became the first– the highest rank on GitHub’s web
application framework, so it’s best writers on
GitHub, like their home ground. And there’s over 200
meetups, and there’s over 7,000 community
packages, and if you look at– I hate those graphs–
but if you look at the trend graph– when I
started using Angular, I tried to explain to
people that Angular is going to be big, I always
looked at the trend graph, because it was very unpopular
to use Angular at the time. And if you look at the
trend graph for Meteor, it’s the same. So how does Meteor
relate to Angular? Like it’s the same thing? Or some people
ask in the forums, is Meteor better than Angular
or Angular better than Meteor? So the Meteor is a platform,
like I said, and it’s decoupled– it has
decoupled parts, so you can actually
use Meteor with React. You can use it with Angular
2.0, or with Angular 1.0, or with Blaise, and you can
actually mix and match there altogether. So when I started at the
Angular-Meteor project, my goal was to make Meteor
like a first class citizen in the Angular community. So everything that’s happening
in the Angular community, Meteor should be part of it. And it wasn’t easy, but I
think I can say that today, we are there. The first thing is that
anything you want to use, that you use today on your
Angular 1 applications, you can use with Meteor. You can use Ionic. You can use Firebase. You can use UI Bootstrap,
or anything you want. So that’s one thing that
we are with the community. But there’s other stuff
that we actually, I think, lead the community,
and have the community around. So I just– last week I released
a blog post and a tutorial about writing WhatsApp clone,
in Ionic, Angular, and Meteor. And I truly believe that
this is the fastest way today to write mobile applications. And you can check it out. It’s on the Ionic blog. And the second thing we’ve
done, and we have the community as well, is that one of our
community members, named Paul, wrote, six months
ago, Angular2Now, which is– you probably
heard about ng upgrade that you’re probably going
to soon be able to use. We are using Angular2Now
for six months already, and it’s basically
the same concept. You can use Angular 2 syntax,
and I show that on ng-vegas like six months ago. You can use the Angular 2.0
syntax today on your Angular 1. And Paul was part also
of the ng forward, too. But what’s really interesting
is Angular 2.0 Meteor. Because Angular 2.0
Meteor– Angular 2.0 is built for this
type of architecture. Angular 2.0 is built to support
large client applications that require this type
of infrastructure. It works great with it. So the integration between
Angular 2.0 and Meteor is really exciting. The first thing is
that it’s probably the easiest way to start
Angular 2.0 application today. The only thing you need to do
is go on the Meteor platform and do Meteor add Angular
2.0, and that’s it. And you’ll get all
the dependencies, and you get the build process,
and you get everything you need, out of the box. No got files, and
no any other files. So that’s one thing. Now the second thing is
the infrastructure itself. So the integration was
so much easier to write, and it’s so much easier
to learn as well, because in integration that we
build in the new Angular 2.0 Meteor package, we don’t
use pipes or observables. You can just write
regular Angular 2.0 code, and it goes the same way,
and it’s just connected to a Meteor collection. That’s a good thing
also in the Meteor side, because in the Meteor side
you write pure Meteor code. There’s no connection
code, the no everything, and I’ll show that in a second. And the way we were able
to do that is, instead of letting you
write observables, and use observables and pipes,
which are nice, but sometimes hard, we actually, because
of the power of Angular 2.0, we were able to link
into the defer process, to the change detection
process of Angular 2.0, and let Angular 2.0
know about the changes that happened, because
Meteor already knows that. And that’s what’s made the
integration super simple, but also super fast,
like I showed yesterday on the keynote. I’ll show really
quickly how it works. So I have the– you
see my environment. OK. What I have here, and I’m
not going to live code today, because I don’t have the
time, but this is probably the same types of
applications that you saw me write them on ng-vegas. Every time it’s parties. So same thing. And this is just a
regular app, and let’s say I’m creating a new
party in London, and it will sync instantly
between all the clients. That’s fun, and you saw that
already in my previous demos, but the interesting thing
is to look at the code. The code that I have here,
the Angular 2.0 code, looks exactly the same,
like a regular app, but the only
difference is that I’m bringing my collections here,
with imports with TypeScript. And you see that I’m using
TypeScript for Meteor, or you can use TypeScript
both on the client and both on the server. And in our tutorial,
we actually do that. We use TypeScript on the
client and on the server. And then the only
thing I need to do is to say that parties
is a mongol cursor. And that’s it. And then the constructor
will fetch everything. And from that point on, I
don’t need to do anything. You can look at my HTML code,
there’s nothing Meteor in here, and there’s no pipes
and no observables. This is like the, I don’t
know, like the simplest to do, that you get on the
Angular tutorials. This deep integration, I
think is very valuable. So going back–
this is integration was possible with the work that
we did with the Angular team. And you can actually– again,
you don’t need to trust me, you just need to go
to, there’s a tutorial that we
already built for Angular 1 Meteor. But then I took the same
tutorial, and every step that I’ve made, and
it’s a full complete tutorial with like 21 steps,
with Ionic. and users, and permissions, and it’s
complete full stack app, and basically step by step, I
converted it to Angular 2.0. So it can actually
go to a step five and just compare Angular
2.0 and Angular 1. So just– you need
to check it out. And I think the
most exciting thing about writing this
Angular 2.0 Meteor package is the
collaboration of the work that we did with
the Angular team. I spent a bunch
of time with them, and they helped me a lot,
tapping into the change detection mechanism
was easy, but they helped me a lot with it. So I’m just very
excited about click, the next, the road ahead,
and our work together to make this type of stack
available for everyone. And it’s already available, so
you can just start using it. And I think that all the
stuff that I showed you today, I can safely say,
and I’m probably going to– some of you
probably going to be mad at me for saying that–
but I really think that Meteor is the best
backend for Angular apps, for all the reasons
that I told you today. So what are the
takeouts from this talk. First thing is that there’s a
backend revolution happening. Angular did a huge revolution
in the jQuery world, and it was era of change. But if you look at what Meteor
is doing on the backend, it’s the same thing. It’s like what Angular
did to jQuery world, Meteor is doing to the DB,
and to the server code. And that’s the same
thing is what Rails did for Rest type
of application, it used to be very hard to
write Rest type of applications, but then it became a standard. Meteor is doing for the
connected client application. So it’s just best Rails. And the second thing,
the second point, is now is the time to become
a full stack developer. The opportunities that Angular
gave you when Angular came out, Meteor is giving you
right now on the backend. So you should take out that
opportunity, because there’s more and more things
and jobs, it’s one thing that does the
backend and the frontend. And your next app will probably
be a connected client app. You can write it
with an all backend. And try to simulate
everything yourself, or you can use an
infrastructure that is built out of the box for that. So that’s it. The only thing you need to do
to get all this information is just google Angular
Meteor, and thank you so much. [APPLAUSE]

You Might Also Like


  • Reply João Vilaça October 24, 2015 at 11:23 pm

    Well done man, nice presentation!

  • Reply Abdourahmane FALL October 25, 2015 at 12:29 am

    i fully agree, JavaScript is the only language you can write everywhere.
    From client to Database. Fully JS

  • Reply Gareth Connor October 26, 2015 at 10:34 am

    Great presentation explaining Meteor + Angular-Meteor. Uri is a ledge for this work and promotion to bring Angular and Meteor together as the best stack for building apps. The only missing piece was Ionic support which he has also worked hard to ensure it happened and now you can build really native look-and-feel apps using the stack as well. Bravo Uri!! 🙂

  • Reply Thomas Groh October 27, 2015 at 10:11 pm

    Sweeeet !!! Nice Platform, excellent demonstration. A++++++ !!!

  • Reply Luka Šilje October 28, 2015 at 7:40 pm

    amazing, thank you!

  • Reply Robbie October 28, 2015 at 10:42 pm

    very cool

  • Reply Hongbo Miao November 4, 2015 at 2:05 am

    Meteor and Angular 2 together are really powerful!

  • Reply November 12, 2015 at 6:51 pm

    Big Like!

  • Reply Sam Deacon November 21, 2015 at 10:26 am

    the future's upon us baby!

  • Reply kyle40581 December 22, 2015 at 12:16 pm

    Great summery! I think Meteor + Angular 2 is all I need to develop my hybrid app.

  • Reply Suresh Kaki March 28, 2016 at 3:22 am


  • Reply El Océano April 30, 2016 at 11:16 am

    Amazing work. That's how the future of sofware development must be, in my opinion. We need a lot of common sense and good engineering in the actual landscape of software development, where fragmentation and complexity seems to be the rule.

  • Reply Pankaj Verma August 14, 2016 at 12:31 pm

    Excellent session that connects key user asks to current day technological options. thanks.

  • Reply Ronald Espinoza September 20, 2016 at 3:35 am

    Agradezco mucho el material y el esfuerzo y dedicación del expositor y de todas las personas que hacen posible que se comparta todo este conocimiento increíble. Dios los bendiga.

  • Reply Yay June 2, 2017 at 7:15 pm

    so there is no HTTP protocol at all ?

  • Reply Achil Sowa August 30, 2017 at 4:45 pm

    Why is meteor taking that much time to compiler ???
    It makes the dev process even slower

  • Leave a Reply