The panelists talk backends as a service with Ryan Done.

Special Guest: Ryan Done.

 

Hey everybody and welcome to episode 129 of the JavaScript Jabber Show. This week on our panel, we have Dave Smith.

Hello world.

Merrick Christensen.

Hey guys.

Joe Eames.

Hey everybody.

I’m Charles Max Wood from DevChat.TV. And this week we have a special guest, Ryan Done.

Hi, how are you all?

Do you want to introduce yourself really quick, Ryan?

Sure. My name is Ryan Done. I’ve been a full stack web developer for about ten years now working at a number of startups, at Ancestry.com as well, not a startup [chuckles]. And a little company within Ancestry called AncestryDNA. I now work for ClientSuccess trying to take on the subscription renewal services for SaaS companies specifically. But recently when I moved over to ClientSuccess I moved from being full stack and working with a Java backend to being fulltime frontend architect. And so, that’s what I do now. I’m the frontend architect at ClientSuccess.

So, why are we talking about backends then?

Yes.

And we want to keep our clean rating, so.

[Chuckles] Alright, we’ll keep it clean if we have to. So, I got into backend as a service about a year ago. I started getting interested in it. And it all started from, I took a year’s stint doing Android development. And I actually got bored of Android development after a year because there just was not quite as much to do in Android as there is in your typical full stack web development. And people who do Android, they’ll probably disagree with me for that. But I found that when I was working in HTML, CSS, JavaScript and then a full backend stack, there was just a whole lot more to think about. But when I moved back from Android development to doing web dev fulltime, I found that there was almost too much to think about to keep my sanity, I guess you could say.

So, as I thought about, at the time I was working at AncestryDNA and as I kind of thought about how engineers are taking the time to compare DNA sequences and then they have to turn around and have the experience to open up Photoshop Illustrator and slice and dice mocks for use on the web, I realized that there was a disconnect there. And I started digging into what is backend as a service. So, that was where my interest came in. Should we talk a bit about what backend as a

service is?

Yeah, that’d be great.

Yes, please.

Alright. So, backend as a service, it helps to have a little history lesson. So, let’s go back to 2007, 2008, a monumental change in the world when the iPhone was released. And after people got sick of the iFart applications…

Apple released…

For the record, I never got sick of those. [Laughter]

Well, you never get… you still got it, you [inaudible] with it, huh?

Yeah, I’m trying to raise funding right now for an iFart application. [Laughter]

Well, that’s good because I’ve got the lightsaber app. That’s the one I’m raising funding for.

So anyway…

[Inaudible] on Kickstarter, Merrick?

Absolutely.

It’s the only way to raise money these days.

Merrick iFart. That’s excellent.

I find the Kickstarter community is enthusiastic about farts in general. [Laughter]

Nice. Well, back to backend as a service. So, in 2008 Apple released the iPhone SDK and this allowed people to build their own apps. Later in the year, they had push notifications that they added to that. But you had to set up a backend to be able to do those push notifications. And it turns out that Objective C is really not the best language for doing backend web development or services development. And there’s probably someone who’s done it out there. I pity the fool. I’ll put it that way. And so, with all these, at this time it was also a chance for lots of little companies to build these applications. There wasn’t a lot of expertise in iPhone development because it was brand new.

And so, lots of new companies came in, started building these applications, and realized that all the backend services that people were requesting were the same. So, they had to have user management, of course data encryption, some analytics, and push notifications, and then a place to store and sync information. And that’s pretty much the same across most mobile apps, if you look at them. They’ve got to have those basics. And so, these companies decide, “You know, why are we rewriting a backend every time? Let’s just create a generic backend and make it available to all of the applications that we write.” And so was born MBaaS or the mobile backend as a service. And it’s grown since then.

Now, there are over 30 different vendors for backend as a service. And it’s really come into its own. There’s actually a few that are really big, well-known ones. But it all started with phone development. And you’ll see that a lot when you look through the literature out there, that they are mostly focused right now on phone development. So, that’s a brief history of backend as a service. Some of the big players out there are Kinvey, Parse, Meteor (it can be considered one), AnyPresence, Backendless, Firebase. But Amazon and Google and Microsoft have all gotten in. They’ve got their own cloud offerings for backend as a service. And those are all mostly focused on phone development right now.

But as these systems have continued to be built out, people have realized that, “Hey, there’s more use to these than just using it for phone development. We can also use it for backend of websites or backend of other applications and then share the data.” So, Kinvey in particular, they’ve got a cool system. They focus on enterprises and they focus on tying together different APIs within a big enterprise organization, and then making those available for mobile application development and then other greenfield application development.

When you say, to tie in together APIs, do you mean that they proxy APIs or they create new APIs for existing services? What do you mean by that?

Typically they’re proxying APIs. So they, like I said, Kinvey is focused mostly on enterprises. And so, they tie together Salesforce and your accounting systems, and all these big systems that are typically really hard to get access to. And they’ll create, they’ll tie into those, the APIs that those systems have, and then they’ll surface an API that’s realistic for the regular developer to use.

Way cool, okay.

Yeah.

