 to be in the browser with Meteor. I've got a couple links up here. If you guys are interested in following along, this is intended to be an interactive demo. So if you guys have a laptop or a phone or something available, this demo will be a lot cooler if you guys interact and play along. So here's the info to the slides. There's a Bitly URL and then a SoCute URL. I find the SoCute URLs to be easier for my brain to read and remember, a little bit longer to type, but easier for me to get down. So like I said, I'm Ryan, Ryan Jay on GitHub, IRC, and Twitter. So I pretty much have that name claimed on a bunch of different spaces. And I work at Red Hat as an open platform sky. So today we're going to learn some Meteor basics. How many of you guys have used Meteor before? One or two people? OK, all right, this should be really interesting for you guys. Are you guys all familiar with MongoDB? Couple, yeah, most people. Good, good, all right. That's exactly the crowd I'm looking for. All right, so we're going to look at Meteor. Meteor, one of the awesome things that it does, awesome and scary, is it basically exposes your MongoDB interface directly in your browser. So as you open up the JavaScript console, you can go and play around with the DB, which is great until you think about security. And then you're like, what the hell is going on here, right? Anyone can access this? And so if you get a chance, see if you can hack my DB. Last time I did this demo, a bunch of people were able to inject some data. And I think my data validation rules weren't being applied. So we'll see, hopefully I have them up to the right security standards this time. And we'll take a look at how to implement that. Let's see, combine, minify, and bundle to deploy anywhere. If we have time, we'll look at deploying to other systems other than just Meteor. And here's the source code that I'm going to be reviewing today. It's on my GitHub account. I have an app called Meteor Showcase. And what I was trying to build here is basically kind of like an open app store. The goal was pretty much to build an app store for people who use OpenShift and want to do a one-click spin-up of a one-click redeployment of an existing app or one command. So we'll see that in the demo a little bit. So what is Meteor for you guys who don't already know? They have seven principles that kind of help define what specifically is Meteor, what their goals are, and what they're trying to accomplish. So I'll quickly go through these. Data on the wire. So they want to have the way their apps are architected. They have one page load at the beginning for all the web content, HTML, CSS, that type of stuff. And then from then on, they basically stream down from the server to your browser. They'll keep an open socket connection. And push down updates that happen on the server. Push it down to the client machines. And then they'll just get no SQL data arriving. And then they'll reactively respond to this new data by updating the page client side. So that's the data on the wire component. Don't send HTML. Just send data. Let the client decide how to render it. This ends up being very scalable, but introduces some security concerns, at least. One language is another one of their founding principles. And it's JavaScript. So if you're already working in the browser anyway, this is easy, same language, front and back end. Database everywhere. Use the same APIs on the client and server. This is another way they're simplifying their application development. Latency compensation. This one's really interesting. We'll kind of see how this plays out. But essentially, if you have a virtual MongoDB in your browser and if you attempt to do a write locally to your browser's MongoDB, then what happens in order to make sure that that update happens right away on your screen? Your browser's MongoDB will apply the changes, act as if it just accepted some new JSON data from the server. And it'll update your DOM or your web page as a result of this data. And so it looks like the data appears, the changes appear in real time. And so it kind of preemptively updates the page before the update has actually succeeded on the server. And so you may end up in some cases where you do an update client side and then the server ends up rejecting it. And so your page has this latency compensation to try to proactively change it. And then that change gets backed out. So it works pretty well. It's kind of a cool feature. And it helps everyone's pages feel really responsive and snappy. So yeah, we'll see what that looks like. Full stack reactivity. Make real time your default. All layers from the DB to the templates should have an event-driven interface available. And embrace the ecosystem. This one is really important for me as someone who works with a lot of open source communities. This is really critical, is working with existing communities. Meteor has done a pretty good job of this. But I think there's still some room for improvement. And we'll see kind of their package manager is kind of like their own separate package manager that's separate from the rest of Node.js's packages. And that creates some kind of conflicts. Because which source do you go update? Which one do you bug patch? Which one do you maintain? They're not really working with the rest of the upstream community. But that's kind of because they have a little bit of a different product they're building here. So yeah, open source and integrates with other frameworks is one of their goals. And the last one, simplicity equals productivity. So the best way to make something seem simple is to actually have it be simple. And Meteor is definitely really nice and simple to work with. I have two or three source files. And that's it that we'll need to work through. So OpenShift is open source. And if we have time, I'll go into a little bit more about OpenShift. But it's a Red Hat product. We do application hosting. You can host your Meteor applications on OpenShift. You could also host anything, Python, Ruby, JavaScript, PHP. You could do Postgres. You could do MySQL, MongoDB. I think we have an experimental Redis package available. All kind of like a Heroku style, really fast deployment, get push for deployment. So really clean interface. And it's all open source. So you could run OpenShift in your own data center. We also have a free plan. You could host three apps on us long term. So it's a cool thing to check out. If we have time, I'll cover some of that. OK, so let's look at some code here. I'll open up this Meteor showcase link. I'm actually working on a substitute laptop here. My other laptop had some problems connecting. But here's the source code we have here. So the CSS file is basically empty. There is some CSS that my application has. But most of it is handled through a package that I installed. So I did a with from the command line. Geez, open up another one of these guys. OK, so from the command line, and I'm missing some of the commands here, because I'm on my alternate setup. But you type MRT, and then you could create an application. And then once you have the app created, you could do MRT add and then add one of their smart packages. So I added things like jQuery. I also added they have a package for bootstrap. And so that's actually where all my CSS is. That's why I have an empty CSS file, is because I added this module to handle it for me. MRT is a command line tool, it's called Meteorite. And that offers kind of a super set of the packages that you'd get from just the Meteor command line tool. There's two different command line tools. Meteor, it kind of gives you a static release of MeteorJS and allows you to install maybe like 10 core packages that the Meteor team maintains. And then Meteorite actually gives you a lot more power on top of that, you can select different run times of Meteor and say I want to run the develop branch or I want to run this specific release. And you also have access to a lot more packages from a package management database called Atmosphere. So more available with this MRT command. So yeah, like I said, this Meteor showcase is empty. Here's what my HTML file looks like. You could see there's some kind of handlebars style injection things here in the page. The body element is like really small and it basically has a stub for navigation, a list of data, and then I have three separate forms here. A submit form, a kind of a detail view and an edit view for each of the objects in the list. And so that's about it. Then there's a couple other templates down here. There's a template for the list view and so that'll get injected up in that area where it says list up above up here. All of this content will be templated into this area and all of this item here is basically going to go into this item in the list. So if you've used handlebars before for client-side templating, this should be familiar. It's a very simple way of injecting data in here. So here I have a variable called date string and then another variable called author and we'll see how these get defined on the server side. OK, let's back up a page here. Last one I want to show you and we'll see some better examples is this JS file. In fact, I'm going to flip back to the slides because I think I covered a little bit better here. But now you know where the code is. OK, so in that big JS file there's basically, this kind of breaks it down and simplifies it for you guys. There's a big block of code that says meteor is server and then another big block that says meteor is client. So anything you want to have protected, that's like your data validation, you put it in that is server block. That stuff stays on the server side and does not get revealed to the client browser instances and everything you want running on the client, you just put inside that is client block. That's pretty simple. It's all just one file for all of your JavaScript code. So super simple. Here's how you would protect your DB access. I have a collection of data called showcase. I should have picked something that was a plural and a singular. I just have one showcase with many items. Items is too generic. I need a better variable name for these. But anyway, my data collection here is showcase. And then on that collection, I want to allow certain operations. So I have a remove operation here. And so who's allowed to remove? This is basically going to be, like I said, with that latency compensation. There's going to be someone who's going to try to do a remove operation in the browser. And it's going to succeed in the browser, but then it's going to get shipped up to the server. The server is going to actually decide, does this actually meet our validation test? And am I going to allow this change? If the change is allowed, it gets broadcasted back out to all the connected devices. If the change is denied, it basically returns false and then a message gets sent back to that one browser that did the latency compensation and accepted the change kind of proactively. And that guy gets rolled back. So that's basically how it happens. And so here, I default a username to false. And then I try to look up this user and see if they have a profile name defined. I'm actually using a plugin for Meteor called accounts. And then there's another plugin called accounts-github. So I have a login with GitHub on this app. If you're interested in seeing a live version of this app, you could go to appstore-appstore.meteor.com. So here's a live version. This is the one. So if I go in here and I say this sketch board, I think this is a great app. I want to upvote it. So I'll upvote it here. Instantly, it changes. There's some data validation on the server side. Do I have access to change this data? We'll look at that validation role next. So yeah, in order to remove something, you basically, in this code, the validation is if you're the owner of that data, then you can remove that data. Or else you're not allowed to delete that list item. Anyone who logs in to an account, that's my insert validation. Do they have a user ID? If they have a user ID on the server side, I know they're authenticated via GitHub. And so I'll allow them to insert some data. That's my only protection. You could integrate with your own authentication system or have some additional checks here. It's pretty easy to add additional validations as needed. Last one's an update. And I actually moved that over to a different slide. So my update rule is pretty interesting. I wanted anyone to be able to upvote an item without logging in. So I have kind of three different levels of authentication here. Anyone can upvote or downvote a particular application in this showcase. And only the owner can delete them. And then the administrator, which is basically my GitHub user ID. I hard-coded that in here. It's kind of a sloppy demo, but it shows kind of three levels of anonymous access, authenticated access, and then an admin level access. All done kind of on the server side. So here's some validation rules I have for update. It's going to find my username. It's going to check this item that I'm trying to update. If I'm trying to move the score over 9,000, it gets rejected, right? 9,000 is the ceiling for my showcase, right? I also check, let's see, the first one here I log out. OK, this is just a voter. Anyone can vote. That's OK. If they're incrementing the score by 5, so you could see this modifier here. If I'm incrementing the score by exactly 5, then we'll allow the operation to succeed. So I could go into the JavaScript console and actually take an object, increment the score by 5, and then save it back to that DB right in the browser console. And if it's exactly 5, it'll work. If I try to update it by four points, then it'll get rejected. So really interesting validation there. I also allow you to vote down by exactly 5, but you can't go below 0. Also, if the username is Ryan, you could do whatever you want. You could probably change your GitHub username to Ryan and hack this pretty easy. But it's a proof of concept. And then the last one, if you're the item author, you're free to edit. So templates, we took a quick look at this earlier. Here's that list view with items being injected. Here's the actual item source. We're dropping in a description, time string, author. And we'll look at the JS side of this. It's going to be injecting the variables in just a minute. And here's the overall main template for the page. That's about it. OK, so for that list of items, we basically do a couple things here. There's a session variable that I have that shared across all the browsers. It's called sort by. And so if I flip back to this demo, is anyone else on the demo page here, one person? OK, so if I put the sort order on rating up here, your page should update to sort by rating as well. If I click on rating again, I could do a reverse sort. And if you click on rating, it should update my browser. There should be anyway. If anyone else is on this page, that's basically the effect is a real time. The more people who participate, the more fun the demo is, like I said. But basically, the sort order, anyone can change the sort order, any connected browser, and it'll update live. So I could try opening a second tab just for the sake of a demo. Let's open up one more and take it out of full screen mode. OK. So this guy, just so we could see what it looks like, is appstore.media.com. And then so this guy, I'll switch to sort by rating. And then, ooh, is that not working? Latest? Yeah, replication, it's not getting, it's not broadcasting out. Huh, ooh, bummer. That's like the core of the demo right there. OK. Well, let's see if we can take a look at the JavaScript console and at least do a query in here. Let's see. Anyone know what the, OK, here we go. So if we go to console, can you guys read this console here? It's a really small font. I don't know how to increase the font size in the console. Oh, here we go. All right. Let's see if I can make that bigger. OK. So I am going to type in db, db is not defined. Should be a db object. It's on the meteor object, meteor.db. Let's see if I have that in my slide somewhere. Back over here. All right, I think I have a command for that later. Oh, here's a bunch of click events that I have on the list. So for someone who's looking at the list, if they wanted to open up one of these things, they could double click and then say, spin me up an etherpad. I want an instance of this running now. And one click, they could go spin that up. So, yeah? Oh, OK, good to know. Well, I'll switch my sort by rating. If you want to upvote or downvote etherpad, we should be able to see it. Oh, there, some reveal.js and sketchboard just swapped positions. So sort by seems to have some issues. I just updated to a new version of Meteor last night, which is probably a bad move. I was on version 6.3, and all of a sudden I'm on version 6.5. And so I tested some of this, but I didn't actually test multiple browsers with this. There we could see a couple more things. I'm not, look, no hands. I'm not changing this. Someone else is changing it. They're voting quake up really high, right? Yeah, cool. So now we at least know something's working here. And that's all based on these click events, right? They're doing click. There's a A tag. And if you hit A tag with an increment class on it, then this action gets fired off, right? And it's doing a showcase.update. Actually, let me see, is that the right syntax? Is it showcase.find that I'm looking for? Let's see about that web console. Showcase, yeah, here we go. Showcase.find1, and here's an object that we have back. Can you guys read that? We've got an object ID and authors. It looks like this one's community maintained. There's a demo URL and a score, which is currently 25, right? So we could actually save this object to a variable and then go inspect that variable. Look at the data attributes on that. A dot score should have this one's got 75 and then I could set this equal to 80 and then try to save it back to the DB, right? So that's essentially what you get right in the browser client side. Okay, about five minutes left. Let's see, here is basically the packages that I use that I mentioned earlier. The why the CSS file is basically empty is because I've added a bootstrap. I'm also using underscore. Previously I had accounts. Now it's called accounts base. That was a change I learned last night, right? Accounts.github is the other and I'll show you right here. I'm not logged in currently. I'll hit login should authenticate against github here. Okay, thank you. And now here I am logged in via github, right? So now that I'm logged in, I actually have an edit button here. There's a settings and then I could go in and I could say, okay, I know I could only change the score up and down by five. I'm gonna change it to 81, right? So I'm changing it by six this time. So that succeeded because of my user ID, right? If I were to take one of the other variables and now it's at 101. Okay, so that's still going up by five at a time. Last demo I had someone basically insert a bunch of applications that were like, hey, this kind of works. And that was the application name. So it looks like I don't see any new apps. It looks like all the client side interaction is working within the kind of validation rules that we have set up, which is good news. A couple of packages that are really great for experimentation, but also really dangerous. There's a package called Insecure and a package called Autopublish. This makes it great, you know, awesome when you're just starting out with Meteor and you wanna make sure you're sending data back and forth across all these environments. But those are two packages that you're supposed to remove eventually after you get your security models in place. And, you know, these are called smart packages. I know a lot of the Node.js community would say, hey, why do you have your own, you know, proprietary package management system? And, you know, are you going to be able to maintain a community long term with your own fork of a, you know, like that's, I think, an honest concern for some people. But they're making a lot of progress. The Meteor team's doing a lot of really awesome stuff. The deployment with Meteor is super simple. You create an app and then just type in Meteor deploy if you wanna deploy to their hosted service. That's something they offer. If you were interested in taking your Meteor code and then running it on your own server somewhere else, you could either just type in Meteor if you wanna run it in a development environment, which is really cool, the way it works in development. I could go into one of these templates, change the layout of the page, and the server will push those HTML and template changes down to the client and update the whole DOM just like it does with data changes. It'll actually push HTML changes down the wire as well. That's only in development mode. That's not in a kind of production mode. But it's great for fast development where you don't have to do check-ins and you could kind of experiment on the fly, get a lot done in a really short amount of time. This bundle step kind of locks you down to here's my release. This is what I wanna ship. This is going to a production environment. And if you wanted to send it out to an OpenShift environment, for example, I have some notes and a blog post on how you might do that. You basically take this bundle and overlay it on top of this Meteor Quick Start that I've made for OpenShift. So that would assume you've done something like RHC app create the name of the app and then you list your dependencies here. So for OpenShift, I'm gonna depend on Node.js and MongoDB, and I'm also gonna say, hey, I want this Meteor Quick Start code to be added in as kind of a, this is basically a wrapper that just sets the right port and IP address and the Meteor connection to MongoDB. That's really the only three things that Meteor needs to know. And so this wrapper is really tiny. Basically just sets those three variables and then refers to the bundle for the rest of the work. I'll skip over this stuff because I'm running short on time. But does anyone have any questions about Meteor? Got one here? Yeah. So Meteor is pretty tightly coupled with MongoDB. You can't use it with other data stores. It's pretty much that one NoSQL option. And Meteor basically is some Node.js code and some browser side JavaScript code that talks to Mongo and basically exposes kind of a virtual MongoDB interface in your JavaScript console and for any JavaScript application development. So that's kind of how it all fits together. But like I said, pretty tightly coupled to MongoDB. If you were interested in using a different NoSQL solution, you'd probably have to look at one of these alternatives like AngularJS. Angular does a lot of the same things but much less work on the data management side. You can have it set up to automatically update the DOM but you have to have some other hook or trigger that you code yourself. But you could definitely use Socket.io and MongoDB and then pipe down information and get the same type of effect with Angular, Ember, Hooties, a really new one. And LevelDB is another kind of alternative where I've seen people using LevelDB you could actually run a real LevelDB instance in your browser and on the server and you could set up real replication back and forth between these. I don't know if they've worked out all the security issues or if they've gotten as far in securing it as Meteor has. I think Meteor's a little bit ahead of them on security currently. For more information, Meteor's got great docs. Check out Meteor.com. There's a lot of great demos there and sample applications. And I've got a blog post as well. I think this links to it here. Yeah, this fireball should link to my, links to something. Yeah, oh, here you go. So this is my blog on using that Meteor Quick Start if you wanted to deploy somewhere else but really that just Meteor deploy, you can't get much simpler than that, right? So that's about it. Let's see, is there any other questions or does that cover it? I think I'm done at 10. One more. You know, I haven't used deployed. I've been, like I said, I'm with the OpenShift team. We have a really smooth deployment model that works for pretty much any. You could use it from Windows, from Apple, from Linux. I do all my work from Linux. But I know, deployed sounds interesting. I'll have to look into that. Yeah, I know Meteor's a little bit, they say they wanna work with everyone but then they have this awkward kind of bundle step that I wish was a little bit smoother. So yeah, yeah, it sounds like a cool suggestion though. All right, cool. Well, thanks guys. Thanks for listening.