02:24 - Robert Damphousse Introduction

02:40 - OAuth

07:15 - Stormpath

08:38 - Authorization Information Storage

11:29 - Stormpath Authentication vs OAuth Authentication

14:43 - Caching 

15:41 - Building Backends as a Service?

18:21 - Security

19:12 - Using Cassandra

20:27 - Use Cases

22:27 - Authentication as a Service 

23:40 - 2FA (Two Factor Authentication)?

24:07 - REST APIs

25:39 - Making Complete Apps

26:33 - Security (Cont’d)

27:34 - In-Between Layer (Authentication API)

28:40 - Browser-Based vs Mobile Application Use

29:44 - Angular, React, Flux, 

32:02 - React Native?

33:05 - Stormpath Life Expectancy

35:09 - Customers

36:12 - Active Directory, LDAP (Lightweight Directory Access Protocol)

37:05 - Support and Pricing

Picks

Putting the "fun" back in "funeral"! Celebrating the death of old IE browsers on January 12! (Dave)
 Giant Star Wars LEGO Super Star Destroyer Shattered at 1000 fps | Battle Damage (Dave)
GitLab (Dave)
Allen Pike: JavaScript Framework Fatigue (Aimee)
The Cult of Work You Never Meant to Join (Aimee)
Serial (AJ)
HotPlate (AJ)
Design Patterns in C (AJ)
OAuth3 (AJ)
JS Remote Conf Videos (Chuck)
Ruby Remote Conf (Chuck)
Traction: Get a Grip on Your Business by Gino Wickman (Chuck)
Startups For the Rest of Us (Chuck)
The Guest House: A Poem (Robert)
The Hiring Post (Robert)
Front-end Job Interview Questions (Robert)

Special Guest: Robert Damphousse.

 

I just want to give you guys a heads up. International Talk like a Pirate Day in September. Watch out.

Yes!

Hey everybody and welcome to episode 160 of the JavaScript Jabber show. This week on our panel we have AJ O’Neal.

Woohoo! Yo, yo, yo, I’m coming at you from a windy backyard.

Dave Smith.

Greetings.

Aimee Knight.

Hello.

I’m Charles Max Wood from DevChat.tv. And this week we have a special guest and that’s Robert Damphousse.

That’s me. Hey, you guys.

Do you want to introduce yourself real quick?

Oh, my name’s Robert. I live out in the Bay Area. I’ve been doing JavaScript since before it was cool. Right now I’m working at Stormpath. We’re down in San Mateo. We’ve got a pretty cool user API. So, I suspect we’ll mention some OAuth at some point in this conversation.

So, I like OAuth. And AJ was baggin’ on OAuth. And you kind of agreed with him. Do you want to explain what you guys were talking about?

Yeah. So, AJ was baggin’ on it for the same reason everybody does which is it just seemed overly complicated, which it is if you…

That’s fair. That’s totally fair.

Yeah, it is. It’s just kind of a weird spec where they tried to encapsulate a lot of ideas around not only authentication but also access control. And it’s just awkward because they have pretty strict specs around pretty banal things like, “Oh, you should use this endpoint for this thing.” But then when it comes down to the juicy bits like how are you going to persist identity assertions, they’re like, “Oh yeah, that’s totally left up to your control. Do whatever you want.” And it’s like, “Whoa. Come on, guys. That’s not much of a spec.”

I’ve got a little bit of a different take on it. Same complaints there, but my core problem with OAuth 2 is it’s not discoverable. It’s not delegate-able. It’s not federate-able. Right? So, back when this whole war started, it started with OpenID. And OpenID was great because it was all of those things I just mentioned. It was terrible because it required a user to run their own website. And we all know that that’s not going to happen, or at least… I don’t know. I think it might happen one day. Anyway, but it required the person that wanted to use it to implement it. So, you couldn’t say Google could implement it for all of its users. It had to be you, Chuck, had to implement it for yourself. And you had to host it somewhere. And so, that’s why OpenID was bad.

And then OAuth was like, let’s make things enterprise-y complicated. And then OAuth 2 was, let’s be a little less complicated. But in neither of those specs did they define how two systems would communicate to each other. So, when you want to implement OAuth 2 for Facebook you have to get your OAuth Facebook gem or your OAuth Facebook npm module. And then the same thing for Google and for Pinterest, blah, blah, blah. There’s no definition to say, “Hit this endpoint/OAuth to discover how to do user authentication and what permissions are available. And then hit that particular endpoint that you discovered to start the process and continue the flow.”

Mmhmm.

It’s like you have to know private implementation details of every single thing you want to connect to, which is dumb.

Yeah. It’s totally frustrating. What I’ve been seeing and I’m curious to see if you see this as well, is that one thing that people seem to be settling on is [chuckles] using the endpoint OAuth token and then using JWTs as the actual token payload for carrying the identity information. Have you been seeing JWTs pick up as well?

Well, yes but that’s because it’s something I’m interested in. So, it’s like whatever you’re interested in, you’re going to see more of it. When you buy a new Honda, you notice everyone drives a Honda. When you buy a new Lamborghini you notice everyone drives a Lamborghini. I don’t know how that’s possible, because not a lot of people drive Lamborghinis.

