WARD:
Something good just happened there, okay.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -AngularBootCamp.com.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures” you'll get a $10 credit!]
CHUCK:
Hey, everybody! Welcome to Episode 50 of the Adventures in Angular show! This week on our panel, we have Lukas Reubbelke.
LUKAS:
Hello!
CHUCK:
Ward Bell.
WARD:
Hello there!
CHUCK:
Joe Eames.
JOE:
Hey, everybody!
CHUCK:
I'm Charles Maxwood from DevChat.tv. This week, we have a special guest. And that's, Uri Goldshtein.
URI:
Hi, everyone!
CHUCK:
Do you want to introduce yourself?
URI:
Yeah, sure! Thank you! I'm Uri Goldshtein, and I wrote the library that's called "angular-meteor" that obviously connects Angular and Meteor together. I'm here to talk about that and why I think Meteor is really good for Angular developers.
CHUCK:
Awesome! So Meteor, it's that isomorphic thing, right?
URI:
[Chuckles] Yeah. It's that isomorphic thing. It's much more, but I guess we're above a little bit into it.
CHUCK:
Do you want to give people an idea of what Meteor is?
URI:
Yeah. Meteor is a JavaScript platform. The idea is to take care of all your needs from the database to the server until the client's end on the mobile apps and give you best practices and extra tools to make it work out-of-the-box for real-time applications. So out-of-the-box, you get many, many tools that you know that are working together and you can just start working. Those tools can also contain Angular or React or Blaze or any frontend framework that you like.
CHUCK:
Very cool! Now, is there a company behind Meteor?
URI:
Yeah! Meteor is a company that's based in San Francisco. I think they started 4 years ago, but I might horribly be mistaken by that. They are funded by all kinds of important people [chuckles], largely funded. And, they have, I think, right about 30 people onboard and they're getting bigger by the day, it seems.
WARD:
When I first looked at it a while ago, it was just coming out, I think 2-3 years ago, it was a total Meteor environment and they were all talking about seemless front to back and you're all in on everything. There was not room for Angular, actually, at that time because it was updating the UI as well as updating your data, so pushing them, so there was all that. It wasn't also clear, it was opensource, it wasn't clear how Meteor with all the transistors are going to make money. A lot has changed since then. Is Meteor all open-source and free now? What's the roll of this thing called Galaxy? What can you tell us about how it's structured for a developer who is thinking about whether they dare put their app into Meteor?
URI:
Good question. When I started, I obviously been an Angular developer long before I started using Meteor. I always was intrigued about that Meteor thing. I saw their video building an app in 10 minutes 4 years ago, and I thought, "Yeah, okay, everyone will talk together and everything will be perfect". And when Meteor walks with Angular, I started doing that. After 3 years or something, nobody deep like a serious thing, so I started digging into that. And when I started digging into that, I found out that Meteor is not like this big monolithic thing that everyone think it is; it's just a collection of packages. And when I started digging deeper, I saw that they started out-of-the-box with their own frontend UI framework that's called Blaze, and it's a good framework, but I obviously prefer Angular so I started looking how can I combine the two. Basically, I started copying some of the code and looking into how Angular works deeper. I think in a matter of -- the first version -- in a matter of a week or two, it was working. It was working just for my app, just for my needs, but it was pretty simple. Since then, I just started using that more and more. I think, what changed right now is more of the story that is being told than the actual code.
Meteor was always a collection of packages. I think they took a big task so they didn't have time to talk about how this is a collection of packages, and not just like this one solution. Because the top priority was to give you a working platform out of the box, which is in the JavaScript community right now, I think it's something that is really missing. You have all kinds of great tools, like a
collection of great tools working separately, which is really good, but when you just want to create an app and you want to guarantee that it works and you don't want to struggle and lose time or resources on combining versions of two different libraries, then this is that really big offering, and it's not simple thing. So I guess, right now, with my job as well, they started to have more time talking about how Meteor is extensible and why they chose what they chose and how does it fit to the larger JavaScript community story.
WARD:
Right. That's amazing that there's something great for somebody who just want to whip something up. But if we were going to try and build our production and app on it, we're going to want to be able to go our own way.
Part of that also was that it seemed like you had to be hosted on Meteor's own servers at that time, there was sort of an illusion to what you could take it to some place else, but for a lot us, that was going to be an on-starter. But, you're saying now that I can deploy to AWS or something else? Or, it's all different? How is that work?
URI:
Yeah. But I think, as long as I know, at least as I know, that was never the story. The story was, you could always use your own things and always replace those stuff. And I am just a guy from the community who added Angular. I just took in initially and did that, and other guys did it with PostgreSQL, which was another big story about how Meteor does work with SQL.
WARD:
Ahh, right.
URI:
And it does. About deploying, you could always deploy it on your own servers. There's now more and more community tools (that are really good ones) that other companies, based on the Meteor ecosystem, develops so you can have one command-line to deploy to Meteor, you can have one command-line to deploy to AWS or Heroku or Modulus or all kinds of other solutions.
WARD:
Well, I'm glad to have all of my misunderstandings shattered...
URI:
[Chuckles]
WARD:
I don't think I was the only one who had those... And it's natural in the early going; it's hard to get your story communicated in a way that actually comes across the people the way they expect it. I'm totally blown away that it works with Postgres and not with Mongo. I thought for sure it was locked in the Mongo, and you're saying it's not!
URI:
Yeah. First of all, you're perfectly right. And I must say that when I started trying to use Meteor, I was like super angry, I guess. But then I started -- because of all the stuff I heard about -- I guess it's the same way when I started using Angular. Everybody told me, "Who uses Angular?" I started super early and everyone was like, "No! You have Backbone, and you have JQuery, and everything is great, so why use Angular?" They started saying all kinds of stuff about Angular that when you just try the Angular, you realized they're not true; it's just words. And when you want something to work, it works.
I think, for me, Meteor wans the same. This is why I think I pushed Meteor so hard on the solution that I wrote because I think that Angular, like philosophy in the Meteor philosophy, are so similar. And I think because they are both were leaps ahead of the other solutions, it's hard for people to grasp the whole thing and it's frightening, I totally agree. But when you start digging into it, and now there's better and better explanations about how it works and what Meteor is, I think the fear goes away slowly. But I guess the best thing to do to remove the fear is just to try it.
About SQL, there was always rumors about there's a community solution and stuff like that. Recently, I had people asked me about that and they tried a particular solution from the guy called Ben Green from the Meteor community, and it works great for them. It has live query, which maybe I'll explain later, on PostgreSQL and it syncs the client-side cache.
So the hardest and the most difficult stuff that Meteor is solving, that package is solving on top of SQL, and it works. And definitely, I think yesterday or today, Meteor released their blog post about what's going to be in Meteor 1.2 and the SeQueL is one of them. So definitely like a core development on SeQueL of the core team.
WARD:
That's going to really open the space for people to consider Meteor because much as many of us like Mongo for some things, some of us are afraid of it for all things, and this is really going to make some of us rethink what our relationship to Meteor will be like. So, that's exciting. I don't know that we can take up their show with that, but that's really exciting.
Is this open-source? And free, right?
URI:
Yeah, yeah, yeah.
WARD:
So how do they make money? [Laughs]
URI:
[Chuckles] That's awesome question. The idea is to make the same easy experience of developing the app as deploying the app. The idea is that you won't need to take care of scaling. Scaling is a huge problem and a lot of people are asking about it in any technology. I guess every time you're afraid of a technology, the first thing you do is asking if it scales. And Meteor already scales. There is already community practices, community tools that help you with that, but Meteor wants to make it seemless. So, Galaxy is the solution that they're going to charge on, and that's their moneymaking machine, I guess, that you could just deploy to a hosted Meteor solution servers.
I just recently saw the unseen interface of this thing that helps you sync and organize all your apps, and it's amazing. For lots of years, I've been working with AWS and a little bit with Heroku, and the Galaxy thing looks amazing. There's still a little bit more time and it will be public, but there's just solution for that. On top of that, if you are an Enterprise company and you don't want to deploy your apps on the cloud, you want to deploy it on your own servers, then the same thing; you will get the same tools, but on your own servers. And it will cost money because as a company that want to scale, these monies work for you to pay it. That's the revenue story.
WARD:
One of the things that really stands out is the way in which Meteor thinks about change, how it detects changes to data that user A made. Or, how it detects them on the server and then propagates those back to users B, C, D, and E. Can you talk a little bit about what that technology is and the challenges of that?
URI:
Yeah. I guess keeping the client-side cache sync in real-time is the huge problem. It's not an easy problem, but it's also a problem that a lot of real-time apps has. And it's the same problem, like you can look it above any real-time Google Drive, or Google Docs, Gmail, Uber. The thing is that you make a change and then you want the change to happen instantly. So you save it on the local database, or the local cache, or the local database, it doesn't matter right now, and then you need to sync these change into the server. Internet is okay, if you were just living in a perfect world, then you will get instant changes, which is something that still a lot of apps today doesn't do; apps today, when they want to save beta, they call to the server. And when they get the Promise and the response back saying it was succeeded, they say, "Okay," and then you can put a spinner or something like that, but that's not the best UI for real-time applications, and users are getting tired of those.
So, you save it into the local database and it happens instantly, and the user was happy. But you have the server, which actually knows more about the information. It knows that maybe you don't have permissions for it. It knows that maybe another user changed the same thing. This is a hard problem. But Meteor's approach was to handle that problem first of all in the same way that the database has handled that problem because databases are great for keeping positions. So, Meteor is kind of, you could say, "agnostic to the database" in that term. So if we're walking on Mongo, then Mongo has a less right succeed, right? So if we walk on Mongo in that sense -- again, I'm over simplifying it and I can have a whole lecture about it and also there are people that are much smarter than me in Meteor, much, much smarter than me that knows those stuff -- but Meteor walks in the same way that Mongo solves those hard problems. And if we go to, let's say Meteor world walk on top of PostgreSQL, then it will use its way of handling those conflicts. But the most important thing is that, it's actually inside the solution and it's all open-source looking into that. But inside the client-side cache, you have actually 2 client-sides cache, one is the reflection of the server and one is the reflection of the current changes of the client that you're not sure that'd been persistent on the server. Once you get the conferred message from the server, then it just overrides the current state in the client and you know that your data is true across clients. It sounds like very sophisticated and very hard, but the good thing is that, Meteor, you don't need to care about it. If you do want to care, it's a package; you can replace it and you can dig in and you can change stuff. But usually, because it's a very common problem and Meteor has thousands of apps running, or hundreds of thousands, I don't know, running with the same problem, then probably they solve this better than what you presently would have done. I'm sure there's particular cases that you want to start with a different logic, then you can start messing around with the package itself. But I haven't got to the point that I had to do that yet.
CHUCK:
If I remember right, Meteor communicates between client and server. Because we talked about keeping the cache current, but that's all done through a WebSocket, is that correct?
URI:
Yes. And on top of that WebSockets, Meteor published a protocol that now there's more and more people in the community that picks up of that protocol because it's an open protocol that's called "DDP". The idea is, it's a high-level protocol for real-time changes so it's a very similar protocol, in this philosophy, to REST. Let's say I have a real-time client right now and I want to work in front of a Meteor server, but right now, maybe I want to work in front of a .NET server. If I have a particular way of -- I'm using a particular library, let's say Socket.io or something like that to do those realtime changes over Sockets, I have to write a lot of code, and I did that so I know it's a lot of code, to sync it now with a different server. And the whole point in REST protocol is, you don't care about which backend you're working against.
So the DDP is the same thing, but for real-time. There's now clients for DDP for .NET, for iOS, for Java, for I think Go, and even just plain JavaScript so you can just take this and any other JavaScript client and use this protocol. It's like REST. You can look at it as like REST for real-time.
CHUCK:
So then, how does this play into Angular? Because most of the Angular apps I've written, I've been using HTTP, so I haven't been using an actual WebSocket. I just make a request to the server and then I get stuff back, and I keep things and sync myself when I get new information whenever I talk to the server. How does the Angular work with the DDP?
URI:
Before DDP, I just add a small thing that people tend to say is inaccurate. They tend to say that you can't work with REST on top of Meteor. That's not true. You can. There's a package that automatically opens all the REST end points if you want, and you can work with just plain REST with $http and that's perfectly fine with your static front-end, and that's okay. But the real benefit of Meteor is DDP.
So you can take two approaches. One approach is, you have that local cache already synced. It means that you can just, with Angular-Meteor, you can just bind to that local cache -- it's just like one-line, it's a service that I wrote on Angular-Meteor -- you just bind that, let's say scope array, to that local database collection and that's it. You don't need to take care of anything. Then you can just push the array, supplies the array, change inner, stuffing the array, and you can just, in Angular, just watch the array, and it just works like a lot of really good solutions in the Angular community that the Angular community has used. So, you don't need to care about that. If you want to have your own solution, don't use Angular-Meteor. You can actually write your own DDP client and not use the local cache that Meteor gives you, but I don't see why would you want to do that. You just bind it with one command-line and your rest of the application will just work; you don't need to use HTTP or anything. Just change the data and it will propagate to all that clients instantly.
WARD:
For those of us who are interested in the sketch of the method, I think that's where Chuck is getting at, the mechanism, it's like -- let me see if I've got this right and we'll talk to what you're saying with Angular Meteor -- but essentially, what I'm saying is, here is an array that Angular is going to watch, and I want you to manage that for me. We'll populate it initially with all these customers, but as your Meteor learn about changes to customer that I'm interested in, you will maintain that array for me and therefore all the data-binding that I've done to that array will be updated for me. Is that how it works?
URI:
Yeah. That was much better explanation that I want to get up [chuckles], thank you.
WARD:
Does that makes sense to you, too, Chuck?
CHUCK:
Yeah, it does.
WARD:
And that's all the way fire-based. A lot of these things that are reactive, they work that way where the UI layer hands something to the data access layer, and says "Maintain this for me aysnchronously, I'll tell you how to jumpstart it." And then, I'm just leaving it up to you, down there somewhere, whoever you are, to keep that going for me asynchronously, and you'll let me know when we'll rebind the screen. That sounds to me like what you are driving at, Uri, is that correct?
URI:
Yeah, yeah, that's perfect explanation [chuckles].
WARD:
One of the cool things is that, in Angular 2 -- it's just that we can't it because they haven't really talked about it much -- there's some noises going on on the data side of the Angular equation where they're developing new techniques for managing such arrays. Can you talk a little bit about that?
URI:
Yeah, yeah. That's actually, I think, the most exciting thing about Angular 2.0, in my opinion. But obviously, my opinion is very specific because I did a lot of work of synching Angular and Meteor together. Most of that work will be gone in Angular 2.0 becuase Angular 2.0 works almost, at least the philosophy that's coming behind it, it works almost perfectly into Meteor. They're talking a lot about Observables that you get. Let's say, like you said, you're subscribing into this collection, and then in an Observable, you get the changes to that collection from the server all the time. It's like a repeated thing; it's not like a Promise that you get it once. Meteor already has a [incomprehensible] of that observe 4 years ago, and this is actually what I used when I did Angular-Meteor. I'm getting that Observable and handling that data into Angular.
With Angular 2.0, it will be so much easier because I will get an out-of-the-box Observable support. More than that, I don't need to convert this collection data in Meteor, which is just a plain JavaScript object into scope array; I could just leave it as a regular JavaScript object and Angular will know that. Angular will recognize that object, and that's amazing.
Another really interesting thing in Angular 2.0 is something that, right now at least, it's called "Pipes", which means that, right now, I know for a Meteor, what has changed exactly and when. So instead of relying on Angular 2.0 they just cycle, I can just notify Angular now something has changed -- now this has changed, now this has changed. This means that Angular can optimize much better of working with the Meteor data than optimizations I need to do right now on Angular 1 and Meteor. So, very exciting stuff. I think performance there will be amazing, and simplicity, too, will be amazing. And just one more thing to say about that is that, the one-way data-binding, I think this is the approach that React has gone with, and Blaze has gone with as well. Now, Angular is pushing that to the next level in Angular 2.0, and I think this is amazing. Just looking at the code, they had to write to do Angular-Meteor now, and looking into how much of that I can just delete in Angular 2.0 is very exciting.
WARD:
Well, you touched my third grail there by knocking two-way data-binding, but we'll let that one slide for the moment. [Laughter]
WARD:
Everybody who listen to the show knows that's a hobbyhorse of mine. Anyway, I wanted to drop act to one of the things that I, again, for our listeners to draw attention because you mentioned of the Observable stuff, and I'm not sure if everybody knows what that is and we can't go deep into it here today, but it's kind of promises on steroids as one way that over simplify it.
URI: [Chuckles]
WARD:
But imagine that you can do a lot more than just react to a chain of success or failure, which is pretty much what Promise allows, is really a composable system for pipelining your interest in this flow of information that could be coming back remotely. So you can do throttling, and what if I want to cancel, and filtering, and delaying, and you can compose all of these different ideas together as you're trying to manage the flow of asynchonous data coming back at you from a server. Is that a fair characterization, Uri? Or, would you like to describe what goes on there in some other way?
URI:
I think it's okay. The deals of the actual implementations are still have to see what the team will come up with. Hopefully, I will get also to San Francisco soon so I can, maybe, help or give my opinions about that. But I think that there's few things like Observables right now when the Meteor gives you exactly what changed in a flow, and this is very unique and I think this is very good for Angular. If they will implement the same API on top of Observables, or maybe similar API on top of these Observables as Meteor is doing, then I think everyone will benefit from that, any other solutions from the community. And about Pipes, I think, this is -- well, I'm just repeating what I said before -- I just think it will be a huge leap.
WARD:
I think you're right, and I actually think I called out the most important feature. As most people already know what this Promise versus Observable thing is, I suddenly reminded of it, it goes back to what Chuck was talking about. We're used to thinking, in terms of making a single request to the server and having a single response to manage, that's the way we're used to thinking. Promises are great at that because it's like I wait, and then I get it back, and I'm done -- the Promise result is done.
Whereas, when you're dealing with one of the systems that is pushing things they were continuously, you don't need a Promise which is done after the first day that it's received; you need something that's ongoing. That is a way of programming to what do I do as the server could, over time, continuously keeps throwing things at me, and it requires a different kind of abstraction.
That's what Observable is bringing, and I think that's kind of cool!
CHUCK:
Yeah, there are couple of good talks that were given out on the last JavaScript conference about this. One was Jafar Husain, and I'm trying to remember because there was another one, I'll try and find it. They really kind of go into, "this is why they're there, and this is why they're powerful". They connect all the dots for you so that you can come in and go, "Okay, Observables, this is really cool!"
URI:
Yeah. I think Observables are bringing real-time communication to everyone, making everyone understand how real-time application works, exactly like you said. You talked about, we're not ending anything. It's not like a static web like it used to be that is always flowing all the time. I think everyone is talking about how Angular is educating people onto new things that are happening, and this is one of the biggest things, like let's take our applications and make them handle real-time changes. So, it's very exciting.
WARD:
So the counter to that, by the way, is that we have an awful lot of servers out there that are only are request response, and they're going to stay that way. There's a lot of things that aren't being pushed at you.
With Observables, it comes with all the complexity of figuring out how the components of those things, but an awful lot of our work are going to continue to be that REST story where we only go out to the server when we want to and we need to continue to have a simple mechanism for requesting data, waiting for it to arrive, and then doing something when it does. And, that isn't going away. You're going to continue to be able to do that even as you're also going to have these other sources like you described in the Meteor where it's pushing stuff at you.
CHUCK:
Yup.
URI:
Yeah. This is why I said people think Meteor is only about real-time, but it's just like node application, so it does the REST support, and definitely you don't want to force, stuff that real-time into real-time; it will cost you in performance and just in time. So, there's no reason not to use REST when it's the perfect reason to use this.
WARD:
Let me take you back and then ask you a question. One of the things whenever I tried to do this in the past, one of the hard design problems is, let's suppose you've got a lot of people out there listening, I'm user A, I'm only interested in certain changes coming back to me. And if you bombard me with every freaging change that's happening on the server, I'm going to fall apart; 99% of the things you're telling me don't interest me. I'll waste a lot of performance on the client-side just listening to your message arrive and discarding it.
So, what does Meteor do to help make sure that user A here is about to change as that matter to user A, and user B here is about to change as that matter to user B?
URI:
Like in any other real-time application, it's based on a published-subscribed mechanism. So, each client is subscribing only to the changes that he needs to subscribe to, and you can manage it in a few ways. If you just want to have a demo apps, you could just send all the data to the client, like you said, and all the clients will sync with all the data (and this is horrible), but it's going for just starting and building something in a minute that works and everything is great. But when you start getting into a real app, you actually write your own published functions. And those public functions are really interesting because in any other, let's say framework, in those public functions, you will have to recognize that something on the database has changed. So, we'll have to write explicit code to understand that. Let's take a query, let's take a query that you're working on the score of the 10 highest players -- you want to display the 10 highest players that score the most, but there's like 100,000 players or 1 million players. So, the query will be just like a regular Mongo or SeQueL query on a published function. But Meteor, with its package that's called "Livequery", will actually update that query in real-time, but just the contacts that you need; Meteor will take care of updating just those 10 players into you in real-time on the server. This is huge. For me, it's like the same change that Angular did with bindings over JQuery. You don't need to explicitly ask the database anything. You just write the query and it lived up to you. And then Meteor, you just write what you want from that query to publish to each client by user ID or any other parameters you want like pagination or security or whatever. And then, the clients just subsribe to the thing they want, so the client can subscribe with any way the server lets him subscribe. You only subscribe to the particular changes, and when those changes flows in to you, you get just the -- let's say the second player got 5 points more, that's it, that's the only thing you get. And it's without a lot of codes, so it's better for performance because you don't need to write a lot of code to explicitly understand what's happening. And usually, in this code, when you write this code in the server, you get a lot of mistakes, Meteor will just take care of that for you, and that's pretty amazing, I think. For me, moving into Meteor, suddenly I learned the servers are so much better than I used to before. I'm originally a C++ and a .NET developer, and it was a big leap for me to get that. I hope I answered your question.
WARD:
No! No! That's perfect. I really agree. I think many people thought that the challenge of this was "how do I just flow the data over to a client and sticking to the client-side cache". I agree that the really hard part of this problem happens on the server where it has to detect that there's a meaningful change and make sure that it tells only the right people about those changes. That is just wicked hard. And if you can make it easy for the client to express through a subscription what it is, and only what it is that the client wants to hear about and then handle the rest under the covers, that's a real amazing piece of technology. I think that what I've read about when Meteor does in that way is pretty, I don't know what the reality is, but I've read is sure good [chuckles].
URI:
I'm not the only one obviously, but I have 3 production apps before I moved to Meteor. I wrote apps for clients that are real-time and scaling and some of them works on hospitals and it works. It's pretty amazing. Obviously, I haven't tested that on hospitals the first time; I waited to do a lot of tests before. But, it's pretty amazing piece of technology, like you said. I'm still mind-blown, definitely.
WARD:
The thing that worries me now, going back to the client is, let's say I'm a user and I'm looking at thing, and the world looks a certain way and I'm in amidst of changing it, and then Meteor wants to tell me that something has changed, and I'm in the middle of work and all that, if you just go blow up everything I knew a second ago because new information has arrived, I know I want to know eventually, but that's very inconvenient for you to just rock my world with changes all the time. Is there a way in which I can write my app so that I'm aware of the information arriving from the client, but I can manage the shock to the user that things have changed?
URI:
Yeah, definitely. First of all, it depends on how you want to implement it. You can do everything. You can have that local cache and you decided to bind it into a certain scope array, that scope array, now you know, that's your one source of truth. You can do whatever you want with that one source of truth. You can work just on top of it, which means that if there would be a change, you will get it instantly and it will delete your things. But, if let's say you were in your form, just like, I think, even in the Angular example, you can just take that beta into the form, and then on the save button or reset button or whatever -- actually, in Angular-Meteor, we added helpers for you to do those stuff -then you can just, only on those occasions, you can sync the data. Only on those occasions, you will sync the data, and also, on those occasions, you can stop and say, "Show me what has changed," and then do some kind of logic. But it's something that we give helpers to give you to do that, but the client should decide what he wants to do in that terms. Out-of-the-box, you have one array that you know this is your "one source of truth" and it will always be that "one source of truth".
Now you can do whatever you want with it.
WARD:
That's the ray of hope that somebody wants to pursue; this gets to go follow. That's a great answer, Uri. I'm tempted to ask also about what the offline story is, but I'm mindful that we have filled the bucket of people's minds here. [Laughter]
CHUCK:
Yeah.
WARD:
Where are we, Chuck?
CHUCK:
My brain has melted.
URI:
[Laughs] I'll just start with a minute. This is the client-side of cache, but there is a package that's called "grunt-db" that you can decide which data from this cache will be also persistent inside the local storage. I think they also gives you all kinds of ways of different local storage to walk with, but you can just Google grunt-db. They also take care of that local storage to be synced. I think there's ngStorage in Angular, maybe something similar. So, I'll stop now, you can Google grunt-db.
WARD:
So, what's your big take away? What's our next action step from your perspective, Uri?
URI:
First thing, just try. Everything I've done on my applications, I just wrote in a tutorial. It's an opensource tutorial, I just wanted people to use it, it's on the angular-meteor.com website, it's from Step 0 to Step 20 now. It starts with nothing. I followed that Angular tutorial, which I think the Angular tutorial is great; it made me start using Angular. It gets to the point that you have a real-time search and pagination and sorting all the way to the server and handling files and Google maps and everything, and Ionic, working with Ionic framework. So, just try. Forget about what everyone is talking about. Think about how much bad stuff people talked about Angular when it just started. I feel like it's the same with Meteor. Just try. I promise you, you won't be disappointed. And if you are, my profile is public and you can start spamming me with criticisms. [Laughter]
JOE:
Nice, nice.
WARD:
Oh, what an invitation, Uri. I'll just take you up on that.
URI:
Yeah, yeah.
WARD:
[Laughs] I got to practice cursing.
URI: [Laughs]
WARD:
If everybody knows. That's terrific, Uri. Thank you for that.
URI:
Thank you. Thank you for listening to me talking so much [laughs].
CHUCK:
No, it was really, really interesting. And it's fascinating to me just some of the things that Meteor has come up with to solve its problems. And the fact that you can take advantage of that in your Angular app is just also very interesting.
Alright, well, should we go and do picks?
WARD:
Let's do picks.
CHUCK:
Alright, Joe, do you have some picks for us?
JOE:
I've mentioned this on JavaScript Jabber, I'm going to be speaking at AngularConnect this fall, and I'm really excited about that, so I'm going to pick AngularConnect just because there's no such thing as too much Angular, but mostly because, there's no such thing as too much me!
WARD:
Ain't that the truth? [Laughter]
CHUCK:
Can't argue with that.
WARD:
I couldn't get enough of you last night. [Laughter]
JOE:
I hope that Ward Bell will be there. Are you going to go, Ward?
WARD:
How can...? You called me out right here on the show.
JOE:
Alright.
WARD:
So, we'll talk. [Laughter]
JOE:
I hope you'll be there dressed as dapper as ever. So, I want to pick AngularConnect. The other thing I want to pick is that "ng-click.com" because all the time, when you want to look up something, say you want to look up ng-messages, if you just go to ng-click.com/ng-messages, what happens is, it'll redirect you to the ng-messages page on angularjs.org. Basically, it just does the tech search on angularjs.org for you, but it figures out what page you want to go. So, any documentation on Angular that you want to find, if you just browse to ng-click.com/ and then whatever your search is, it could be a phrase or whatever, it will automatically run that for you on angularjs.org. I think it actually uses Google's "I'm feeling lucky", but limits it to angularjs.org. It's just a really sleek way. There's a similar one for mdn, mdn.io, if you want to search to Mozilla developer network. But I think that this ng-click.org is really sleek. That's my second pick.
And by the way, AngularConnect is this fall, on October, for anybody who is wondering.
CHUCK:
Alright, Ward, do you have us some picks?
WARD:
I have something that I'm working on with Victor Savkin of the Angular team. By the way, Victor is one heck of a good guy, and smart guy, and busy guy. He is responsible for a lot of the databindings stuff. Some of our listeners may know, I'm on the war path to defend whatever it is that business developers think we're doing when we think we're doing two-way data-binding. They put a challenge to us to come up with scenarios that we use that require two-way data-binding and then they're matching it with examples that work in Angular 2. So, Victor and I have made some progress on that. I wrote some Angular 1 samples so that are what I think are the ranges I think are important, and he has written the Angular 2 side. We're still in the process, but by the time the show comes out, we'll have a link here to some Angular 2 samples. There's a lot of different samples there, but I think these are going to be very interesting ones for people who are interested in how to build business applications that [incomprehensible] that are important, the kind of binding we think we're doing when we think we're doing two-way binding. So, I'm going to put that into our show notes so the people can hear about it. I hope to come back later and be able to speak to it. But the hint is that what Victor has come back with this, in the way of "I throw these challenges at them" and what he seems to be coming back with this is something that's going to cover the ground. I'll have more to say on that, but the link is coming.
CHUCK:
Very nice. Alright, I've got a couple of picks. My first pick is the app that I use listen to my podcast called "Downcast". I just got a new iPhone 6+ so I put Downcast on it. I've been getting my podcast set up on it so that I can enjoy them there. I also really like the big screen so I'm going to pick "iPhone 6+".
I think that's all I've got in the way of picks this week. Uri, do you have some picks for us?
URI:
Yeah. I thought about it and the way that I leave is that I travel all over the world, and everything I own in just one bag. So, my pick is actually my bag. I'll post the link into it, but it's a really cool bag. I'm going all over the world, programming with people, and it has everything I own in my life, just in that bag. Lukas has the same bag, actually.
Another thing I'm going to add soon, I'll post a link into that, too, is to actually place a solar panel on top of this bag so I can also charge my laptop while I'm working outside.
CHUCK:
Very nice.
URI:
Those are my, I guess, very special picks. And just one pick for self-promotion is that I think, the best intro I gave was -- to Angular-Meteor for people to start and understand what it is -- is my ngvegas talk. On the talk, I created an app in 10 minutes with a camera and a mobile app and I
showed Angular 2.0 with Meteor and Angular server, which we haven't had the chance to talk to, but it's a way to write Angular code on the server with Meteor.
CHUCK:
Oh, cool!
URI:
Those are my picks.
WARD:
Well, I'll definitely going to look at those. And next time, when you're in San Francisco, look me up so I can see your bag.
URI:
Yeah [chuckles]. Cool. Cool. Thank you.
CHUCK:
I know, right? Alright, well, let's go ahead and wrap up the show. Thanks for coming, Uri.
URI:
Thank you, guys, for having me. It was a great pleasure and I'm super excited.
[This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]