That makes a lot of sense, especially for Salesforce.

What are the bare minimum requirements that you should be looking for in a backend as a service? Do some of these self-hosted ones like Hoodie or Meteor make sense? Or are they just not there yet? Are they missing out? What are the requirements you should look for?

Yeah, so let’s talk a bit about the spectrum of backend as a service. There are really so many different types of backend as a service and that’s because there are so many different types of applications that we’re building. So, it’s hard to say a minimum. I’d say you’ve got to have user management and security down pat with each of these backends. Typically, you’ll want to have a database as a service included as part of that, a place to store user data and surface it. I guess if you have those three things, you can be considered a backend as a service. But to be really useful, people talk about, if you’re replacing your backend as a service, or sorry your backend with a

service, you need to be able to write your own custom services within that backend as a service as well. And so, a lot of these provide APIs internally to be able to do that.

It seems like there would be two classes of this sort of thing. So, the basic level in my mind would

be just that it provides basic CRUD operations, create, read, update, delete. So, you can throw stuff on the pile, you can read it, you can update it if you need to, and then you can pull it back out if you wanted. And then on top of that then, if you need some custom work, then you build that in one way or the other.

What’s the standard for how to extend and build custom stuff where you need to?

Oh man, so each of them is different. Well, I guess the standard way is they have a language that you can write in. Often, it’s what the backend was written in itself. And that just allows you to get access to the data through APIs that they surface and do whatever you want with the data, and then surface that through endpoints that you create.

Got it.

So, maybe I can back up a little bit more, go back a little to a list of technologies that I was expected to understand when I was working at one of my last jobs. And think about the list of technologies that you work with and see if it’s similar. So, I was expected to learn and understand HTML5, CSS3 with transitions and SAS and Compass and object-oriented JavaScript, [inaudible] JavaScript frameworks, and then some AngularJS, a couple of different software as a service vendors that we had, lots of little JavaScript libraries. That’s all frontend stuff.

And then backend, we were a Java shop with Spring Data, Spring Securities, Spring MVC, Hibernate, Aspect-oriented programming within Java, and again lots of little libraries in Java and RESTful services that we were surfacing. And then I was also expected to learn and understand unit testing with Jasmine for JavaScript, Junit for Java and test runners for each of those. And then build systems, so Maven builds for Java, RequireJS for JavaScript with Grunt and CSS minification, all those plugins within Grunt. This was a year and a half ago so it was the new thing. Jenkins build server for Java, a Go deployment tool, and the list goes on and on and on as to what a typical senior engineer needs to know.

So, not very many though, right?

No, not very many, right?

So, let’s go on. So Hibernate or some ORM.

There’s more.

SQL Server or some other server, SQL or NoSQL. And then understanding Linux and Tomcat configurations, security patches and OS updates, debugging tools, oh it goes on. So, at some point, my brain just exploded. By the way, I’m not complaining here. I think that understanding and learning all of these things is fun and that’s why I’m a web developer. But I just want to point out that there’s a ton of overhead that we keep in our minds as engineers. Write down your list sometime and see.

You’re so right. One thing I’ve noticed working on my current team as we bring on new developers, I’ll say things like, “Oh yeah, you should be able to use StatsD for that.” And they’re like, “What’s that?” I’m like, “Oh.” [Chuckles]

“I guess you weren’t here when we added that to the architecture as well,” you know.

That’s right, yeah.

A dozen other technologies and the same problem.

So, if we go back to computer science beginnings, there was, I can’t remember the guy’s name, but he said that computer science is just a thousand abstractions. We don’t write 1’s and 0’s anymore. We’re JavaScript people. And that’s a long ways from Java even. And so, if we can abstract the backend and make it so that we don’t have to worry about that as frontend engineers, then to me that’s just awesome to be able to get that complexity moved out of the way and focus on what my customers really want, which is an awesome application that meets their needs.

Yeah, totally agree. And it’s so interesting, too. You mentioned all of the different things that we really do have to understand. And so, this really eliminates all of the backend stuff and so then we can focus on providing great stuff for our clients, because we only have to focus on the frontend technologies.

Yeah, that’s totally right. Yeah.

So, do you have examples of applications that have worked really well on this that you’re aware of, on this kind of setup?

So, obviously phone applications are great. I was trying to look. I wrote down a list.

Yeah, but usually they provide their own functionality. They’re almost like the frontend backend. And then the backend as a service just provides a way to connect the data together or to persist it somewhere off of the device.

That’s right. And with single-page applications in JavaScript, I think that’s where web development is moving, is to becoming an application and then you persist the data somewhere else. Of course, it’s all integrated and tied together. But it seems to me that’s the direction that application development is moving on the browser.

So, here’s my list of people who use different backends as a service. And I don’t know the specific applications, so I can’t call those out. But Philips, Regent, Salesforce, Splunk, USA Today, Cadillac, Hipmunk. All these are just pulled from different backend as a service vendors. So anyway, there’s some example. If you look at, have any of you guys used Firebase?

Yeah, I have.

Yeah, yeah, yeah.

