The crew talks about preferred backends.

 

Just the three of us today?

[Sings] We can make it if we try – the three of us.

Hey everybody, and welcome to Episode 10 of the Adventures in Angular Show. This week on our panel, we have Aaron Frost.

Hello.

Joe Eames.

Hey, there.

Lukas Reubbelke.

Yo.

I'm Charles Max Wood from devchat.tv. And this week, we're going to be talking about our preferred backends for Angular.

You know, when you introduced the show, it kind of sounded like “Avengers in Angular.”

That’s right. We are the Avengers. I get to be The Hulk.

Oh, man.

Is that because you're really big, or because you don’t have any social skills?

Aww. All right, so I'm curious what backends have you built Angular stuff against.

I've used Angular with Express and Node. And I've done some with Happy in Node. I've also used some Firebase as well.

And you’ve used Java.

So at work, I’ve used Java. I didn’t write that myself though, so I was excluding it, but I have used it with Java as well, yeah.

Yeah, Java is a hard one to claim because it could have been in FoxPro backend for all that we had to deal with it over at Domo.

Yeah.

It was just a set of services that we called.

Yeah, it's just a bunch of [unintelligible] that we talked to, so.

So I can add in there .NET as well.

And I think I've done pretty much almost every backend. I'm doing .NET right now.

Almost. So let’s see, Rails, .NET, I've done Java, I've done Python, and also I've been playing around with StrongLoop’s API libraries which is really good. And then I use Firebase quite a bit as well.

PHP?

Yes, PHP as well. If you delineate your backend and your front end on a REST API, it's really what's on the other side of the fence is kind of trivial, so I’ve use quite a few versions of backends.

How about a custom C++ built web server?

Well, now you're just getting crazy.

Not really. What about Erlang?

We should issue a challenge to our audience to produce a rest API in Erlang, and I will implement it. True story.

Nice.

You heard it here first, folks. This is the $10,000 Erlang Challenge.

Yup. Bring it on.

I am connected to Erlang people, so I might just do that for you.

Thank you. I appreciate that. How kind.

So I've done Ruby on Rails, I've also played with the MEAN Stack, and I've done a little bit with Sinatra, and Sinatra is another Ruby framework.

What's everybody’s favorite? My favorite is MEAN.

I haven’t done enough MEAN to say it's my favorite. I’m probably still happily in the Rails camp.

[unintelligible] with Mongo to be like in love with it. I wanna do MEAN, but more like with MySQL.

MySQL?

Yeah. Can I not say that? This is not a safe place? [Laughter]

This is the circle of trust, Aaron.

Yeah, I didn’t say MSSQL, man. I said MySQL. I thought it was okay.

Yeah, it's all good.

I really like Rails and MEAN Stack, but if I'm just taking something else for a lot of prototype work, I actually use Firebase because you get real time stuff, but you can also translate that into a REST API for free. So generally, I'll start with Firebase, and then move over to usually MEAN Stack…

So every time you guys build something on a Rails backend, do you get a nasty letter from DHH saying, “Stop it.”?

[Laughs] Not quite.

That, “You're wasting your time using Angular because server side HTML rendering is all you need?”

Stretching. You're stretching, Joe.

That’s exactly what he said, dude. That's exactly what he said.

But with the accent.

I can’t do the accent.

Well, life goes a little beyond DHH’s opinions.

But yeah, it seems to work really well. I'm curious, in Rails, what do you use to build your JSON out?

Generally, well, I'm no Rails expert but that you generate your routes and the just by tapping the .json onto the routes, I’d get that for free. So that has been my experience that somebody would generally… I will work with Rails developer and build up the models, generate the routes, and then you get to kind of JSON stuff for free.

Okay. You're using JBuilder which is the default from Rails.

Yeah. It's easy and that’s why I love it.

Nothing wrong with that.

Yes, sir.

You guys mentioned Firebase, and that you like it when you are prototyping and stuff, but what about for a more serious implementation? How does Firebase work for something that isn't just a prototype?