Last time I drove a Lamborghini, I didn’t see anybody on the road with a Lamborghini. [Laughter]

No, that’s how it is, though.

Hey, sorry to interrupt. But I be but a humble web developer and you guys be using fancy words.

Can you help us understand a little?

Well, okay.

Like, let’s back up and talk about what all this is? A little introduction for people who may not know what is OAuth, other than the thing that AJ likes to bag on.

Facebook Connect.

You click login with Facebook, magic happens. Your server has a validated session that says Facebook says you’re a validated user. And so, you trust that and you move forward and you can grab their profile information. That’s in a nutshell. Facebook Connect is OAuth.

I always have to look for any [inaudible]. I’m very visual. So, there are good diagrams on it. It’s just like a series of handshakes. It’s how I think of it.

Yeah.

And it’s passing back and forth.

It’s about getting access to a resource without requiring that person to present their typical username and password directly to you. They authenticate against some access control server. And then beyond that you can use other mechanisms other than username and password to get information about that user with limited scope. That’s one aspect of the OAuth specification.

So, you’re saying it’s like the pirate code. “A bit of a guideline.”

Yeah.

A bit of a guideline.

Just tell me know if you want me to stop doing my pirate impersonation.

No, I like the [show]. [Laughter]

Okay, I can keep going.

How about talking about what Stormpath is?

Yeah, so we’ll come back to OAuth later. So, Stormpath is basically, it’s an API service, so it’s software as a service. So, you use our REST API to store sensitive information about users. Obviously the most sensitive thing being their passwords, right? So, you store that basically in our cloud data store. And then you do authentication attempts against us. So, the way I describe it is that user table that you threw in your MySQL database at the last minute because you’re like, “Oh man, I need to let people log into my site,” you basically take all that out of your infrastructure and put it behind our API. So, that’s the core feature that we do. And there are some cool stuff around that. We can handle sending password reset emails to people and stuff like that. So, like all the CRUD you have to do around a user registration system, we’ve modeled behind an API which is pretty sweet.

But this year we’re getting into some of this OAuth and API authentication stuff, which is pretty cool because I have been using SaaS products for a long time. Being a web developer, it’s so common to use other people’s APIs now. So for me, it’s quite fun to work on that kind of a product and also help people with authentication and security issues around their APIs. That’s the Stormpath and my position in a nutshell.

So, in addition to storing, excuse me if I get the terminology wrong, authentication information, do you also allow apps to store authorization information?

We do. We don’t have a structure around it yet. Basically, any resource in our system, be it an account or a group or a directory or an application has a custom data object, which is just a freeform JSON blob that you can put whatever you want into it. So, we provide that to a lot of people to build their own access control rules. We don’t yet have a specific data model or a scheme for that. We basically find that everybody has a very different use case. So, before we bake that into our model we’re just providing this custom data object and getting a feel for what it would look like if we were to bake it into the core REST API.

So, here’s a thought. I’d like to go back to email. Email I something that just works and I love it. It’s federated. It’s a standard protocol. Everybody knows how to do all the things. Obviously we build these web apps because the thing that we want doesn’t exist exactly the way that we want it. But there seem to be some common APIs that over the past decade have emerged everywhere. There’s an alarms API. There’s a messages API. There’s a contacts API. And every single device and every single app implements it in some way. So, it feels like for some of these things that are really esoteric, it’s just going to be custom and you‘re never going to be able to define it. But for some of these things that are on every single device and every single app, there should be some way to converge and be like, “We’re just going to follow this methodology that seems to work for these cases because they’re well-defined cases.”

Mmhmm.

Thoughts?

Yeah. Are you asking has there been an effort at defining an access control scheme or a model?

Well, not necessarily in general for everything. But just looking at these most common types of resources that are accessed. Because I don’t believe that we can do it for everything. But I believe we could do it for the most common things.

Yeah.

What are your thoughts?

Well, at the basic level most people just like to keep it simple and use the concept of a group. So, the way that our data model works is most people just want to keep it as simple as that. If user in X group, this means something. So, as a higher level convenience in some of our SDKs and framework integrations, we provide little rules like that. For example, in our Express.js integrations we have middleware that says, groups required [inaudible] and you pass it either one or a list of groups that the user must be in. So, at a higher level outside of our API we provide some conveniences to do those assertions, yeah. Is this the kind of stuff you’re asking about?

Sure.

Yeah. That’s pretty much the one thing that everybody agrees on, is a user is going to be a member of one or more groups and that means something.

So, I’m wondering. We talked a little bit about OAuth, but what is the difference between the way you handle authentication and the way OAuth does it?

So, in a typical situation, let’s talk about a web app, a browser based app. Is that a good place to talk about it?

Mmhmm, yeah.

Okay.

It’s a JavaScript podcast, so I think that’s safe.

Yeah. So, the typical thing we’re all used to writing is you submit a form with your username and password. And then you get a cookie with some opaque identifier, right? And that ties you to some session on the server. Where OAuth can take it further is you’re not just getting this opaque session identifier. What you’re getting back is actually an access token that basically, it grants you access to the thing that you have access to. So, it’s a lot more descriptive.