So Firebase is a prime example of just something that you can quick and dirty get something up and going. So, they have on their site, one of their examples is a whiteboard application that you can build. Have any of you done that? No, okay. So, you can get on there and just pull down this example code that is a digital whiteboard that can be shared across anyone. And Firebase specifically they do, their forte in backend as a service is three-way data binding. And all of a sudden people don’t like that term, but it’s just tying the data together so that when I make a change on my end it goes and is pushed to another user across the world, right? And so, they have this example application that’s a whiteboard.

Well, there’s a company called Invision that built a UI sharing tool, a UI development tool I guess. I don’t know how to describe it. It’s what we used at my work that our designer will build mocks and then he’ll throw them into Invision and then people comment on them back and forth. So anyway, Invision took Firebase and integrated it with their existing service by adding a real-time whiteboard to their application, just like the example that is on Firebase’s website. And not just, they’ve added a bunch of cool features on top of it. But it allows you to just dig in and communicate more effectively with each other in real-time. So, there’s one example where backend as a service really shines.

I have kind of a comment/question on it, but…

Sure.

It seems to me like for these applications, like a whiteboard or a chat application that has pretty minimal business logic and pretty minimal authentication requirements, the backend as a service seems like a really good way to go. But as soon as you need to have some logic that you don’t want to have to re-implement across all the clients you’re going to support, like say for example you’re going to have an iPhone app and a web app and they need to be able to communicate with each other using the same backend service, how do you solve that without repeating yourself a lot? So, you end up implementing all the business rules in the iPhone app and then implementing them again in the web app.

Good question. So, that’s where this custom code comes into play. Like I said, most of the more advanced backend as a service systems, they allow you to drop in some code and you can do all your business logic still on the server. And so, if you have just a few places where you need business logic and you’re mostly a CRUD app, I think that’s a great place for backend as a service right now.

Does Firebase support that?

Ooh, I actually don’t know specifically with Firebase.

Which ones are you familiar with that do support that kind of node?

So, Kinvey and Apache Usergrid and BaasBox and LoopBack (LoopBack is a JavaScript one), and Backendless. [Chuckles] These are all a bunch of names. I’m just throwing names out there.

Okay. So, I’m trying to get my head around when a service is a backend as a service versus infrastructure as a service or platform as a service. So for example, Amazon AWS has Elastic Beanstalk. Google has the Python one. It’s not Google Compute Cloud, but the App Engine I think. You know, would you not consider those backend as a service providers?

Yeah, so there’s a real fuzzy line between backend as a service and platform as a service. I think the difference for me is that a platform as a service, I’ve heard it said it’s bring your own code. There’s a great article by a guy named Brian O’Neal talking about all the different layers of abstraction that we have in web development. And he talks about infrastructure as a service first. Infrastructure as a service is Rackspace, AWS, or Azure VMs, whatever, just a virtual machine. And that’s where you bring your own application container and your whole application. You set up Tomcat or you setup Nginx or whatever it is you use to run your application.

And then yeah, the next level like you’re talking about is platform as a service. And that’s where you bring your own services and your application. And so, you deploy your work file out there or your PHP files out there, and the platform as a service automatically scales that and takes care of all of the infrastructure needs that you might care about.

Yeah, I tend to think of the platform as a service as like the Google App Engine or Heroku or some of the other ones out there like that where effectively, so they’re not the infrastructure as a service where they’re providing you a server that you have to set up on your own. They’ve done the setup.

And as long as you meet their qualifications, then they will host your application for you.

Yeah, that’s exactly right.

That’s the platform as a service.

Yup. So then, the next level of that is backend as a service. And so, they’ve set up all of that already. In fact, they might even be built on top of a platform as a service. But they’ve brought their own code that is most of the backend that you care about. So, it has a bunch of REST endpoints to a database. You can configure your own REST points either through a UI or through just configuration files. And then you bring your own frontend application on top of that. It can be a single-page app. It can be an iOS or Android app. But it’s the next level abstraction there.

Yeah. I think where the line gets blurred a little bit is where you’re providing your own endpoints on top of the backend as a service.

Oh yeah, for sure.

So, the parts of it that are programmable, is that platform as a service or backend as a service?

And I can see the line being a little bit fuzzy there.

So, is it fair to say that if I write code for a particular backend as a service, like Apache Usergrid, that it will tend to not be portable to other backends as a service?

Yup, that’s pretty fair to say.

Whereas with platform as a service, there’s a pretty good chance that I can port. Like if I’m writing a Heroku Node app, there’s a pretty good chance I could port to any number of other places and have it work, right?

Yup.

Okay.

Although, well it depends. So, platform as a service, there’s actually a lock-in there as well. So, it depends on what services you use on top of that platform. So, most platform as a service providers give you extra stuff that you can use that make your life a whole lot easier as a developer if you’re going to stay on their system.

Like what?

So like, is it EC2 with Amazon, that is a database but they also provide extra stuff that’s not just

SQL?

No.

Is that not EC2?

No.

I can’t remember what it is from Amazon.

I think you might be thinking of DynamoDB from Amazon?