I know that we're going to have a Firebase episode sometime in the future, but it's time for some real talk is I love Firebase. I think it's amazing technology. But I am a firm believer in using the right tool for the right job. And so Firebase is really good in my opinion for doing real time stuff, so for instance if you have an application that you need to integrate kind of real time, add functionality into that, it's great for that, as well as for prototyping. It's really excellent to get a prototype up.

Where it kind of starts to fall apart is if you have complex relationships within your data models, that you need to represent and expose via back end, is that there's no ability to kind of query the database or query your backend and get like filtered results. Or if you need to actually establish relationships, you kind of have to denormalize your structure to do that, which is fine for small things, but it becomes very difficult very quickly. And so for that, I think it's understanding that limitation of if you need to perform [unintelligible] like the backend, not the case. We're not appropriate used case.

So that would be kind of one thing is what are the actual requirements for that where it does at the same time, as it works really well in conjunction with other backend. So using even Firebase as an event bus, that works with like Rails application. I've done that to where we stored the data, it was sensitive like HIPAA compliant data into Rails, and once it was updated, you'll need to let firebase know. Then from there, we were able to update certain pieces of the application. So really, for realtime stuff and prototyping, but if you need to do a complex data models, I would probably put that onto Mongo or PostgreSQL and then expose just the pieces you need to be at Firebase, if that makes sense.

Would you pair them up together then?

Yes. I've done that with Mongo and Elasticsearch and Firebase. I've been using those three together. So Mongo to hold the main data model, then doing rich query via the elastic search which was really great tech there, and then doing the real-time stuff and synchronizing that via Firebase. And so that’s worked really well. It was pretty easy to set up those. And I think it's a really good setup there is using Firebase in conjunction with something else. But even like Mongo, if you wanna really do vast, rich query, I don’t think that is maybe the appropriate technologies, probably Mongo plus Elasticsearch.

Does anybody use Kinvey? Ryan Kahn gave an awesome talk at the UtahJS conference about backend as a service, and he mentioned Kinvey specifically and kind really kind of talked it out. We talked about Firebase, we also talked a lot about Kinvey. He mentioned a few others. I think he mentioned GoInstant and some ones that are more detailed towards being mobile backend. But he talked about Kinvey, and said that that was a really awesome backend as a service.

His whole talk was basically talking about how backend as a service is potentially going to do same thing that platform as a service did, and kind of grow to be this thing that will enable developers to build apps potentially without needing much in a way without anything at all in backend work and just hook up to a backend as a service, and not have to do anything. Where platform as a service eliminates the need for IT guys worrying about infrastructure backend as a service eliminates the need for backend work. It's really interesting talk.

Yeah, there are several of them out there and we’ve talked about on the iPhreaks show, and it's definitely an interesting thing to think about.

I've heard that before, and I've never like fully been able to wrap my head around how it can be secure. I'm sure that the guys that Firebase would be like, “Well, it’s easy.” I just have never been able to wrap my head around it.

I don’t know. We'll have to remember to ask The Firebase that and then heckle him when he answers.

I will say it is easy-ish, but we will save for that another episode. You all come back to here.

It's easy to be secure?

They have some rules about kind of an access tool in the forge that you can actually set up, like who can actually write to what or what is exposed. So they are definitely is when you go to like Firebase, is you get a very specific kind of email like, “Hey, you really need to kind of go through these steps to [unintelligible].” And so you can set access privileges and who can do what to the different nodes within your Firebase object.

Okay.

It's essentially a JSON object that you kind of construct. They all [unintelligible] tools to make that a little bit more intuitive. So they will say like, “Yeah, handwriting this JSON object is not super easy.” That’s why I said easy-ish. But it's fairly well-documented, but I think they are working on kind of a UI tool make it a little bit more intuitive.

So moving away from backend as a service, Lukas you said you work with .NET right now, how do you like that?

It's interesting. So I think that with .NET, where we’re using MVC like 4.5, and we have a gentleman doing the .NET kind of like REST API. The beautiful thing about it is because it is REST; I don’t really have to worry about the implementation details of the .NET side per se. And so I jumped in and fiddled with it, but more so, it's kind of the ecosystem around Visual Studio, and kind of the Microsoft ecosystem that I think has been interesting. As well as having to setup like templates via routes, and MVC framework.