So for example, when we issue tokens from, let’s say we’re talking about our [inaudible] integration. Rather than just sending a cookie identifier we actually shoot you back an access token following the OAuth handshake. And that token basically declares who you are, meaning the user ID. Again, still an opaque identifier but it’s a user ID. And then within there you can put scopes. So, this notion of scope is pretty big in the OAuth spec. It’s the way of saying, “Hey, you’re allowed to access these things.” So by default, we don’t add any scopes. We basically just say, “You are this person,” and then it’s up to your server when it sees this incoming access token to decide what it wants to give the person.

But coming back to the groups example, a very common thing that people want to do is pass along a list of groups as scope. So, this is where it gets really cool. You have this self-contained cryptographically signed piece of information that is… it’s still sitting in that cookie. And you can just pass it along to the server. And as long as the server has a private key it can verify this token with, you don’t even have to go hit your database. Just like, this person is this ID and they have access to these groups. So, that’s where OAuth is really sweet for a lot of people, is it helps you rejigger you architecture to not use your user data store as often as you need to.

And I’d like to add on that. OAuth is this big thing, right? There are at least four strategies that get used in the wild. And then there’s a couple more in the definition that no one actually uses or implements. But you can start off reaping the benefits of this type of system by just implementing the strategy for granting tokens with password authentication. You can take it piecemeal. It’s not like an all-or-nothing where you have to implement all of the OAuth spec or none of it. You can add a route for an access token that is a password grant and it’s just a couple of query parameters. And you can start building a better architecture that way. JWT is awesome. [Inaudible] client side tokens so you know whether or not the user is logged in without hitting API is awesome.

Mmhmm. Yeah, that’s a really good point. Thank you for bringing that up. Most people see OAuth and freak out because it’s so big. But you can start super simply just at the username and password flow. They call it the password grant flow, basically. So yeah, we get a lot of people that ask us, “Oh my gosh. Do you guys do OAuth?” And it’s like, “Well, what part of OAuth?” [Chuckles] So, it’s a big spec.

Yeah. Resource owner password is the formal name of the strategy that you would use on your own website, like a first-party site.

Yeah.

So, do you find that people who use Stormpath, they will cache user information in addition to querying it from your API?

Yeah.

First name, last name, stuff like that?

Yeah, totally. So, if you use one of our SDKs actually, which is basically just a nice convenience wrapper off of making just raw HTTP calls, we actually handle all that caching for you. So, because our API is designed very RESTfully, it’s super easy just to cache everything. So, by default I think we set, I want to say five minutes on all resources. But then you can control it pretty fine-grained. I think we even let you set different cache control, TTLs for different resources. So yeah, everybody wants that so that’s just something that we baked into our SDKs by default.

So, a common flow is somebody will login, get issues with an access token, and then they’ll just keep checking that access token until it expires. At which point either the user has to re-login or some other flow. So, there’s a lot of different ways you could control how often you hit our API, which is pretty cool.

So, can I wax philosophical with a question for a minute?

[I’d love to].

Oh yeah, philosophy. We’ve talked a lot on this show about backend as a service. And we’ve talked a lot to different service providers for different, the backends. Some backend as a service providers provide the whole enchilada including authentication and lots of other services. Stormpath of course is just focused on authentication and authorization. But do you think that web, browser app development in the future is moving to a world where people can piecemeal build their own backend as a service portfolio? Like for example using Stormpath as the API provider, maybe Firebase as the database persistence provider, and so on. And you just build this up. Do you see that happening?

Yeah. I do, actually. That’s how I came to be at Stormpath actually. in my last startup we were iterating and prototyping different ways of building classrooms online for teaching English to nonEnglish speakers. Year after year that went by. We started using more and more API services, because whether they make sense in the long-term for scalability and cost analysis, that’s always a decision that everybody has to make individually. But when you’re small or prototyping it absolutely makes so much sense. Because you can put together a fully-featured product basically just using other people’s APIs.

So, whether… going forward I would love to see more of this just because I think it’s so cool to be able to piece stuff together without [chuckles] having a DevOps team. That’s pretty awesome. Once you get to scale, that’s where the big question mark comes in. Is that philosophical enough? I could keep going.

[Laughs] You’re pretty good.

Any other web developers in the room want to talk about that?

So, I definitely think that no backend is where we want to be. We want to have all the APIs that you have on a phone. We want those in the browser. We want to be able to set an alarm, to send a text message, to send an email. If we want to do that on the client side we want the permissions to be there. I definitely do. That’s one of the things I’m working towards. And the stuff that I’m creating is making that easy. Because if you take the barrier to entry down to JavaScript where every single person in the world has a device, if they have and electronic device they’ve got an electronic device that runs JavaScript on it. And so, if you can bring that barrier to entry down to a language that’s so flexible albeit sometimes terrible that everyone has access to, we can explode more and more development, more creativity, more solutions.

Mmhmm.

And potentially more problems. [Chuckles]