Oh, that’s it, yeah. And then there’s Cloud Compute from Google that you tie into their APIs and they allow you to do a bunch of cool processing on your data. But you’re again, tied to their APIs.

So, what about the near future? What do you think are things that are missing in the backend as a service world, whether it’s as far as features and existing services or new services that you think may pop up to solve existing needs?

As far as new backend as a service systems…

Yeah.

Or as far as people adopting them.

No, new features, the new features on existing services or new services. What do you think is missing right there, right now, that could be solved in the next year or two?

Whew, man. I’m probably not the best person to answer that, honestly. So, let me just run through a list of…

How about an easy calculus question instead? [Laughter]

Nice. Let me run through a list of features that these backend as a service providers have already. And then you tell me what might be missing. So, they’ve already got user management, data encryption and security, load balancing, social logins with Facebook, Google, XYZ, as well as logins through LDAP and Active Directory, data and file storage, offline data caching, real-time data synchronization again depending on the system, analytics based on the RESTful endpoints it provides, easy integration with third-party APIs just through some mappings, CRUD operations that are automatically set up, media streaming, push notifications, email services.

They’ve already got different environment setups. You can run dev test or dev test prod, whatever you want to call it. And versioning, and then most of these will also take the settings that you’ve put into it and automatically generate some code for you to plop into your app, or an SDK for you to be able to access all these endpoints that you just created. So, you can just plop that SDK into iOS or Android or your HTML5, and then you can just run with it. Let’s say I need user X or user 125 with all of their email addresses, and it will just go fetch that data for you and you’ve got it. And then those are the, most apps that I’ve worked on, that’s all the basic stuff. And then anything after that is custom to whatever app I’m building, right?

Now, you didn’t specifically mention real-time in that list, right? But that’s also another feature.

Oh yeah. Real-time is in that list, too. Yup.

Did I miss it? Did you name it?

I did name it.

Oh.

[Chuckles] That’s alright.

He was just being polite. [Laugher]

Get your head out of the calculus and back into [inaudible].

Come on, man. I can’t answer those calculus questions, but I did get that one. [Laughter]

So, I heard recently that one of the things that makes backend as a service less applicable in certain scenarios is if you need data that has any kind of relationship. Discuss.

Discuss. [Laughs] I’m not sure how that would make it less applicable. Most data needs relationships, right? And so, if you go look at these services, they all provide a way of tying things together. It’s pretty much the NoSQL argument of relationships. It’s how you structure your data to create that relationship. A lot of these are built on NoSQL and you have full access to getting that data in and out and setting up the relationships that you need between objects.

Yeah, I was going to say, I fiddle around a little bit with Parse and I’ve looked at some of the other ones, but I haven’t actually used them. Yeah, I mean really what it is, is some of them have referential features. So, you essentially say, “This references that,” and then you could just use them. And then you’ve got other things where you put the references in and then you have to go look up in the other API endpoint.

So, users and posts, just as an example. And so, in some systems you would go and you would look up posts and it would index across them based on their user id. And in other systems it would actually do it the other way. So, you could just go and do users and then it would give you the link to the endpoint that would pull it. Or it might embed them or whatever. And it just depends on how it’s set up and what you want to do with it. But they all work a little bit differently. And so, there are definitely tradeoffs between them.

Yeah, that’s absolutely true. So, as you go looking at different backend as a service technologies, you got to really focus on what you’re trying to get out of it. What do you need in a system? Some of the reasons that you should look at backend as a service, maybe we can go into that. Would that be helpful?

Mmhmm.

So, some of the pros are it’s a faster time to market because you’ve already got the whole backend written. There’s lower cost. It’s a lower initial cost because you don’t have to pay your backend engineers to build anything. And you can share the resources across different applications. So, you could easily share that same backend with iOS, Android, and a frontend app. And you can do that with your regular backend as well. But the nice thing about a backend as a service is it will generate the API for you based on your backend that you’ve configured.

Another thing, so it’s easier to manage and you don’t have to go maintain those servers. There’s less general maintenance because there’s less code. If someone’s already written that code and tested it fully, you don’t have to maintain that at all. And then you get all the benefits of platform as a service as well, so easy scaling built in, service management, and you need fewer developers, things like that.

Of course, there are pros of just writing your own backend. And that would be, if you need something that’s really custom or you need it to be super performant, if you need full control over every little bit or some special security concern that none of the backend as a service providers give to you, those are all pros of writing your own backend.

So, one of the things that really concern me about this pattern is vendor lock-in.

Ah.

Can you comment on that? For example, one of the examples you just gave is what if I suddenly, when I start my app, I don’t have this special security requirement or this special control that I need. But then six months into my app development I realize, “Oh no.” [Chuckles]

“I can’t do this with my backend as a service. Now I’ve got to rewrite the whole thing.” Is that true or is there a better way out?

You know, that’s a fantastic question. I’m a big fan of open source and there are quite a few open source backend as a service solutions that if you start with one of those, you don’t have to worry about that at all because you could, it’s written with standards already that you could just take the system, call it your own, change everything to work the way you need it to and be good to go.

So, at that point, you’re deploying your own backend as a service with one customer, and it’s you, right?