But as a whole, I think once you wrap your mind around like, “Oh, this is the .NET to do it, it's pretty streamline. The interesting thing is that I know in the new versions of Visual Studio, they are coming up with, they are going to introduce Grunt support, but new they are kind of on build management system. So it's really weird. I feel like I'm in the void, by being in this ecosystem that doesn’t actually have like Grunt as a first class citizen. So, if anybody from Microsoft is listening, please put that on the fast track. I love you. Thank you.

So are there tradeoffs that you found between using a Node backend or a Rails backend or .NET backend or something else, that really make a difference in what you are choosing for a specific project?

I think what the client is using ultimately is you wanna get the best solution for the client. So in this case, we're using .NET because their entire infrastructure is built on .NET, and so that’s obviously the right choice. But I think a lot of it, really honestly comes down to not necessarily a technology per se, like, “Oh, are you using Python or Ruby or the MEAN Stack?” Is a lot that comes down to I think your existing skill set, the ecosystem, and also the tooling around it.

So I don’t think it's like language per say that would cause me to make a decision one way or the other, but what's the ecosystem, the community like in the tooling. So for me, I really love the MEAN Stack because you kind of have this really amazing tool chain with using Grunt or Gulp to build these things out. With Angular, you have Karma, so you have this amazing test runner that you can do different things with. And so it's kind of these tangential things that really I think affect my decision.

Interesting. Yeah, I said that MEAN would be my favorite. I like the synergy in the tools and basically working with JavaScript the entire time, so I like a lot about MEAN. But I will say that I'm not sure if we necessarily disagree, but I'm very familiar obviously with .NET, and .NET seems like a very polished experience when it comes to throwing everything together, all the little tools. The problem is just missing tools that I like to use. For example, as you mentioned, grunt isn’t a first class citizen. Same thing would be too with Gulp.

So it's missing tools that I like to use, which is why I just prefer MEAN a little bit better. But also, one of those developers doesn’t like black boxes as much, so I prefer working with tools that let me dig into them a little bit more, and expose a little bit more of themselves and .NET doesn't necessarily always do that. Sometimes it does kind of, but I’d say in general, it's more black box-ish than I like to be, that's why I prefer more MEAN. But I feel like I end up building a lot more pieces with MEAN. Like if I was just looking at absolute time from start to when I have something working and building, then I think .NET is kind of hands down a win there between those two over MEAN.

I totally agree. Visual Studio is a really good IDE once you kind of wrap your mind around how they do it, and make peace with those blackboxes. I actually have [unintelligible] do C# using ReSharper. So ReSharper plus Visual Studio is a really good development experience if that’s all you are doing is we'll say kind of good integration with a lot of the other Microsoft tooling. So for instance, we're using team foundation server and it just integrates seamlessly into that, right from the IDE or if you need to touch the database, you can do it right from the IDE. So it's actually kind of this composition of black boxes that if you are all in, it's great, but if you need to introduce some new things, or you wanna do thing in a different way, it's a little challenging.

I agree with that. I hope that your TFS experience is better than last time I was playing with TFS. I hated it.

It's not too bad. I mean, once you kind of accepted it is what it is, it hasn’t been too painful, so.

So to switch gears, to circle back around this is surprisingly apropos, but next week on JavaScript Jabber, we're having the episode on Backend as A service with Ryan Kahn, the guy was talking about.

Awesome.

So we'll have more questions to ask to him based on this episode.

Yup.

And after that, next week is Angular Fire.

Oooh, yes.

Is that next week?

Yes. We’ve got Michael Wulf and David East on talking about Angular Fire.

Nice.

Two awesome episodes in a row. I'm excited.

That will be way cool.

Let’s talk about PHP. I wanna talk about PHP.

I have no experience whatsoever.

I thought like you were in the [unintelligible] talk with like, “Let’s talk about languages that suck.”

[Chuckles] Yeah.