You’re talking about CoffeeScript, right?

No, that would be one of the problems, yes, yes. [Chuckles]

That would be one of the problems.

So, is that all there is to Stormpath? Just storing user information and authentication?

Yeah. We’re really focused on that piece that applications need. It’s like, in this task-based world, like you’re saying, there are companies out there that do everything. But we’re really focusing on this one part and trying to do it really well. Because on the surface people think, “Oh, just user information. That’s all?” But there’s actually a lot of complexities in that especially when you start thinking about all the security around how you’re securely storing the actual password, how you’re salting it, how you’re hashing it, things like that.

There’s a lot of stuff that we do behind the scenes that need all kinds of security compliance requirements that the average web developer doesn’t have to think about. But as soon as your application becomes important, you start getting these B2B conversations where people are like, “So, how secure is blah?” Then you have to start thinking about these things.

So, speaking about behind the scenes stuff, I was looking at your blog and saw that you guys recently migrated over to Cassandra. That’s actually one of the databases that I use where I work.

So, I was curious about your decision to go to that and why you use that and how you use it.

So, I’m not on the backend team. But I can talk a little bit about my understanding of it. And basically, because we are a REST API and everything is essentially a node in a graph, Cassandra makes a lot of sense for that situation when you need to… gosh this is [inaudible] so I’m doing my best to talk about this here. But it has to do with the way our data is structured. And we want to start implementing some pretty awesome search criteria across stuff in our graph, be it an account object or the custom data properties. So, my understanding is that Cassandra’s going to be a better choice for that kind of situation, given that we’re a multi-tenet environment where one customer may be relaly hot on some piece of the database for a while, or some other customer is not.

Okay.

Someone in the background thinks Cassandra’s really funny. [Laughter]

Oh Cassandra, are you kidding me? [Chuckles]

Can you tell us about some of the cool customers who are using Stormpath and what they’re doing with it that you think is pretty cool?

So, one of the natures of being a security minded company is that most of the people, we cannot talk about who they are.

Yeah, but it’s just us. So, you’re cool, right?

Yeah.

Yeah.

There is actually, I can’t name the name, but there is a company. They’re the largest RFID vendor in the world and they actually use us as a backend mechanism for a lot of their authentication services.

Is it McDonald’s? Every burger has an RFID?

[Chuckles] The bun.

You got to track them somehow.

Yeah.

You can go ahead, Chuck.

Related to that, what I’m thinking is, is there a use case that you can give us that just makes a ton of sense? So, it’s like, okay, you’re building this kind of app and you want to do this kind of thing.

And so, you would go through these steps to get everything set up.

I’m being completely honest. Any new project which is a web application, meaning it’s going to have some kind of browser application and some kind of data backend that requires you to identify resources on a per user basis, that’s basically it. Anytime you’re like, “Okay, sweet. It’s the weekend. I’m doing hobby project X. I’m going to build a site that does this.” That’s exactly when you should start using Stormpath because it’s so easy just to throw the whole shebang of user management in there. So, new projects are amazing.

On the enterprise side, where we get a lot of traction is people who have a lot of internal systems that have developed over the years and they have their own internal struggle which is not OAuth specific of everybody’s doing authentication in a different way. And so, they know that they want to standardize on some kind of common data model and service for storing and authenticating users. And what typically happens is they spec it out and they spec out what’s roughly a RESTful API for user management. And then they hear about us and they’re like, “Oh perfect. You guys have already done this.”

So, we run the whole spectrum there. It’s like, small prototyping projects all the way up to large enterprises who are trying to just standardize on some kind of model. They see us and they’re like, “Yeah. This is essentially what we would build. So, let’s just use these guys.”

So, another advantage there is you guys are running your authorization or authentication and some parts of authorization as your own service. And I think that’s a really good idea. I think that too often people are, well the common standard is to put your authentication inside of your data APIs. And that’s how users’ passwords get leaked, because that’s where all the complicated stuff is. And you don’t want something like a user’s password in with the complicated stuff. You want it external. You want some sort of session server that protects that really private and personal key that most users are using in other places like their email. And if somebody gets access to their email, then they’ve got access to their bank account.

Yeah. Yeah it’s very true. And when you’re using those ORM style things in the common frameworks, it’s really easy to start data hopping if you set up your relations in the wrong way. So, putting all the user auth and storage behind a very discreet API that’s using very different and very different code paths, it’s pretty awesome for reducing risk.

Do you guys do two factor authentication? I didn’t see that on the site.

We don’t yet. Oftentimes when people ask us that question, they’re already looking at somebody who does 2FA. And so, we’ll just look at how their API works and be like, “You can use it with ours like so,” because since our stuff is very, very RESTful it’s super easy to tell somebody, “Okay, get this information you need from the 2FA service and then get this information from our service and make a decision.” Go on.

Okay.

Which of the 50 million versions of REST are you actually using?

The one that makes the most sense to us. [Chuckles] There are… I guess people have tried to make specifications, right?

Yeah.

I’m being facetious. [Chuckles]