Exactly.

But that’s a price you have to be willing to pay, because I’m sure that these backend systems are costly to maintain and to deploy and whatnot. And now all those concerns are on your lap, right?

They are to a degree, but not as much as you would think. So, they’re actually built to be easy to deploy. So, let’s take Apache Usergrid for example. So, Apache Usergrid was actually created or purchased, I’m not sure, but Apigee a couple of years ago. And then it was donated to Apache. So, it’s an incubator project there right now. Well Usergrid, I can’t find the quote right now, but it’s currently being run by Apache Telecom on thousands of servers and has auto-scaling across all of that. So, if you want another Apache Usergrid server, you just spin up a new VM and throw Usergrid on there and tell it where the cluster is.

That’s my understanding. Don’t quote me on that entirely. I haven’t worked with Usergrid in that big of a situation. And then, but Usergrid is built on a full Java stack. So, if your teams are familiar with Java and you get that situation where you need something super custom and you can’t do it within the framework that Usergrid provides, you can just take that system, spin it up in an IDE and make your changes on your own and then redeploy it.

Okay. Would you say that this kind of service is particularly attractive to mobile developers and that there’s more adoption in that community than there is in the single-page app web development community?

Oh yeah, definitely. So, this is coming to a point of maturity within the mobile community. Are you all familiar with the Gartner Hype Cycle?

No.

Yes.

[Chuckles] So, I’ll explain a little bit. So, this is just a, there’s a little graph. Go look it up, Gartner Hype Cycle. And any new technology that comes out goes through this cycle where it starts. Nobody knows about it. People start learning more about it more and more and more, and then it gets to this peak where people are just in love with this technology. They think it’s the most fantastic thing out there.

And then there are all the naysayers coming and saying, “Oh, it’s horrible because of this, that, and the other.” And so it goes through what Gartner calls the trough of disillusionment where people are unhappy with it. They think, “Oh, it’s the worst thing ever.”

And then people realize that, “Well, it’s not the worst thing ever. There’s just some different ways of working with it than we realized. It really does provide value.” And so then, it comes to people start using it more and more again to what they call the plateau of productivity. Fancy words, but essentially it just becomes a mainstream product that people use.

And I’ve seen this firsthand with NoSQL. I think people can say that in general with NoSQL, is it came out and a lot of engineers were just super excited about it, super excited about everything you could do with it. And then came the naysayers saying, “Oh, but it doesn’t persist all your data. There are all these problems with it. It’s not great.” And now, it’s come back to something that’s in common usage and is used all over the place.

So, am I the only one who thought of Lord of the Rings with the Gartner Hype Cycle? Like first you have to ascend the peak of inflated expectations and then flog through the trough of disillusionment, finally climb the slope of enlightenment and then you reach Mordor. [Laughter]

And then you throw the ring in? [Laughter]

That’s awesome. So, now that we’re at Mordor with NoSQL, I don’t think we’re there with backend as a service. What I was going to say with that is with the mobile specifically, I think they’ve been through the peak of expectations, just at the peak of that, and they’ve gone through some of the trough already and it’s starting to become commonly used. I think in frontend web application development, this is brand new. People are still learning about it. They don’t trust it. They’re completely happy writing their own backends at this point.

Yeah, because two, three years ago we were all doing that. We weren’t writing single-page apps.

That’s right. That’s exactly right. So, this is all really new.

And I think it’s interesting because as web developers, I think we’ve often conflated the idea of the backend service with the same service that has to host our frontend code. And in the mobile world, they haven’t done that because it’s simply not possible, right?

That’s right. That’s a great point.

And so, these mobile developers are like, “How do I get a server?” And they’re like, “I don’t have any idea how to do that.” But these frontend web developers are like, “Oh, I know how to do that. I’m a Rails developer.” [Chuckles]

Like, “I know how to build my own service, my web service on the backend.”

Yeah, that…

I actually think that as a web developer, we would do well to decouple the notion of your backend web service and the servers that serve up your HTML and your JavaScript and your CSS, because I think that that will best poise you to scale. And you can deploy your web app on a CDN or something. And then the backend services are just totally separate. And the two can be deployed independently and just, everything’s wonderful. And that’s how mobile apps are, just by their nature.

Yeah. That’s exactly right. And that’s what I see happening with so many single-page applications and so many different frameworks coming out for single-page application development, is again with abstraction we’re moving to focusing more on what our users care about, which is the interface. And if you can do that, like you’re saying, split your service out so it’s a completely separate thing, then why not move it to a backend as a service?

So, what about the issue that on a mobile device it’s a lot harder to hack in and intercept anything, but on web it’s much simpler?

Oh, security.

Yeah.

Yeah, security is a great question. So, all of these, I mean if you go to the Firebase site, one of their top things that they call out is how secure their solution is. And it is secure. It’s all based on OAuth and grabbing your tokens and then setting up a communication between your frontend and your backend. And so, they handle that. Each of these systems handles it. If it doesn’t, I sure wouldn’t use it. [Chuckles] Does that answer that?