Let’s talk about JavaScript. Joe is like, let’s talk about… anyway, I love PHP. Lukas [unintelligible] because I love you.

Lukas, talk about PHP.

PHP I think is proof that you can take an okay language and do really amazing things, aka, if I'm going to do a blog, it's going to be on WordPress. I don’t have time to do that. With that said, I've played around with Laravel, and so it's kind of a Rails-ish framework for PHP which you can generate REST APIs. So it's not too bad. Again, like I think the biggest thing that I would want to, if anybody had any questions about where I stand on Angular backends is REST API, REST API, REST API. And so if you can delineate your front your backend on the REST API, then you can kind of focus on the front end, and it doesn’t really change depending on the backend.

So with that said, it's pretty easy to generate RESTful API in Laravel. So I have just a little bit experience on just kind of a side project that I did, and it's pretty good. Tuts+ has some pretty decent tutorials on that as well. So if I were to do it and I would kind of go with Laravel because it is kind of like Rails, so kind of that paradigm is familiar and just generate a REST API.

Awesome. So I have kind of a question that spans across all the backends. My experience when I was getting into MEAN was that authentication was the one thing that always seemed to be unique amongst the backends. If you get the REST API working, it's almost like you could squint your eyes a little bit and whether you had .NET on the backend or Node on the backend or Java on the backend, you kind of went to these steps of, I need another restful API, so I hook up the database, I do whatever route I need to do for it, I might do a little bit of validation, and then I have this piece.

And I am minimizing my backend and going… all my really hard logic is on my frontend, right? So between all my different backends, they just don’t seem to be that distinct once you kind of figured out how they work, and then it's almost like [unintelligible] you can pay a high schooler to just do your routes for you. But the authentication was the piece that was like, “Oh, this is entirely different here than it is on this other thing.” I have been doing it the first time authentication was Express and Node was entirely unique from all my other experiences doing with authentication. Do you guys feel the same way?

It definitely differs from back end to backend. For instance, if you are using Node, you have Passport, I know that in Rails, there's a specific one that you can use. I don’t remember it at the top of my head, so Charles if you wanna to jump in if you know one. You know, Laravel has their own kind of security thing. Firebase comes with, they implement with some kind of authentication services, so it's kind of  OAuth centric. So I would say even favoring OAuth is maybe a way to kind of standardize across the backends. So you can do that. I know there's some pretty good libraries, you kind of drop that in and do OAuth kind of across the board.

Yeah, in Rails it seems like the one that most people use is Devise for authentication. And then there are few others like Sorcery and Clearance that work pretty well. It actually just depends on how much magic you want. You know, do you want to understand what it's doing, or do you want it to just do it? Devise is kind of magical. But speaking of OAuth, that's typically the way that I go with authenticating backends to get API access. And the library I use for that in Rails is called doorkeeper, it's actually going to be the first episode of a new video series I'm putting up called Rails Clips, so if you wanna pick up some tips on how to do Ruby on Rails, JSON API backend, that's kind of going to be the first four or five episodes of this new series that I'm doing. But yeah, doorkeeper makes it really easy for you to set up application, set up application keys and get authenticated.

It sounds like door key pur.

Yeah, what's a pur?

Yeah, what's a pur?

It's like when a cat is purring, but in a really dorky way.

Ah.

You have a real dorky purr. [Laughter]

So anyway, I'll put a link to that in the show notes, and then there are also a bunch of JSON API and libraries that you can use. You don’t have to go with jbuilder. And depending on what you are doing, some of them are pretty nice, so active model serializers allows you to deal with your JSON like a regular object, and then it just sends back the appropriate result. And [unintelligible] it provides a DSL that makes it easy to again, serialize your objects in a way that you want, and you can actually nest stuff on those and it's really, really nice way of turning your response into a [unintelligible] view.

Awesome.

So I'm really excited to talk about Angular Fire next time. Are there any backends that we haven’t discussed?