So, basically the approach that we’ve taken, if you go on our blog actually, somewhere you’ll find a link. Our CTO Les Hazlewood has actually given quite a few talks about our REST API design. So, in lieu of watching that whole thing which is pretty amazing, we really just center around the idea of named collections. So, we have in our situation accounts, directories, groups, with the idea that every resource in there follows kind of the same schema, same data format. And then if there are any relations between them, you set it up as an href link.

So for example, if you look at an account object in our system it has a directory on it, which is then, got an href link to the actual directory. So, you just set things up as discrete schema-fiable resources and then you use hrefs to link between the two of them. And then for building, it’s just kind of the job of the REST API consumer. That’s why we provide SDK just to make a lot of that stuff easier.

Alright.

I just pasted it in the chat here. I’ll link this company called, what are they called, Big Bang. So, they’re like an internet of things type thing where they’re trying to make it really easy to piece together lots of different little hardware gadgets. And they have a cool user dashboard that’s actually secured using Stormpath. And I think they’re using our custom data system to store some of the user preferences. They’re pretty cool.

So, people who are using Stormpath to build apps, what other services are they putting together to make the complete app? Do you have visibility into that?

Yeah. They’re usually using some kind of analytics platform as well, if they’re a web startup. And sometimes they’ll be using things like there’s a service called FullContact for taking somebody’s email address and trying to… do you guys know of FullContact? It’s pretty cool, actually.

No, I don’t.

It’s basically a thing that scours the web to try to put together a complete profile about a person. You just give them the email address. So oftentimes, people will use FullContact and then backfill some information.

So, it’s like Reportive or WebFinger?

Yeah. It’s kind of like that. And then Firebase also. We get a lot of people trying to integrate Firebase. Because Firebase does have an incorporated user management system but some people want to look outside of that.

So, what do you guys do to secure the user credentials and the limited amount of user data that you’re keeping? Or I guess, is it… do you actually have data with the profile or is it just the groups and access custom object?

Yeah, so any of those objects, be it the account or the group, does have a custom data field on it which is a freeform JSON field that you can put whatever you want into. Though, anything you put in custom data at the moment is not encrypted. That’s for search purposes. People usually want to be able to search across that stuff. The piece that we encrypt right now is the password. And any custom data you provide to us is not encrypted. We have a lot of customers who basically set up an encryption layer on their side. So, anything in it out of our SDK they just, they’ve got some secret key somewhere and they just cryptographically encode it.

So, instead of including an object they’ll just Base64 a string that’s the encrypted data?

Exactly.

So, do most of your customers have a layer in between if they’re using this with a web UI and then your backend. Do they have a layer in between to do that and then to also do validation?

Yeah. Some people will actually architect it that way where they’ve essentially built an authentication API so to speak between their frontend and the backend, or between two internal machine to machine services. So, Stormpath will be sort of the authentication API between the machines. So yeah, that does happen. The most common use case of that actually is people who are using, not the machine to machine thing but the frontend situation, is with our Angular integration. So, for people who are building an Angular application it usually means they have an API service as well.

Mmhmm.

So, what they’re doing is just adding in Stormpath to provide the OAuth endpoint to get a token. And then they use our middleware helpers for Express if it’s Node for example to just then authenticate the request against the rest of their APIs.

Makes sense.

Yeah.

So, can you say what percentage of your users are using Stormpath in a browser based application versus a native mobile application?

Mobile is probably the smaller bit of that right now just because people are still really trying to figure out what authentication means in mobile. Oftentimes they just defer to whatever the operating system provides or do Facebook login or something like that. So, I would say browser is probably the bigger set there.

So, on the mobile side, do you do the OAuth style handshake where it opens up a web view, redirects and comes back? Or are you doing the first-party username/password authentication where it just goes straight to your service?

Yeah, right now it’s first-party. We don’t actually have any client SDKs that integrate natively with mobile right now. Anybody who’s using Stormpath in a mobile situation right now, they’re probably just using PhoneGap and relying on our access token, cookie storage stuff. So, the username and password grant flow, basically.

So, you have an Angular plugin or a library for Angular. Do you have other integrations for other systems and other languages?

Not yet. I will say React is coming up a lot. I’m getting a lot of questions about that. So, I’m going to have to check out some React pretty soon. We focused on Angular first because it’s something that I have expertise in. I really love Angular. And it’s just something that we get lots of requests for. Because it’s like the quintessential place people are going right now when they know, okay I want to build a frontend client that is consuming my REST API and those are different systems. People who are really into separating those concerns are really using Angular right now.

Yeah. I still don’t quite understand what it means to use React in the way that people say React, because to me, React is a view component, not a framework. Ember is a framework. Angular is more jQuery++ than a framework per se. And React is more like HTML+++.

Yeah. I can’t say too much because I haven’t really dived into it myself yet. But when I look at it and I read about it, it sounds like yeah, it’s mostly about providing some kind of expressive way of having a data model that a view is bound to and will update in real-time. But it sounds like a lot of the other stuff, meaning how would I easily talk to a REST API or how will I use local store and stuff like that, it seems like that’s all pretty much up to you right now. That’s my understanding right now.

Yeah. I think it’s…

It is. It’s true.