Yeah, kind of. I mean, what about something simple like just validation of data entry fields and things like that? How do they handle scenarios like that where you can go in, not matter what kind of validation I put in JavaScript, somebody can still go in and change a value using a console before they click the save button, right?

Yes. What they’ll do, again I’m going to use the Firebase example because it’s the easiest to explain, they have a validation schema that you just take a JSON-like object that contains your validation for all of your endpoints. And you configure that within Firebase itself. So, you go and say, “Endpoint user/create new user is only accessible to,” and you put a string of JavaScript in there that describes what you want it to be accessible to, who you want to be able to write to that, who you want to be able to read from that endpoint, whether or not you want the endpoint to be public so anyone can get that data. So, it’s all configured within the backend as a service system.

And then can you also say things like, “This field within this endpoint has to be an integer between 10 and 30 or something”?

Yup.

Does it go that level of detail?

Absolutely. In Firebase specifically, it’s just JavaScript. It’s like an if statement.

Can you actually write JavaScript on the server side in Firebase to do validation?

For the validation, yes.

That’s awesome.

It’s within, it’s wrapped in their own custom way of setting things up. But yeah, it’s just JavaScript.

I imagine they’re really going to have to grow with that kind of concept a lot, because only the most trivial of applications have even simple validation that doesn’t require…

Yeah.

Just some logic.

Right.

That’s dynamic in nature. So, that’s one of the reasons I’ve really been hesitant to embrace these ideas for big projects that have a long lifespan expectancy. But for these quick projects where you want to get off the ground quickly, it makes a lot of sense to me. Maybe they’ll grow with us.

There you go. There you go.

Well, I did an episode of The Freelancers’ Show, myself and the other panelists did. And we talked to a fellow by the name of Kurt Elster and he talked about how he builds these teeny apps that you could build in an afternoon and launches them. And then he monetizes them essentially by putting Google AdSense on them and stuff. And so, it did occur to me that something like this could shorten the development cycle on something like that to the point where you could just put something together.

I am a little bit curious, I have to admit, about the OAuth stuff that you mentioned. So, is that how people authenticate to your app, is they provide an OAuth endpoint and then you can scope the data accordingly? Or how exactly does that work?

So, I’m going to use the Firebase example again. Their documentation is great. But you have a couple of different options. With Firebase, you can have them, you can use an OAuth login to one of their Facebook or to Google Plus or to any of those and get the token back and the server handles that and then handles the communication to the application. Or you can tie it, and I can’t remember if Firebase does this, but I know that many of the others do, you can tie it to LDAP if you want some internal enterprise thing. Or you can set up your own users system within the application. That’s the most common scenario if you’re not doing a social login, is to use your own users within the system. And I don’t think I’ve seen any of these that don’t provide that out of the box.

But the actual ins and outs of it and how it functions, I can’t explain that easily over a podcast. So, I’d recommend just pulling up the site, any one of these, and looking at how their security works.

So, do you see this becoming as ubiquitous as platform as a service?

I do. One of the biggest challenges I think is mindshare. And I think it’s the same thing that happened in infrastructure as a service, and the same thing that’s happened in platform as a service. Ten years ago, if you talked to you IT guy who ran all your servers and he said, “Hey, we’re going to take all of your servers and we’re going to let Google handle those,” or whoever the company was back then. He would have said, “No way. I’m not giving up control over these. These are my babies. I know how to build these and keep them running fast.” But look at it now. If you talk to any IT group, if they’re still running their own servers, it’s either because they have some government restriction that they have to or they’re just very outdated. [Chuckles]

No, it happens a lot in big organizations, too. They often still run their own servers. But for the small groups, small fry starting up your own shop, you don’t have to go out and hire IT guys. People can spin up their own servers easily. Same with platform as a service. You don’t have to go hire people that are super knowledgeable about scaling and reliability and security and also Linux administration. You can just spin up and deploy your application to Heroku or many of the other platform as a service vendors and scale it just with the touch of a button. So, I think that backend as a service is definitely next. I view it as a disruptive technology because you don’t have to pay for those fulltime backend developers. You might still have to pay for a person to manage it for you and to be the expert. But you don’t have to pay for a whole team of people to manage the backend. Now, are we there now? No, I don’t think we’re there quite yet. I think that…

But…

Go ahead.

Well, you are saying that anybody who’s not looking into backend as a service right now is an idiot. [Laughter]

Yeah, I think I did hear that.

Pretty much, yes. Yeah, I think that’s what it is. [Chuckles]

No, I know a number of companies who have made the switch either entirely switched their backend or they’re switching pieces. So, there’s one company local to where I live that has switched their user authentication entirely over to Usergrid. I know another company that is looking at, oh what’s the name of that one, [inaudible] as a way of managing their backend system for doing web analytics and the web analytics that they provide to other people. And so, I think that there’s a lot of value to be found within this area, within backend as a service ecosystem. But right now, it is difficult to find the specific value for you, for the reason that there are lots of services out there. And also because we have this cognitive bias against giving up something that we love, something that we own.

Those developers who were working on the backend for the systems that moved to backend as a service, did they get fired? And if so, are they looking for a job because I’m desperate to find some good people.