We mentioned Node and Express, and really anything Node based, which is a lot of what like guys on their own time are using. I'm not saying that most Angular developers use Node and Express, but it is one that we kind of glanced over just because I think we just go like, “Well, that’s the one that a lot of people use, so we don’t need to talk about it, like let’s talk about these other ones that may seem a little more like not common for Angular. I mean I love the story with a Node and an Express are happier, there's not a sales out there for Node. And that kind of RESTful framework on top of Node where JSON just kind of build into the platform and you don’t have to deal with odd stuff in your JSON because the platform that your web server also speaks JSON and

[unintelligible].

Also you don’t really have a ton of context switching. And for me, there's some really sharp developers out there, so when I complain about context switching, someone will just like look at me, like, “Dude, you're stupid if that’s a problem.” And maybe I am, but it's a big deal for me I'm like writing my backend and if I have to write it in Java which is what I used to use, when I switch back and forth from the front end or the back end, I wasn’t like full steam ahead when I’d switch, because you had to get back to that framework. And again, for some people, it's nothing. For me, it was significant. And switching to Node, I was like, “Dude, I can literally like switch back and forth. And I don’t even miss a beat. I just keep going.” And for me, developer productivity has been sweet. And I'm a huge fan of using Node all the time, but I mean, since I use Angular, those are what I can buy most of the time.

Using JavaScript all the time is what you mean.

Yeah, using Node because it lets me my JavaScript on the frontend and the backend.

So that’s a pretty interesting perspective. When I started working with MEAN, I would say the very first thing I've noticed was that the context switch was actually more difficult for me. Again, I prefer the MEAN Stack or Node on the back and I'm not really stuck on the MEAN Stack. I really like Koa. I think it's a very cool framework and I've played around with it some and I thought it was awesome.

I love it.

I find the context switch to be actually more difficult because the conventions and the way that we write JavaScript in Rails is different than the way we write JavaScript on the client. And specially, obviously in Angular, right? But because they are so much different, I've found myself doing things that if I go to the backend and I’d write it in a certain way, it's like, “Oh, this is entirely wrong. I have to switch this.”

So I kind of agree, but then I choose the way I wrote my backend. And like Angular really was like, “Hey, Aaron, stop doing it the way you're doing it and use Promises.” And so, once I threw all my backend stuff to use queue, and now I got Promises, my code is all based around Promises, the way my code looks is way different. And they look really similar when you're writing your backend services and frontend services, and they all use Promises like that stuff. So I don’t know. It looks way different when you write your backend using Promises as well.

Are you doing that with Express?

Oh yeah.

Really? That’s interesting. I’d love to see how you did that.

Yeah, again it makes your code… it feels like you're writing your frontend because it's all Promise based and you can do your promise.all, your promise.raise, you can chain them, and because you are using queue, it works almost exactly like what you think the Angular is going to do. And so it is super predictable for an Angular developer to use queue in your Node code as well.

Yeah, I did find that figuring out, “Okay, I'm using these modules this way here, and these modules this way here,” it was a little bit different because I was expecting it all to work the same way when I first started with MEAN Stack. I am curious though, it seems like people get excited about MEAN Stack, and I could share all my code between the front end and the back end. Is that a pipe dream or is that actually happening?

For me, I've found that to be a pipe dream, but after talking with the guy at HabitRPG on Ionic, he's doing a fair amount of it, sharing the code. Although, he's sharing code between the website and his mobile app, so he's not showing [unintelligible] single line of code or any of the code that I have written. I've never been able to share a single line of code between server and client. The only code that I’d want to share would be maybe some validation, but it seems like it's entirely different.

I can see wanting to share like in a traditional MVC setup, you might wanna share your ‘m’ to get models.

Exactly.

You get similar behavior on both front and back, and validation is a good example of that.

That’s exactly what I was going to say was your model is where I think you could get reuse, because on the client, if you have an item and it goes inside of an item list, and you have a model called item list and a model called item, and they know how to talk to each other, and they may even have a cyclical dependency, like a cyclical reference so that they are using the [unintelligible] with each other, using those two models across the front and the back could be a thing that you could do. I haven’t done a ton of reuse, but I would consider myself a total noob is for even trying to reuse code for my client and my server. I haven’t even put a lot of effort into it. So is it possible?