The Flux or Reflux, Dave, you know about this right? Is it Flux is the framework that you use with React?

Flex is more of a pattern, really a design pattern [inaudible]. But you need to use React because it will change you so much that you’ll realize that you don’t really, I don’t know, you don’t even really need a framework anymore. You just need a couple of small pieces, put them together, and you’ve got an awesome way to build apps.

I always have a visceral reaction when people say, “You don’t need a framework.” Because what I hear is lots and lots of custom code that’s error-prone and untested.

No, it’s like three pieces. You need an Ajax stack. You need a build system. You need a view rendering layer. And everything else is just plain old JavaScript. And it doesn’t require hardly anything.

Okay, that makes sense.

And if you really want to get fancy, you can use a Flux implementation. But anyway, that’s okay. In fact, I was going to ask if Stormpath has been getting requests for React as well as React Native. It sounds like your Node integration…

Well, React Native sounds cool.

Your Node integration probably already supports React Native out of the box.

We are getting requests for React. But what is the React Native component? I’m not that familiar with that.

React Native is where you take the React rendering engine and instead of rendering to a DOM tree inside of a browser, it renders to (I’m putting “render” in air quotes), to a native tree of widgets for Android or iOS. So, you write code in the React style using JSX and JavaScript. And then you run it on your phone.

Yeah.

Got it.

And it actually produces an actual native app. But you can use almost any npm library.

That’s pretty cool. Yeah, I have not seen that one.

Yeah, it’s pretty sweet too. Are you guys in npm, your library?

Yeah. We’ve actually got a handful in there. We have our core Node SDK which is really the API wrapper for our REST API. And then from there we’ve got some integrations for Express and for Restify as well.

So, another question I have for you about Stormpath is that when I choose a library or a framework I have to consider certain risks. Like for example, is this project going to go unmaintained? And sometimes that happens with libraries, even whole programming languages. But even if that happens it’s not usually the end of the world for your application or your company because the code will keep working. But when it comes to a hosted service like Stormpath, if it goes “unmaintained”, you’re really screwed right away. Can you give us kind of assurance that Stormpath will be able to weather storms and stick around long enough so that I can take a bet on it and really use it in an application that I expect to have a good, long lifespan?

Oh, that’s the bet every one of us here takes, right? We’re a startup company just like everybody else. It’s a perfectly valid question. And obviously we’re striving to be around as long as we can be. But being a pragmatic programmer you should ask that question. So with any, this is just my personal viewpoint, but anytime you depend on a SaaS backend you should really spend some time understanding their data model and basically having a backup strategy in case that backend goes away. What would it look like to essentially implement that API in my own infrastructure?

Where would I host that data? So on, so forth. And that obviously means asking these questions of who the company is.

So, in the case of Stormpath, it’s how will I get my users? How will I authenticate them? And in our situation, our answer is we’ll export all the data and give it to you, as well as the cryptographic hashes that were used to validate passwords. So, you continue to authenticate counts. That’s our answer to the question that you should always ask any SaaS company, which is, if you go away, what’s the game plan?

There’s no vendor lock-in with Stormpath. You guys, you just upfront like, “This is what we’re providing. This is what you’re paying for. And if you decide to stop paying, your data is what you own and you could take it with you.”

That’s exactly right, yeah.

That is freaking amazing. Rock on, you guys.

You’re welcome.

That’s the way it ought to be. That’s beautiful.

Yeah. Yup.

Do you find that most of your customers are on a greenfield project or have people migrated to you just because they get tired of maintaining an already working system?

It’s both. It’s literally a mix of both. And then everything in between. I deal in my day to day experience because I’m really frontline with a lot of our browser stuff, I tend to work more with the greenfield projects. But it’s really cool because it gives me a chance to understand a lot of this confusion around OAuth and really negotiate what people think they need because they read about it in a blogpost versus what they actually need given the use case. That’s a really cool spot to be in. But yeah, we also as I was saying earlier have lots of larger companies who come to us either for dealing with public-facing browser security or a lot of internal stuff that they’re just trying to coalesce into something as well.

Yeah. It definitely seems like, I know for the team I’m on it’s like isolated knowledge. The one person who worked on that, everyone always goes to them when they have questions.

We also support integration with Active Directory and LDAP, if you guys are familiar with this. It’s essentially… I want to call it legacy even though it’s not.

But [chuckles] it’s…

It’s like a mechanism for having directory services and authentication. It’s been around for a long time. And what we provide is actually a way to mirror that data into a Stormpath data store, which basically means you get a REST API for read operations on top of your Active Directory in a sense, which is pretty amazing, because Active Directory is not a REST service and then you can make it that way.

Yeah, I was a Windows sys admin in a previous life.

[Chuckles] Me, too. [Laughs] I did a lot of Active Directory configurations in that previous life. And…

Oh.

I’m so sorry.

They’re easy to set up. [Chuckles] They’re not so easy to debug and figure out what’s wrong with them.

Yeah.

[Inaudible] do all the emailing for the ‘forgot password’ and things like that, do you do that yourself?

Yes.

Or do you use another service behind the scenes?