[Laughs] You know, I don’t know. I think that they just moved up to a different level, right?

They moved up to the frontend.

I don’t know about those specific companies.

Question for you about data security. So, moving your backend to a backend as a service system seems like it would increase your risk service a little bit. For example, if I’m on Amazon EC2 and I’m running my own backend with my own database and stuff like that, then it’s my job to protect my data. But if the VM who happens to be on the same hardware gets cracked by some attackers, my data is probably safe. But if a backend as a service system gets attacked and there becomes a data breach, isn’t it a much broader risk for all of the backend as a service subscribers?

Yeah, that’s a valid concern to think about. That’s where I think the open source vendors are going to pick up a little bit quicker. They’re going to take off a little bit quicker, specifically in the web application development because you can take any of these systems, these open source systems. You deploy yourself onto VMs like I was talking about. And so, you already own that database. It’s not like someone’s going to hack Apache Usergrid. They don’t have any core servers anywhere that they can hack to get your data. It’s all your servers. Same with BaasBox, LoopBack, Deployed, Helios. These are all some open source vendors for backend as a service.

Now, to defend a little bit the commercial vendors, this is their core business. They care a lot about keeping that data secure, because if any leak happens, nobody will trust them anymore. And everyone’s going to leave. So, they put a lot of energy into making sure that their systems are secure so that no worries get introduced into the marketplace.

Yeah, I think the other thing to keep in mind is that if they structure it properly, then your database will probably be encrypted with a separate key than the other folks and things like that. So, even if they break into the system and steal a bunch of data, they’d have to steal all the keys and then they’d have to go through and decrypt each database one by one.

Oh, makes sense.

So you know, there are a lot of security measures that they can take that can mitigate a lot of the issues that you’d be concerned about. And so, it really just comes down to how well they partition the data, how well they partition security, and what measures they’ve taken to make sure that people can’t just get in.

Yeah. Well said.

And you know, it’s definitely a buyer beware, but go out and really have a good look at what they say they’re doing and what the risks are.

I totally agree. [Chuckles] I really think everyone should be looking at this to some degree, because it is such a potentially disruptive technology. Because if a startup comes in, in your space, and they’re doing the same thing you’re doing but they don’t have the overhead cost of 10 engineers writing a backend and they can move faster because the backend is already written or super easy to configure for what they need, then you’ve got trouble as a business. And so, I think it’s definitely worth looking at.

It probably sounds like I’ve poo-poo’d on the idea of a backend as a service in general. But it’s not true. I think they’re really appropriate for young projects that you want to get off the ground quickly. Why bother concerning yourself with the backend on a quick startup kind of project where you want to get going?

Yeah, exactly.

It makes a lot of sense, I think. You really have to convince me not to use one of these services for a project that I don’t even know if it’s going to exist next week.

What if I gave you five bucks?

I’ll do anything for five bucks. [Laughter]

Yeah, I think it really comes down to be informed and use the right tool for the right job.

The other area where I think this is really beneficial is for new developers who are learning. I’ve seen developers build really cool applications as they’re teaching themselves how to code. Like you just picked up a book on HTML and JavaScript and with nothing else, without a backend as a service, you’re stuck. There are a lot of technologies, like you said, to get started. But this really helps you jumpstart that and get going. So, I think for new developers it’s a great tool.

Yeah, it really removes that mental overhead.

Oh yeah, especially Firebase. I think they’ve done a particularly good job at getting that going. As a new developer, you’re probably going to make a lot of mistakes with it and have security problems and whatnot. [Chuckles]

But at least you’ll get off the ground and get your stuff going, you know?

That’s right. And Firebase is really geared toward the JavaScript application developer. It’s one of the few that started from the get go being geared toward JavaScript. And so, I think you’ll see others coming to the market that are equally as good in that way. If you’re trying to learn iOS development and you need a backend, same sort of thing. There are lots of services out there. You can just get going without having to worry about them.

Alright. Well, anything else that we should go over with this, things that we haven’t considered, before we get into the picks?

The key to me is complexity gets abstracted and things move up the stack. That was a quote by the Heroku CEO. But with complexity continuing to become abstracted, we need to be sure we’re ahead of things so that we don’t get booted out of the stack.

Isn’t he the same guy who said, “With great power comes great responsibility?" [Laughter]

Yeah, probably. That’s it. We’re going back to Mordor. [Laughter]

Ooh, that’s a cool mashup, Spiderman in the Lord of the Rings universe. [Laugher]

Oh, there we go.

Yeah, I like it.

Where do I sign up?

I’m already starting my Kickstarter campaign. [Chuckles]

Awesome. Alright, well let’s go ahead and do some picks. Dave, do you want to start us off with the picks?

Sure. I have two picks. One of them most people are probably already familiar with, but I wanted to pick it because I used the service recently and really enjoyed it. And that is Airbnb which is an online service for basically staying in other people’s homes and apartments when you travel, instead of hotels.

Plus one.

Most people are familiar with it. I have not used it but I am going to use it at the end of this month for the first time. So, I’m a little nervous. But the process for getting signed up and everything was really cool. And I like their UI and I really enjoyed it. So, that’s my first pick.