Probably, I've never really done a lot.

Let me jump in here real quick because I have actually had some experience with isomorphic JavaScript is I did a project and I kind of still somewhat involved with GetHuman. Jeff Whelpley, who is their engineer on that, is GetHuman is essentially I might need to get a human on phone. And so essentially it's a community driven site that relies heavily on search engine server traffic.

And so, the problem that we had is we need to actually render the views on the server, but then share that code in a client with the Angular, so it was a really neat to solve that isomorphic JavaScript problem. And so, to have server side rendering, but then be able to take it up on the client side. And so it definitely can be done, but it's not without challenges.

In fact I think, he would be a great candidate for person to have on a future Adventures in Angular podcast, because he had to solve that problem because their entire business model depends on search engine traffic. And so he had to do things on the server, the rendering is what was, pick it up on the client once it has been rendered. And so it can be done, but it's not without some challenges to say the least.

Yeah, that’d be awesome. In other words, bring it! [Chuckles]

Bring it on. I will let him know.

Awesome. All right, well we're getting really close to the end of our time. Is there anything that we would be crazy not to talk about that we haven’t yet?

Probably our users know a lot. They are pretty smart.

If there's anything in particular you want to talk about. And I like to do shows eventually. Not all in a row, but do one on MEAN Stack, and do one on Express, do one on PHP, do one on Rails and kind of get some perspective so people can see an entire stack in that technology. So if there's a particular stack that you'd like us to talk about, let us know about that too. You can just tweet us at @angularpodcast.

Awesome.

Should we do some picks?

Let’s do it?

All right, Lukas what are your picks?

I just have one. Last week, I got back from Strange Loop Conference in St. Louis. It is probably outside of ng-conf. I love you guys. It's my favorite conference. And it's just a ton of like functional like Scala, Clojure, really smart people. Stephen Wolfram was there this year ,where he spoken pretty much every year that I've been there. So I would just check out their YouTube channel. And it is just amazing. Those talks are ridiculous. They will make your head spin, but pretty incredible. So that is my pick. Strange Loops videos, incredible.

Joe, what are your picks?

My pick is a talk given by Lawrence Lessig on OSCON 2002 on Free Culture. It's great talk about these folks primarily on copyright, but talks really just about our entire culture, and freedom of expression and artistic expression. So super awesome talk. Ad it's also he was also kind of a pioneer of a certain style of getting presentations as well. He's pioneered this Lessig-style of presentations, so it's very interesting great talk. So that’s going to be my pick.

Aaron, before we get to your pick, is there any news that you want to give us about ng-conf?

Yeah, the call for papers is out, so if you're an Angular [unintelligible] and you're wanting to be a part of the next ng-conf, go ahead and submit it. Head over to the site. ng-conf.org and do a submission for a chance to speak at the conference. We're not going to have unlimited spots. Obviously the line is going to look a lot like, as far as the show runs, like it did last year, so we'll have a specific number of spots. All I can suggest is be outrageous. It needs to be outrageous. So if you can do some outrageous…

Did somebody say my name?

Yeah, no, no, I'm not talking to you, Lukas, even though it is your name.

If it's outrageous, it's got a better chance is all I'm saying. It's my only tip. It's my tip of the week.

Very cool. And then what's your pick?

My pick, I just gave a course at Frontend Masters on ES6. I wasn’t going to pick it, but we got so much good feedback on it. I'm going to do a pick. I really think people can get a lot out of it. It's on ES6, the next version of JavaScript coming out. It's a full-day course and I thought it was really informational as a teacher and it sounds like most people that were there also really liked it, so I'm going to pick Frontend Master’s ES6 course.

All right, so I have one pick. As some of you may or may not know, I love Audible. So the latest book that I've been listening to is a fiction book called Michael Vey 4: Hunt for Jade Dragon. It's a young adult fiction, so it's a pretty easy read. And it's just kind of a fun book. And so yeah, I enjoy reading that and so that’s what I'm going to pick. I'll put links to that in the show notes.

All right, thanks for coming. We'll catch you all next week!