Oh, well of course yeah, of course we use another service. Who wants to deal with, you know? [Laughter]

We do not manage SMTP servers, thank God.

But yes, honestly that is my favorite feature of Stormpath is the fact that if you use this you never ever have to send a user registration email or a ‘forgot password’ email again. You just forget about it.

[Chuckles] That’s really nice.

That’s so amazing.

That’s [inaudible] [Chuckles] I assume you can customize those emails and stuff?

Yeah, definitely.

That was going to be my question, was how does the branding work out?

[I’m going to do a] check. It’s customizable after your first upgrade. I’m going to check it out right now. Yeah, custom email is at our first pricing tier. The way that our pricing tiers for Stormpath work is by API usage. A lot of other people who provide user management products in this space charge per user, which is actually, having done startups before, well you never know how many users you’re going to have this week versus next month. It’s quite infuriating. Whereas with API calls there’s always some amount of control with that.

Yeah. And it’s no bueno when you’ve got this Slashdot, slash reddit effect and you suddenly get 20,000 users but oh wait, only five of them stay on.

Not to mention that’s going to totally destroy your little Node app. So, you should totally let some other third-party handle all that looking up users in the user table and doing cryptographic checks on passwords. Because that will destroy web servers that get a big load all of a sudden.

Yeah. Because really, the ideal case is that you have a server that serves static stuff and you’ve got a server that manages the session. You’ve got a server that manages the API calls.

Mmhmm.

Yeah, and that’s my real vision for the future, is [chuckles] more of these SaaS products to the point where yeah, a browser really is just pulling some static assets off a CDN to bootstrap an application which is then communicating with APIs in a secure and RESTful way. That’s my vision.

So, Firebase got us pretty close.

Cool.

I drink that Kool-Aid.

The future is now.

The future is a couple of weeks ago. [Chuckles]

The future is when Google bought Firebase.

[Chuckles] Right.

Let’s do some picks.

Hold on, is Google going to buy Stormpath? I just want to know.

I don’t know. But follow our blog. I’m sure that’s the best way to hear about it.

Your response should be, “I’m not at liberty to discuss that.” And then everybody goes crazy.

Yeah.

Yeah.

Yeah.

You what?

Yeah, that’s [inaudible]

You heard it here first, folks. Google’s buying Stormpath. [Laughter]

And your stock price jumps threefold. [Chuckles]

That’s right, those stock options.

All about the stock options.

That’s right. Okay, let’s do picks.

I’m sorry.

Dave, you have some picks for us?

Yes, I do. Alright, people. I’ve announced this before but I’m going to announce it again. January 12, 2016 we’re putting the fun back into funeral as we celebrate the death of old IE browsers.

Nice.

Woohoo!

I’m keeping an eye on this date. I’m going to throw a huge party. I’m going to try to get… this is real, people. This is going to be a real thing. You thought some of the conferences you went to this year were real? No. This is it.

I’m going to try to get my company to sponsor a big event. We’re going to do something cool. [Chuckles]

So, January 12th. Put it on your calendars. We’re going to figure something else out. It’s going to be awesome.

And by ‘woohoo!’ I mean, don’t hold your breath. [Chuckles]

I don’t know. I actually believe Microsoft this time. I think it’s going to happen. Anyway. [Laughter]

Okay. The next pick is, this is a pick from, at the time of recording… This is the day after May the 4th and it was a really fun May the 4th special video on YouTube called Battle Damage. What happens when you build the $800 Lego Star Destroyer and drop it into the ground in a 1000 frames per second high speed camera. It was pretty cool. So, I’ll link that in the show notes.

And finally, I’d like to pick a really cool open source project called GitLab. This is a clone of GitHub but you can host it yourself. So, you have a little more control. And it is really, really good. And they are… it is actively maintained and they release new versions with nifty cool features all the time. I’m a huge fan. I used to not believe in needing a web-based interface for you Git projects at all, because I liked the tools like tig and even just built-in git log, things like that. But I’m a huge convert to GitLab. We use it for code review. I love it. So, I’m a fan. I’m not affiliated with GitLab in any way.

So, those are my picks, thanks.

Alright. Aimee, you have some picks for us?

Yes. I’m just now realizing that there’s some sort of theme of balance and relaxation through my picks or something this week. But anyway, so maybe that was subconsciously on my mind.

Ohm…

[Chuckles] The first one…

Ohm… I’m sorry.

And then the second one, I saw this somewhere and I posted it in our Slack channel. And I got a lot of good feedback on it. It’s another blogpost called ‘The Cult of Work You Never Meant to Join’. And the same thing, it just talks about balance. If you want the cliff notes, there’s a good graph at the bottom that just talks about how your productivity doesn’t necessarily go up the more you work. So, you just have X amount of productive hours. So, the time you put in doesn’t always produce better results. So, that is my second pick. And that’s it.

Love it.

Awesome. AJ, you have some picks for us?