Is that something you do with or without permission? [Laughter]

Okay, so a competitor Airbnb would be a website that tells you when your neighbors and friends are going to be out of town so you can steal their apartment. [Chuckles]

Nice.

Yeah.

So, my second pick is actually a vim plugin called Align, A-L-I-G-N. And this plugin appeals to me because I am OCD with how I layout my code. So, if I’m writing a JavaScript object literal and it’s got a bunch of keys on the left and colons and then values on the right, I like those to all be vertically aligned with each other. And the Align plugin lets me select a block of text from a JavaScript object literal and hit the Align command. And poof, it lines them all up. So, I can be OCD and fast.

Does it say, “Poof”? [Chuckles]

Joe, what are your picks?

My first pick is going to be Xanax for people with lots of OCD. [Chuckles]

Dave, that was a jive at you. [Laughter]

Got it, I got it, message received. [Laugher]

No, that will not be one of my picks. I’m going to pick a TED talk given by, he’s the conductor of the Boston Philharmonic about appreciating classical music. And it’s one of those talks that’s just absolutely amazing. The guy’s name is Benjamin Zander. He gives the talk. It’s just the most beautiful, wonderful, and incredible TED talk about appreciating classical music. And his whole point is anybody who doesn’t appreciate classical music just hasn’t been exposed to it the right way. And his whole talk is about this. And it’s a great example of just a great talk in general. And also, it’s got beautiful, amazing music. And the way that he presents the topic is just so compelling. So, that will be my first pick.

My second pick will be a new book published by the guy who writes the ‘What If?’ comic, and it’s the ‘What If?’, sorry the XKCD comic, and he also publishes a weekly ‘What If?’. And it’s a book about what ifs. So, it’s him republishing some of the articles he’s already written from his ‘What If?’ which is basically readers send in what if questions and he’ll answer them, things about science and physics. You know, like “What if you had all the money in the world?” for example is one of the questions. And he talks about what it would be like if all the coins and paper money in the world was consolidated to one physical spot, what that would be like physically. And very interesting stuff. So, it’s a book. You can get it on Amazon. And if you have Amazon Prime, then it’s free. It’s one of those free books you get with the Prime upgrade. So, that’ll be my second and final pick.

Awesome. Merrick, what are your picks?

So, I have three picks. First is the Das Keyboard with brown switches. It’s relatively new. It’s awesome, because it’s got this volume knob on it which just makes you feel legit.

The second one is this Chrome plugin called Momentum. And it’s this like, I don’t know. It’s a prettier new tab page but it’s pretty cool.

And my last and most important pick is that it’s actually going to be International OCD Awareness Week.

Let’s see, the 13th through the 19th. But yeah, if you don’t know much about OCD or what have you, about one in a hundred adults actually have it. So, it's something worth becoming aware of.

So yeah, that’s the last pick.

Alright. Well, I’ve got a couple of books I want to pick. The first one is a fiction book. It is ‘The Emperor’s Soul’ by Brandon Sanderson. I enjoyed it. I thought it was good. I’m not liking it quite as much as the Iron Druid Chronicles, but it was enjoyable.

And then the other book is a book that is a classic. It’s called ‘Think and Grow Rich’ by Napoleon Hill. And it is so good. [Chuckles] But yeah, I’m almost done with it and I’m going to go back and re-read it as soon as I’m done. I’m actually tempted to put together a study group where we talk about one chapter a week and do it more of a mastermind group style as opposed to an open discussion style. And the reason is because it delves a lot into who you are and what you want. And I want people to feel like they can talk about their business or their life or whatever else they’re working on and do so in a confidential setting. And so, we probably will use Google Plus or Skype or something for the discussions. But anyway, if you’re interested in something like that, you can email me, chuck@devchat.tv. And I would be delighted to put something together. Those are my picks. Ryan, what are your picks?

So, I’m going to pick WebStorm first of all. I absolutely love the WebStorm IDE in all of its flavors. Depending on if you do Ruby or Java backend, they’ve got different IDEs. But those guys at JetBrains make an awesome, awesome tool. So, that’s one.

Next one would be the Traveler Guitars. Have you guys ever heard of these? They’re a small guitar but with a full-size neck. I don’t know if any of you play guitar. But they’re awesome. I’ve picked one up and I use it to practice during lunch. And I can just plug my earphones in, flip a switch so I’ve got distortion, and just rock away. [Chuckles]

And then my third one is Zion National Park. I hadn’t ever been there until earlier this year. But oh my gosh, it was the most beautiful national park I’ve ever been to. I got there early in the morning. The sun came and the shadows on the canyon walls were just amazing. If you know about the sublime, it was just awesome, almost a spiritual experience. So, I highly recommend Zion National Park. There you go. Those are my picks.

Alright. Well, thanks for coming Ryan. If people want to get a hold of you, what are the best ways to do that?

You can get me on Twitter at pickledego. Awesome. Well, thank you guys very much for having me.

I appreciate it.

Yeah, thanks for coming.

Yeah, thanks man.

Thanks, Ryan.