- Valeri Karpov (twitter blog github)
- Ward Bell (twitter blog github)
- Joe Eames (twitter github blog)
- Jamison Dance (twitter github blog)
- Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)
01:25 – The MEAN Stack
05:21 – Concurrency
12:49 – Express.js
14:48 – Working Within the MEAN Stack
- Mongo and Node
- Code Sharing
- Validation Logic
28:40 – Using Angular
34:40 – Hosting
37:37 – Deploying MEAN Applications
41:40 – Memory Management
47:42 – Resources
- Risk of Rain (Jamison)
- Joe Eames: Pluralsight Courses (Joe)
- The Legend of Zelda: A Link Between Worlds (Joe)
- Disneyland (Chuck)
- New Media Expo (Chuck)
- Valeri Karpov: The Code Barbarian (Valeri)
- The Book of Five Rings by Miyamoto Musashi (Valeri)
- Breeze.js (Ward)
- ng-conf (Ward)
- Angle Brackets (Ward)
- Her (Ward)
CHUCK: Dude, I see a picture of you wearing a suit.
VALERI: Yeah. I’ve been known to occasionally wear a suit.
CHUCK: I’m sorry.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]
JOE: Hey there.
CHUCK: Aaron Frost.
CHUCK: Jamison Dance.
JAMISON: Howdy, folks.
CHUCK: I’m Charles Max Wood from DevChat.TV. And this week, we have two guests, Valeri Karpov.
VALERI: Hey guys. What’s up?
CHUCK: And Ward Bell.
WARD: Hello everybody.
JOE: Chuck, aren’t you going to check that you pronounced the word Bell correctly?
CHUCK: Ward, how do you say your name?
WARD: I say it [in Italian accent] Ward Bell.
CHUCK: Grazie mille. Alright. So, we brought you on to talk about MEAN development or the MEAN stack or whatever, I guess they call it a couple of different things I’ve seen. So, MEAN stands for MongoDB, ExpressJS, AngularJS and Node.js. So, what is it about this particular stack that is so appealing?
JOE: Besides the acronym.
VALERI: The acronym is very pippy. And I credit the acronym for giving it a lot of its buzz.
CHUCK: You should have called it AMEN, AMEN stack.
VALERI: People actually have suggested that. But on the other hand, I don’t know. I don’t think AMEN would be as pippy.
VALERI: MEAN has a little bit of attitude to it and I kind of like that.
WARD: And you know, we threw a B in front of it to put Breeze on it, so we call it B.MEAN.
VALERI: Yeah, there’s also MEANS with Sails, a couple of other spinoffs that I’ve heard. It’s [chuckles] oh man, it’s fun.
CHUCK: When I did the Google search, it came back with Mean Girls.
VALERI: Oh man, that’s an SEO fail.
VALERI: Need to work on that.
CHUCK: Well, that’s what you get when you just google MEAN instead of MEAN stack or MEAN, anyway.
WARD: Have we said what it stands for? Because there are other people poaching on it, too.
CHUCK: Am I looking at the wrong MEAN? I said Mongo, Express, Angular, and Node.
WARD: Ah, but I just saw somebody do one where they substituted MySQL for the M. So, I thought we should say it explicitly.
CHUCK: I just want to apologize people for their own lives if they’re using MySQL.
VALERI: Oh man, 2006 called and wants its technology back.
CHUCK: Oh, man.
VALERI: Not to hate too much on MySQL. It has its uses, but I mean, no pun intended, right now I definitely think that MongoDB is the better general purpose database out of the M’s, MySQL or MongoDB. Again, the thing that really got me on to MongoDB, just getting started right off the bat, was there are plenty of other database products that I had used and none of them were just quite as simple and intuitive to me as MongoDB.
What I want to do with a database, I want to be able to go in, I want to store something, then I want to be able to query for it by whatever I just inserted. And with MongoDB, it was just like, “Oh, okay.” I just download a tarball, I unzipped it, I ran a program. And all of a sudden now, I can start inserting things. I haven’t had to go set up a table. I haven’t had to install anything. It just let me get started and basically got out of my way, which is the mark of the best products, I think.
CHUCK: Yeah, I tell people, I have clients come to me and they’re like, “So, I keep hearing about this NoSQL thing. And since my product is going to have a million and a half users on it, I need to use MySQL.” And sometimes MySQL lends itself very well to their problem and sometimes it seems like a relational approach would work better. Of course then, I’d put them on PostgreSQL. But I think it really just depends on your problem domain. I think in a lot of cases, it doesn’t matter because you’re just putting stuff in and pulling it out. But yeah, I think there’s a place for both paradigms and it just really comes down to what you need and what you’re familiar with.
JAMISON: That’s your answer to everything though, Chuck.
CHUCK: Yeah, I’m a consultant, so it depends.
JAMISON: You sit squarely in the middle.
CHUCK: I really like both. So…
VALERI: Oh, funny how consultants and some SAS people are similar in that regard. And well, disclaimer, I currently work for MongoDB. But that is also my opinion as well as the company’s opinion, that MongoDB is awesome.
CHUCK: No kidding.
VALERI: Since the disclaimer, anything I say on the show doesn’t reflect my employer’s opinions necessarily. But also, I’m not necessarily speaking on behalf of MongoDB here. Just wanted to get that out there.
WARD: Yeah, I think that’s important because while I really appreciate your enthusiasm for Mongo and I have enthusiasm for Mongo, I think we need to explore the reasons for the choices around that and to recognize the challenges that you face when using it in certain kinds of more traditional application environments. I know this is all, “Let’s all get enthusiastic about the MEAN stack,” because that’s worth doing. But losing our heads about it [laughs] maybe we don’t want to do that.
CHUCK: Yeah, I do have to say though, that having the MEAN stack for example, having something where it’s, “Look, here is a stack that we know works and here are some practices that you can use that work well with it and here are some frameworks that hang together nicely,” there is definitely some advantage to that. Because there are a lot of people out there then using the same tools for the same things and the entire stack benefits.
VALERI: Yeah, absolutely. The more people use it, the more tools are built around it and the more useful it becomes. It’s one of the interesting things that people see, coming back to the database space in that you can sit around and argue that CouchDB or MySQL or Cassandra are better for certain purposes than MongoDB and you might actually be 100% correct.
But the big advantage of MongoDB, at least I feel, in addition to the fact that it’s a very simple product to use is that there is a huge community around it. And basically, we actually have engineers that are — or we have support rotations where people spend their time going around answering Stack Overflow questions. So the community is there. The support is there. And the tools are there.
VALERI: And I think that that makes things a lot better. And I hope to see that, the same community building up around the MEAN stack.
WARD: Yeah, I agree with that.
JAMISON: I think an interesting thing to consider about talking about technology choices in general is how much of it is we pretend like we’re making the objective best decision, but it’s really hard to have perfect information about both what your problem is actually going to be and what the technology is actually going to do when fit into your problem. So a ton of our talk about how good things are as rationalization is backed by emotional things.
VALERI: But you can think of some pretty objective advantages. But again, you can’t have perfect information, but there are certain things like, “Oh, if I’m building a web application, at some point I’m going to have to introduce some complex concurrency. I’m going to have to have say, I’m going to have to do a csv dump of my data 12pm every day. So, the analytics guy can sit around and play with it. Or I might need to do say, n concurrent requests to Facebook to get to, I don’t know, to deference some data pointers or something to that fact and get some location information. And if you want to do that, that’s really where Node.js shines where you can come in and just do this very sophisticated concurrency in an event-driven format.
And event-driven code really makes a lot more sense to me in terms of how the concurrency is managed simply because you don’t have to worry about being interrupted at any given time. You don’t have to worry about guarding things with locks. So, it makes that sort of task of building out sophisticated concurrent programs a lot simpler. And again, that’s one of the things that I’ve seen the MEAN stack really have a good advantage over more older and more developed web development stacks, say a full Ruby on Rails stack or something to that effect. [Crosstalk] just that concurrency is stupidly easy.
JOE: That’s interesting, Valeri. You know, I say most people jump over to MEAN thinking, “Hey, either I’m doing Rails or I’m doing something else and I want to try that’s a little bit more on the edge, maybe.” And so, they jump over to MEAN but they’re probably not thinking from a concurrency standpoint. Most apps aren’t really like, other than scalability-wise, for concurrency you’re not thinking about, “Oh, I need to be doing something crazy concurrency-wise,” so you’re not necessarily driven over to that stack because of that. Would you agree with that?
VALERI: I would agree with you there. It’s not something that people think about when they first get started. It’s not something that I thought about when I first started building my first MEAN stack application. It wasn’t exactly high on my list of priorities. But as the applications evolved, I started to see, “Oh, it would be great if I could do this, that, and the other thing,” always just adding one more thing, maybe things like, “Oh, I want to be able to notify the administrator every time something happens but I don’t want to slow down my response times for that.” So, I just want to handle that asynchronously after I’ve returned everything to the user already.
And where this really clicked for me as MEAN stack as just a tool for making a very concurrent web server came from when me and my roommate actually started doing Bitcoin arbitrage. My roommate came to me in March and just told me, “Oh, there are all these Bitcoin exchanges and the prices are just so wildly different that the math works out where a few times a day, we can execute some trades and make some decent money.” And so, I sat down to do that and I just wondered how can I do this? Oh hey, why don’t I just use Node? Node is really good concurrency, right?
And then basically within an hour, I’d gone from nothing to basically just throwing out live trades, mostly because I can listen to a Socket.IO stream here, I could ping a REST API there, that all comes together seamlessly. And oh by the way, I have a web server running on top of it powered by Express so I can serve up whatever price analytics and history of trades and all these things right from my browser. And as somebody who had just left their job at a high-frequency trading firm, this just blew my mind because I had just come from a job where basically we had huge teams of people getting paid exorbitant salaries to do pretty much that.
CHUCK: Now I want to ask, I’m going to redirect just a little bit here. I’m pretty familiar with what MongoDB is about, what Angular is about, and what Node is about. I don’t think we’ve talked a whole lot about Express. Can you talk about what that gives you on top of Node?
VALERI: I would say that the biggest advantage of Express is again, it’s a product that gets out of your way and lets you access Node. But it gives you on top of Node a very simple framework for building up a RESTful API on Node.js. So, a Node server without Express would make things a little bit more difficult where you would have to define your routes, you’d have to be able to go in and pull various things from HTTP headers, take care of parsing that. Whereas Express gives you a nice little framework for thinking about things in a modern MVC web framework fashion. The framework is based on Sinatra, which is a Rails competitor, basically a Ruby server MVC framework.
CHUCK: Kind of. Sinatra’s not really MVC, but it is a very lightweight way of managing web applications.
CHUCK: And you can definitely add the model component to it.
VALERI: True. The M is explicitly missing from Express. Yes, you’re right. But the M, you can add on yourself. It’s relatively simple.
VALERI: The big advantages it gives you, the framework for writing a function that takes in an HTTP request and outputting an HTTP response without having to necessarily deal with the ugliness of setting up all the correct headers, computing the response length, various things like that.
JAMISON: So, we talked a little bit about why if you’re using Node, Express is a good decision. We talked about why Mongo could be a good decision. Can we talk about why Node is a good fit, or why Mongo is a good fit for Node vice versa?
CHUCK: One thing that comes to my mind is that the document is, at least for the most part, very comparable to a JSON object. And so you can take an object, probably less any functions you have on there, and put it into Mongo fairly straightforwardly.
VALERI: The shell helpers?
CHUCK: Yeah, well…
VALERI: It’s one of the ways we call just the query language, do you know what I mean?
VALERI: Although putting on my MongoDB hat, we don’t recommend that you do server eval…
JAMISON: Oh, yeah.
VALERI: Where you’d send eval in your queries. You can do it, but we recommend that you don’t. And probably 99.99% of the time, you don’t have to. And yeah, unless you really, really know what you’re doing, the answer is no, don’t use it.
JAMISON: Yeah, I think I’ve done it once in a couple of years and it was just exploring on the command line. You don’t want to expose your server to cross-site scripting. I don’t know. [Chuckles]
WARD: So stepping back…
VALERI: One of the funny things that you end up with when you’re in the SAS base is the realization that if you include a feature, somebody will find every possible way there is to use it incorrectly. So, eval ends up being one of those things where people just try to use it and get shot in the foot.
AARON: Yeah. They’re crying right now.
JOE: Not only that Jamison, but what is the payoff for getting to put a single, getting probably a vast look of your developers if you’re doing MEAN stack at your shop, only working in one language across the board? What’s the payoff there?
JAMISON: Well it’s not sharing code, because that is a pipe dream.
VALERI: Oh, there is a lower barrier to entry in terms of understanding the codebase. You don’t necessarily have to look for somebody who can be like, “Oh yeah, of course I know Go and C++ and Ruby and all other things,” in order to be able to balance you codebase, especially if you’re a small company where you only have maybe a handful of people. You would like it to bring on people who can understand everything front to back. And that’s one of the advantages, I guess from a business perspective.
WARD: They do work fine, but you still have impedance mismatches at the connecting points. And that’s one of the things that really pop out at me whenever I work. I work in all these different stacks, right? But the thing that pops out at me when I work in what we’re calling the MEAN stack and with all of its intended tools, Grunt and so forth, is how at the points at which the different layers meet and the tiers meet, you’re not translating from one representation to another. Well you are, but you know what I mean. You’re not changing. You’re not having a technology transfer.
So, you’re not dealing from say a static type like the way the customer is structured in a statically-typed language on the backend and then saying, “Well now I got to turn that into JSON and then I got to rehydrate that back on my client as something else.” And those things go away. And the other thing that really pops out at you is that the cycle, the development cycle, you iterate completely around that, from spinning up the backend to developing on the frontend and moving back and forth, it just feels comparatively frictionless. And that just isn’t true when I’ve got a different technology that I have to spin up in the backend.
For the most part, you can use the same tools. Yeah, you can’t share code, but you have all of those other things going for you. So you don’t have to change environments. You don’t have to change the mindset on the tools. You don’t have to handle as many of the differences between the two languages and the way that their virtual machines work. But at the same time, you do have to be able to keep in mind that Node.js is not the same as the engine that’s running in the browser. And there are going to be some mismatches that happen there. It’s just that the mismatches aren’t at the linguistic and syntactical level.
WARD: I’ll throw another one into the pot, which is the validation logic. Obviously, your final validation logic needs to be on the server. But it’s very helpful to user experience when you can project that same validation logic onto the client. And if you have simple things like the order date has to be before the ship date and stuff like that, these little things that go on, and it’s really nice to be able to move some of these rules around or have them execute in both sides.
So, I’m not minimizing the differences on the two sides. What I’m saying is that the points at where they come together, they come together in a much smoother fashion. You’re dealing with structural types at those boundaries and types that you can monkey-punch. And all of these things make it just easier to move back and forth as a developer when you’re trying to write an application on both sides – the client and the server – at least in my experience.
WARD: I would prefer to factor it so that there’ll be some that’s purely server-side. But I would factor it in such a way that, that’s the value is that I would be able to literally reuse the code.
CHUCK: Yeah, I can definitely see that and I identify with the opposite. I worked with a company that had a Ruby on Rails backend and a Flash frontend. And the two really didn’t mix. And it would have been nice to be able to have the frontend guys speaking the same language as the backend guys. And there’s a definite advantage there.
VALERI: A lot of that down to, well at least for the Node space, that comes down to the advantages of the Node package manager, npm, which is one of the things that makes the MEAN stack really shine, in my opinion, is the 50,000+, as of a couple months ago it’s over 50,000 npm packages. Again, npm has its own problems, but the things that they do right are things like all I have to do to get started with using a repo, it it’s a well-written repository, is I clone it off of Git, I go in, I run npm install to install all of the dependencies, I run npm test to test it, and now I could go in and start tweaking it. I don’t have to go in and start finagling with my binary path. I don’t have to really go around and set up proper build tools or set up a different source control tool that I don’t necessarily use, like having to install Go from source via Mercurial, which is a pain.
VALERI: It’s a huge advantage to being able to lower a barrier to entry from “I don’t know anything about this repo” to “I’ve taken it down. I’ve installed everything I need to install and I’ve run all of its tests with basically three lines of code, or three lines at your favorite command line.” It’s pretty damn cool.
CHUCK: So, I want to get into another holy war that I see periodically and that is you picked Angular over say Ember or Knockout or any of the other dozen or so popular frameworks out there. Was there a reason besides the acronym that you did that?
And well, from there when I got started with Angular, I had come from basically just using jQuery. And that wasn’t quite cutting it in my use case. So I got started using Angular very, very early, did some personal bug fixes while I was getting started. So I’m very, very familiar with Angular and it’s the way that I think about things. And in all the time that I’ve used it, I have not really seen the necessity to move off of it.
I’ve tried Ember. I’ve tried Knockout. And they haven’t upped the bar enough from Angular for me to move off to something else. I don’t necessarily have any real pain points with Angular when I’m using it. It’s just a library that does pretty much everything that I’ve ever wanted to do on the UI side and then gives me suggestions for what I could to, things that I hadn’t thought of. So it’s extraordinary. And I have a lot of experience with it and that’s why I put it into the acronym.
WARD: Well, I have used the others and I actually have a pretty high regard for not Knockout [inaudible]. I think of Durandal as being an equivalent. It’s more than just data binding and Knockout is about data bindings. So when I look across the choices that you have for a presentation framework, I think that the others are worthy. But the thing that people are finding really attractive about Angular is that it doesn’t lean on observability in order to know what’s going on when it’s doing its data binding.
I think that’s the really distinguishing feature as a developer. And the consequence of that, you may say, “Well what the heck does that mean?” The consequence is that when I get that object from Mongo coming over, I don’t have to transform it by making each of its properties observable in order to make it bind. And just taking that whole business out of the equation makes it a much easier introduction to wedding your presentation framework to whatever’s going on in the backend. It just seems like the writing of the code is less, you don’t get trapped into morphing the JSON coming in in order to make it presentable. And taking that out is the biggest thing. And I think that’s one of the reasons that Angular really won.
Now, it just so happens that it’s also beautifully written, as you say Valeri [chuckles]. And it has the wonderful testability features and it has the built-in dependency injection and all these features that as a long-time client developer in technologies like Silverlight and C# that I would expect when I’m trying to build a single-page application that is heavy in client-side execution. And they’re all built right in and they drop out of the box. So Angular is a great choice. It’s not the only choice, but it’s a great choice and I think it fits right in.
VALERI: [Chuckles] I guess the question that we need to ask is, “Will it bind?”
VALERI: Oh no, that’s actually another very excellent point about how, and something that I’d like to harp on a little bit more where the fact that you can basically just take an object immediately from your JSON, immediately from your server, and you don’t need any extra work to glue that to your user interface is extraordinary. And probably one of the biggest advantages that I’ve had is that again, as somebody who’s worked for relatively small companies for much of my career, I have seen that basically whenever I have to interface with a designer, I want the designer to have as much autonomy as humanly possible. I don’t want to have to go in and micromanage and tweak their jQuery or something to that effect.
CHUCK: Yeah, there are definitely some nice things about Angular. I’ve played with Ember and Angular and I tend to lean more toward Angular myself. I have one more question and that is, and this is something that I hear about most technologies that are not PHP, and that is that the hosting story for PHP is really simple. It’s usually installed just about anywhere you want to host, on shared hosting, on most servers. All you have to do is put your PHP app up somewhere and then point Apache or Nginx at it and it just works. Do you see MEAN becoming mainstream enough to get to that point as well? I know that there are, and I guess this is a question more along the lines of Node or maybe Express, but you know, is there a simple hosting story for MEAN or Node?
VALERI: I’ll take this question first, because first of all, as somebody who has had experience dealing with Apache, you make it seem like dealing with Apache is very simple.
CHUCK: I did gloss that, didn’t I?
VALERI: And I’ve heard of people who, their fulltime job is managing Apache config files. It’s not an easy thing to do. The advantages with running basically MEAN or everything on top of Node is essentially all you have to do is install Node. That’s it. You install Node, you run your test, and then you basically just run a Node process and point it to your main file. And there you go. You have a web server. You don’t necessarily need Apache or Nginx or any of these other things. It makes it considerably simpler.
And as a matter of fact, actually if you all have heard of DigitalOcean, which is an EC2 competitor that gives you SSDs and serve high-performance hard drives on your instances, they actually now have basically an instance that comes prepackaged with Mongo and Node in a MEAN stack setup, which is very cool. It takes you from having to, saves you the effort of having to actually go through all the effort of having to go sudo apt-get install node. Well, saves you one line at the command line, which is [chuckles] great I guess. But yeah, I think that’s one of the advantages of the hosting setup, is it’s already very easy if you’re on an Ubuntu box or a Mac box or even a Windows box, it should work. And if you want to make that even easier, go to DigitalOcean and spawn up an instance with them already installed.
CHUCK: Yeah, I [inaudible]. DigitalOcean is awesome. I love those guys.
WARD: And all the cloud providers make it easy, so why waste time with that if you just need a server? Just pop it up there. Or I guess the answer to that is if you’ve got an internal application. But it’s pretty easy in the cloud and it’s pretty easy on your box.
CHUCK: So, one other question I have then is if you deploy more than one MEAN application to the same server, do you need something like Nginx or Apache then to proxy that and say this domain goes to this app and this domain goes to the other app? Or is there a way to work around that?
VALERI: To the best of my knowledge, I don’t have a good answer to how to do that. You might need Apache and Nginx. Again, you can make them listen to different ports. But Ward, feel free to chime in. I don’t have a good answer beyond that.
WARD: No, I don’t know how it differs from other situations. You spin up a different endpoint, you spin up another. Yeah.
CHUCK: Yeah, it’s not that different. I just didn’t know if Express or Node gave you that kind of an option where you could configure it and say, “I’m running two applications on the same VM,” or something like that.
VALERI: I would imagine it is in some way possible, but I have never actually done it so I can’t actually say.
CHUCK: Yeah, I think the common practice is yeah, to set up Nginx or something and then just tell it to proxy back to another port. And so, effectively, it’s just routing based on domain name.
VALERI: And that all still brings me back to another interesting point about the MEAN stack and one of the paradigm shifts that I’ve seen in my coding in that particular realm, is with other web frameworks I’ve used, I’ve had often a tendency to basically things start spilling off into multiple processes pretty quickly. You start having to set up cron jobs. And god, I hate setting up cron jobs. They’re such a pain.
VALERI: I have a different process doing Nginx. I have to worry about my memcached, all these other processes. And with the MEAN stack, I’ve seen that, “Oh I can basically, why would I use a cron job when I can schedule things internally in my server?” Just say, “Okay, this should run at 6pm.” That makes life an awful lot easier. A lot of these things start moving into the server, having to set up Apache or have an Apache instance running and having to set up things like modphp or modpy, all of those tools, so Apache doesn’t spawn up a new process for each and every single request. All of these different things just move into your one server, even memcached. Again, you don’t necessarily even have to use memcached with MongoDB because MongoDB is very, very good about using as much available memory as is humanly possible for [keeping your data] in memory.
JAMISON: That is such a positive way to spin that. [Chuckles]
CHUCK: What do you mean?
JAMISON: Oh, I mean it uses all your memory, right? That could be a bad thing or good thing.
VALERI: Well, if you have extra memory, then you’re not using all of your available memory.
VALERI: But I think that’s part of the point of having memory in the first place, is you want to use it, in theory. And I guess, again that is something that people have criticized MongoDB for. They have their beef with that. It can use a lot of memory and if there is available memory and all of your data doesn’t fit into memory, it will still try to use all available memory. But that’s mostly because you want your data to be in memory because you don’t want to read from the hard drive pretty much ever, because hard drives are slow, especially if you have a web application. The hard drive often ends up being a bottleneck if you’re doing things right and still hitting the hard drive. So, [inaudible] if you want to make sure, just never read from the hard drive and the positive spin on MongoDB’s memory usage.
JAMISON: So we’ve talked a lot about all the strengths of the stack. Are there any gotchas or pitfalls or things to watch out for? [Inaudible] MEAN stack?
CHUCK: Or places that…
JAMISON: Restart your server periodically.
JAMISON: There is one incredible blog post about people debugging memory leaks in Node. And it’s intense. They’re all on the SmartOS and using DTrace and generating all these graphs and stuff. But they have really specialized tools and it can be painful. Yeah, so that is one issue.
CHUCK: Is this a problem that frequently occurs?
JAMISON: Not more than any other garbage collected language. But in every garbage collected language, you can have memory leaks. So it happens sometimes.
CHUCK: Yeah. Well, in most garbage collected languages that I’ve seen, you can trigger your own GC. But yeah, if it’s a really frequent problem, then I can see people being concerned. But if it’s something that most people aren’t really going to run into, then I don’t know.
JOE: And let’s be clear. Memory leaks were invented by non-garbage collected languages. It’s certainly not unique to garbage collected.
CHUCK: That’s true.
CHUCK: Well, the other thing is that if you create a memory problem on the browser, it’s those people that have the millions of records or whatever that you’re displaying, and there are ways to mitigate that. But on the server, if you crash the server that people are connecting to, you’re going to affect a bunch of people all at once.
JAMISON: So, there is an option to expose the garbage collector in Node. I was just googling this because I thought I heard of it. I’m pretty sure this is mostly for testing though. I don’t think you want to do this in production. But we’re not talking about stuff that wouldn’t be picked up by the garbage collector anyway. We’re talking about leaks. So running the garbage collector wouldn’t find your leaks, so you’re still not going to get that memory back.
WARD: Yeah. Often it isn’t just about leaks. It may not necessarily be a leak. It’s maybe that you’ve accidentally accumulated too much stuff and you don’t know that you’ve got too much stuff unless you have some other metric on it. But you have no idea about which environment you’re in or how much memory you’ve got. So you don’t know how much you have to play with, if you want to make decisions about say flushing a cache or something like that. So it isn’t just about memory leaks.
VALERI: A lot harder than people think it is. [Chuckles]
CHUCK: Yeah, but at the same time, I’ve been a hiring manager and hired people that didn’t know the technology we were working in and they were smart enough and had enough experience and skill to pick it up.
JOE: Do you think there’s potentially an issue with the market getting flooded with people doing client-side development that want to move to the server but just have no idea how to code on the server?
CHUCK: Who knows?
WARD: I don’t think they know how to code on the client.
CHUCK: Yeah, I agree.
JOE: So I want to ask a question. If you got people out there that are very interested in MEAN stack and want to learn it, where do you think is the best place for people like that to go?
VALERI: Oh, the resources out there are still somewhat limited. I think that it’s slowly but surely improving. Right now, the things that come off the top of my head would be MEAN.io which is a wonderful MEAN stack skeleton and other tools maintained around the MEAN stack by some guys in Israel I think it is. There’s also my blog, shameless plug, TheCodeBarbarian.com. I have a few posts about the MEAN stack and why it’s useful, how you can get started, how you can build a very simple to-do list application with it, and a few simple use cases like building an online store where you want to change between viewing prices in different currencies.
Those are the things that come to mind right now. I would love to hear some other people’s opinions. If you want to learn about AngularJS in particular, you can look it up on Google. Egghead.io also has some excellent tutorials that I’ve heard are truly wonderful. That’s pretty much all that I can think of off the top of my head right now.
CHUCK: I still maintain that they should have registered MEAN.io in Ireland.
JOE: I like the MEAN.io. I just completed my course on MEAN development on Pluralsight. So I definitely want to recommend that one as well for learning MEAN. But when I was preparing for that, I went through and tried to find all the places where people were giving fundamentals of how to learn MEAN, just to get ideas for what other people were using to teach people MEAN. And other than MEAN.io, I really didn’t find much in the way. So definitely, here’s a shameless plug for my Pluralsight course on MEAN development and introduction to it.
WARD: Well, if it’s as good as your other courses Joe, I’m looking forward to seeing it. Plug that.
JOE: Hey thanks, Ward. Thank you.
WARD: [Chuckles] But I do think that the A is where you go to spend most of the time anyway. And there’s lots of good stuff on being a good Angular developer.
JAMISON: Yeah, the Mongo stuff, their docs are pretty good and they send out, you can subscribe to some newsletters and [inaudible].
VALERI: There’s also a MongoDB university, which is another thing that I forgot to mention. They have numerous courses including so-called M101JS, which is basically MongoDB with an emphasis on Node.js development with MongoDB, a roughly 40-hour video courses and nice little tests that will give you an exhaustive knowledge of the very fundamental stuff with MongoDB with a little focus on the side of how you interface with MongoDB using Node.
JOE: And I think learning MongoDB, especially from scratch, is actually really straightforward. My one complaint is I wish it was just a little bit easier or less picky about where you configured your data to be.
JAMISON: What do you mean?
JOE: Well I wish it would make the smart choices if I hadn’t adequately pointed it at the right place for data to go, it would just say, “Alright, well I’m going to put your data here because you haven’t really told me.”
JAMISON: Oh, you forgot, when you have to create the directory for it to store the…
VALERI: Yeah, if the directory doesn’t exist, it won’t [still] refuse to start up.
JOE: Yeah. Yeah, it’d be nice if it did or warned you and gave you something really meaningful and a nice option, just start it up for you. But other than that, I think that Mongo is awesome to pick up and get started with just from scratch, absolutely.
WARD: As long as we’re doing shameless plugs, we have a B.MEAN sample in our portfolio samples for Breeze, if you want to see how that can work.
JOE: Yeah, I think that’d be interesting. I think we’ve talked about Breeze before, but Ward at least highlight what does B add to B.MEAN?
WARD: Well, when Valeri was talking earlier about on a client all you do is make an AJAX call with $http and the world is your oyster. And the Breeze premise is that maybe there’s more involved if you have a rich object with capabilities that is on your client. Maybe there are some other concerns that you may want to deal with there, such as validation and caching and dealing with a self-assembling object graph. A common thing even with Mongo is you’ll pull down a document. But not everything you’ll need will be in that document, or should be in there. Eventually, you’re just going to have some kind of reference to something that’s sitting someplace else, otherwise the document gets ridiculously large.
So, something like, say all the information you would want to know about a product in an order or a line item. So how do you connect those dots on the client side if you want to? If you’ve got a collection of product information or colors or statuses and stuff like that, Breeze can reassemble those so that you have the full object graph but your communications over the wire can be focused on just the parts of the document that you need. So there’s stuff like that and we have a query language you’re actually able to use on the client so that the client can customize what kinds of, the client developer can make decisions about what queries they want to make. And when those queries arrive, we translate those into Mongo queries for you. And from client-side, if you know LINQ, it looks LINQ-like.
JOE: So, I’ll agree with you here that Breeze has an awesome purpose. When we were doing some major work over at Domo and switching over to Angular, one of the things we wanted to figure out was how we were going to handle our models in the client-side, because we had some really rich models that we’d written in Backbone. And I spent a lot of time looking through all the options for modeling and everything else was extremely barebones.
WARD: So, it’s all good.
CHUCK: Alright. Well, we’ve already been talking for an hour and five. And we usually get to the picks about 20 minutes ago. Are there any other things that we need to talk about with MEAN stack to help people understand how best to use it or maybe when to consider other options?
VALERI: Give me another three hours.
CHUCK: [Laughs] Yeah, it seems like a terrific way to go. And so yeah, go check it out. But are there any gotchas that people run into or things that people find difficult or is it really just as easy as installing Node.js and MongoDB and then hooking things up with ExpressJS and Angular?
And number two, a lot of the other difficulties come from again as was mentioned, is that Angular is a complex library. Well, both a library and a framework. It’s pretty dogmatic about how you should write things correctly while also still giving you about three billion ways to doing the same thing. And a lot of the difficulty comes down to understanding how Angular should work and how it should be written.
WARD: It would take too long to go into what I think is an important understanding of the difference between NoSQL and SQL databases and why they both have a reason for being and why they both have vulnerabilities. And Mongo doesn’t escape from the challenges that are faced by NoSQL databases. But it’s way.
CHUCK: Shh, don’t tell Valeri.
WARD: [Laughs] It’s way beyond the scope of this talk, of our discussion. So we could just leave it at that. But it almost sounds like when you do that, that it’s got to be an either/or. And I don’t mean to imply that or that one is bad, because you realize that one has flaws. I don’t think that’s what I’m saying. Not at all. Otherwise, I wouldn’t be here talking about MEAN and talking enthusiastically about it. But I do think that you really have to be aware of what choices you’re making and what consequences you’re making when you go that route.
CHUCK: Yeah, I just want to pile on that a little bit. I’m pretty well convinced that most languages, as well as most frameworks, are set up to handle about 80% of the cases that would come their way. They can handle it really without too much trouble. But there’s that other 20% and sometimes there’s a better way. But give it a shot and see where it shines and see where it doesn’t.
Alright. Well, let’s go ahead and wrap up the call, and by wrap up I guess get into the picks. Jamison, do you want to start us off with the picks?
VALERI: Did you MountainWest JS?
JAMISON: Yes. I will post a link.
VALERI: Cool, because I will definitely do a CFP for that.
JAMISON: Yeah, that’d be awesome.
CHUCK: Yay, payoff. It will be closed by the time this goes out.
JAMISON: Well, if it’s not, submit. If it is closed, then come. It’s going to be great fun. The next pick is just a soundtrack and a video game. I played this game called Risk of Rain. It’s an action rogue-like, if that means anything to you. It’s super fun. It’s really polished, really well-done. And the soundtrack is amazing. So I’m going to post a link to the soundtrack because it’s been my programming soundtrack for a couple of days now. That’s it.
CHUCK: Cool. Joe, what are your picks?
JOE: Alright, so I think it’s fairly obvious that I’m going to mention my course. Right about the time that this episode comes out, my course on MEAN development should be released. I think it’s called Developing Applications with Angular in the MEAN Stack. And so it’s a great place. It’s a very introductory level course. It’s all about putting the four pieces together. It’s not an advanced course by any means. So if you are looking for a place to learn MEAN, that’s definitely a great place to go, over on Pluralsight.com.
My second pick, my last pick, is going to be the new Zelda game on the 3DS. I picked up a 2DS because it was a little bit cheaper than a 3DS. And if my kids got a hold of it, they wouldn’t break the hinges. And got the Zelda game, the A Link Between Worlds. It’s won Game of the Year awards. It’s just been really fun. But it is incredibly hard. It reminds me a ton of the original Zelda game. But I’m constantly getting lost and going online to find out what I’m supposed to do next. [Chuckles] But I really enjoyed it.
CHUCK: Awesome. Alright, I’m going to pick a couple of things. If you’ve listened to the other shows that I do from this week, I’m picking the same thing on all of them because I just got back and I haven’t really had a chance to think of anything. So the first pick, my family went to Disneyland and we had a terrific time. We actually got a house that was a couple of blocks from Disneyland so we just walked to the park every day and then we’d walk back when we needed a nap and it was terrific. So a lot of fun. And I highly recommend, if you’re looking for a terrific way to spend a few days, then go to Disneyland.
The other pick I have, halfway back, well not quite halfway back, from Disneyland to here is Las Vegas and I was there for New Media Expo. And New Media Expo is the big podcasting, blogging, web TV, YouTube kind of crowd. And it was a ton of fun. And I met a lot of cool people, met a bunch of podcasters that I really admire. So if you’re interested in learning how to blog or podcast or if you have any of those and you’re looking to take it up a notch, then by all means go to New Media Expo next year. I don’t know yet when it’s going to be, but the last two years it’s been in January in Las Vegas. And the other nice thing about that is that they’ve set it up so that it ends when CES starts. And so I was able to go to some CES press events while I was down there for New Media Expo as well. And so that was a lot of fun. So yeah, those are my picks.
Valeri, what are your picks?
VALERI: Sure. Well first of all, I would love to, while we’re on the subject of shameless plugs, I’d like to link to my blog once again, TheCodeBarbarian.com. I’m going to make it a New Year’s resolution to write more often. However, I have maybe about 10 or 12 blog posts right now on various topics ranging from the MEAN stack to nutrition and general rules for how to be a better developer.
CHUCK: Awesome. Ward, what are your picks?
WARD: Alright, I’ll blast through them quickly. First of all, everybody should go to BreezeJS.com [chuckles] which is our open source product that we talked about earlier. The link is there.
It’s too late for you all to go to ng-conf, the very first one. And Joe is one of the founders of that conference that’s going to be next week. I’m looking forward to that. Maybe there’ll be some video.
The Angle Brackets, they have intersections in the spring in Orlando, is a great conference. It’s fascinating to see how single-page apps, Angular, and I suspect we’ll be seeing a lot more Node and Mongo are showing up big time in the staid Microsoft .NET world and you can see it happening there.
And then on the fun side, if you’ve ever wanted to fall in love with Siri and she sounded like Scarlett Johansson, you’d want to see the movie Her, which I think is a winner and a really poignant, surprising tale of the love between a man and his female computer voice.
JOE: Nice. Hey Ward, now might be a good chance, since this episode should be released during day two of ng-conf, to mention that the conference sessions will actually be streamed live and put up on YouTube. So I don’t have links that I can give here in the show notes. But for those who are listening to this, it should be going on right as you listen to it if you got the episode as soon as it’s released.
WARD: Wow, that’ll almost be like being there, except it won’t because being there is going to be a lot of fun.
JOE: And definitely tastier food.
VALERI: Y’all need to advertise that more. I actually did not run into ng-conf until December 20th of last year. So apparently, I haven’t been following the community enough. But either that or you all didn’t advertise well enough. So I’ll make sure to look out for it next year.
WARD: Well you haven’t lived until you’ve seen Frosty and Geddes do their show on Angular tied into various electronic devices. It is funny.
VALERI: Oh man, that sounds awesome.
JOE: Yeah, it is.
VALERI: I don’t have words to describe how awesome that sounds.
CHUCK: Alright. Well, thanks for coming guys. It’s been a terrific conversation, a lot of things that we discussed. And hopefully, we’ll get some people to try out MEAN and see what it’s all about. See how it can help them out.
And I guess we’ll wrap up the show. We’ll catch you all next week.