I do. I’ve got some good ones today. Alright. So, first off there’s this podcast called Serial podcast. And it’s like unsolved mysteries except there are 12 episodes on just one. And supposedly at some point they’re going to come out with a season two. But it’s a very interesting murder case where there’s literally one piece of evidence in the entire case and they convicted and put this person in jail. And there’s no way to say that he’s innocent for sure. But when you listen to the thing, you just start thinking, “Where’s the evidence here? And where’s the motive and why would this happen?” And so, it’s just one of those brain bender things to listen to and form your own opinion. But nobody will ever know the truth, which is kind of weird. Or maybe, I don’t know, maybe they will. But probably not. That’s how those unsolved mystery things go.

Another thing that I’m going to pick, I’m going to pick Computer Science. There are so many people that code by they don’t… I am completely pro-college dropout. I think that college is an absolute waste of time if you’re going to be a programmer. But on the other hand, I would not be a good programmer if I hadn’t learned some computer science. And so…

So, you’re saying it’s okay if you don’t want to do computer science but you’re just going to be a

bad programmer? Is that what you’re saying, AJ?

That’s what I’m saying. [Laughter]

Some people are really smart in that they…

Own it, baby.

They just get the patterns. It just comes to them and they just understand it and they don’t have to get formal education. But I think that if you’ve been programming for a couple of years and you don’t understand big O notation or you’re still fuzzy on how to do things like introspection and recursion and iterative loops…

Pumping lemma.

So, related to computer science I’ve got two links for you. One is HotPlate. It’s a homework assignment. It’s a pretty fun one. It’s simple and it’s fun. And it will tease your brain. And if you cannot solve HotPlate, then you are not a good enough programmer yet. But you can be. And I hope that you will be.

And then also ‘Design Patterns in C’. C is a terrible awful language because it’s not for programming. It’s for hardware. It’s not for applications. It’s just not. But if you learn design patterns in C you can apply them to every language. Not to say because it’s the hard way, but just… when you have a limited set of tools to work with and you learn how to use a limited set of tools to create a result and you have a superfluous number of tools, you won’t get confused by which of these 11,000 tools should I use? You can be like, “Oh, I only need these two building blocks to make this pattern work.”

And then after that I will pick OAuth3 which is coming into existence because it is. People have blogged about it. People talk about it. Everybody pretty much has the same idea of what solutions we need, how to make it so that OAuth3 is just, drops in place, simple, done deal. And I’ve been working on implementations because I’m working on the home cloud system and some other things that I need authentication to be a lot simpler. And so, you can check out the website for that, which is OAuth3.org. And hopefully more stuff will get up there. And I’ve got some examples and whatnot. But I want some feedback. I want people to ask me questions and to criticize and whatever. Because I think that we need something that’s standard across the board and that works and that will be a tool for the pure web. When the machines rise, they need to be able to autocommunicate with each other, you know? So, all those things.

Okay.

I have pick fatigue now. [Laughter]

I haven’t even gone yet. Neither has Robert. I’ll keep it brief. First of all, I did JS Remote Conf. I got the videos published on YouTube. I think I mentioned this last week but I’ll put links in the show notes again.

Another thing is I’m doing a Ruby Remote Conf. I had a lot of people from the JS Remote Conf want it. And so, I’m just putting it out there. So, you can go to RubyRemoteConf.com. I should have the schedule out pretty soon here.

I also read this book called ‘Traction’. Now, I may have picked another book called ‘Traction’ in the past. This one’s a different book by Gino Wickman. And he talks about how to organize a small business. The picks have gone a little long so I’m just going to summarize it there. But there’s a lot of great stuff in there if you’re running your own business.

I also really quickly want to pick the podcast Startups for the Rest of Us. Mike and Rob just have terrific conversations. I met them both at MicroConf this year and they’re really super smart. So, I’m going to pick that as well.

Robert, do you have some picks for us?

I do. In the mindfulness space, I’ve actually got a poem that was read in my yoga class a few weeks ago that I’ve been digging. It’s called ‘The Guest House’. I won’t read the whole thing. I’ll read the first verse here. It’s saying:

This being human is a guest house.

Every morning is a new arrival.

Oh, I’ll let you guys read the rest. But it’s a nice light way to think about the arrival of feeling and experience in your life. So, that’s from the mindfulness side.

My next one here is actually, it’s something about engineering and hiring culture. It’s a good writeup on a problem that everybody’s trying to figure out which is, how do we kill the standard way of interviewing engineers? Because it doesn’t really do a good job of finding people who love their work. It’s a really good read on that.

And then a third one here, maybe some of you guys have seen this. But it’s following the last pick. It’s a really good list of questions if you’re looking to hire someone who’s a frontend developer. It’s a very exhaustive list, because the whole frontend web development space is quite large, right? It’s a really good list. My strategy actually for those kinds of interviews is I don’t pick the questions. I put the list in front of the person that I’m interviewing and ask them to find the things in it that they have a really good knowledge of and can answer very specifically. Because it helps you figure out where someone’s expertise is quickly, because frontend is very board. You can be amazing at CSS but not have a clue about how XHR works, and things like that. So, that is something that I want to pass along as well.

Alright. Well, I think that’s it. Thanks everyone for listening. We’ll wrap up the show. We’ll catch you all next week.