The Frontside Podcast

Special Guests: Brian Douglas and Bex Warner of GitHub.

In this episode, the panelists talk about automating GitHub with Probot. The origins of Probot are discussed, as well as making GitHub apps with the GitHub API, automating workflows with Probot, must-have Probots for every repo, and GitHub’s V4 GraphQL API.

References:

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

TRANSCRIPT:

ROBERT: Hello everyone and welcome to Episode 105 of The Frontside Podcast. I'm Robert DeLuca, the director of open source here at the Frontside and I'll be your episode host. Today, we're going to be discussing automating GitHub with Probot with Brian Douglas and Bex Warner. I'm really excited about this topic. The idea of automating GitHub workflows with bots is amazing. This is something that I've been wishing the GitHub have the platform support for since I even started using GitHub for open source. Just being able to have a bot to take care of certain things like somebody doesn't leave enough of a PR description and they open up a PR, you can have a bot that just responds to it and saying, "Can you provide more information?" It's pretty awesome.

With me as co-host today is Charles Lowell, who is also a developer here at the Frontside. Hey, Charles.

CHARLES: Hey, Robert.

ROBERT: Before we get into the discussion, I like to make a tiny little announcement. We've been building a composable and an immutable state container called Microstates. I'm sure Charles can talk about this more at length, then we will in the next podcast episode -- 106, but I would like to make a small announcement that Taras who is an awesome developer here just wrapped up a month's worth of work, creating a new ReadMe to describe the vision of Microstates and what you can do with them and everything about Microstates. If you're interested in that, I highly recommend checking out the ReadMe. I'll drop a link in the show notes for you that are interested.

CHARLES: If I can add, it really is [inaudible] because it isn't like any other state management solution out there.

ROBERT: No, absolutely not. I've been building something with it in React Native over the weekend of the 4th of July and it's amazing. But enough about that, you'll hear about that next episode. For this episode, I want to talk about Probot with Brian and Bex. Hi are you two doing?

BRIAN: I'm well.

BEX: I'm good. Thanks for having us.

ROBERT: No, thank you for joining. This is really exciting. Like I said in the intro, I've been really excited about this project. I do a good amount of open source, I would say and this has been really helpful in all of our repos. We have, I think like 78 open source repos on the Frontside. We have Microstates, like we just talked about and Big Test and all of those repos use some combination of Probots that people have built and it's really nice, especially with the new Checks API that has just come out. You can integrate Probot into that, right?

BEX: Yes. I, actually am currently working on shifting one of our bots from using the commits Statuses API to the Checks API.

ROBERT: That's awesome. Before we go too deep into it because I want to come back to that because that sounds really cool and what the integration of that is like and what changes because I'm not even really that familiar with it. I just know it was released. I kind of want to go from the beginning here. Where did Probot come from and can we get a little bit of a history for everybody that might not know what Probot is?

BEX: Sure. Probot originally started out as this simple idea to make GitHub scriptable. The original idea was you have a single file in your repository that would be like a JavaScript file and it would essentially spell out how the bot would act on your repository and the goal was to make GitHub apps accessible to people because if you ever look through our GitHub apps documentation, I think it can be a little tough to get started. There's, honestly, a lot of nonsense that you have to go through in order to get set up.

For one thing, the way our GitHub app authentication works is it requires a JSON web token followed by using that JSON web token to request an installation access token and that process would be really tough for new people to get started.

ROBERT: Yeah, it sounds like it.

BEX: Yeah, so Probot was created to abstract all of that away and handle all of that authentication automatically and simply leave you with the payload that you get from listening on web token events and in authenticated GitHub client to make authenticated API requests while authenticating as an app.

ROBERT: Cool, so that's where it started like a flat JavaScript file in the root but today, you use like EMO files and a .GitHub folder. How do that kind of progress?

BEX: Originally, their use case was much simpler and it quickly became clear that a single JavaScript file in the GitHub repo was not scriptable enough and not easy enough to understand. The goal was to make like an API that could make that JavaScript file really, really easy to customize for every API of GitHub and it quickly became clear that that was not really a feasible thing to do.

as time went on, it turned into this way to build Node JS applications and essentially, what the configuration files you're referring to are the way in which we make it customizable because right now, there's no way to be officially supported GitHub apps channels to pass secrets because it means you're a [inaudible] and the owners of GitHub apps, so that was just a way to kind of stop that problem.

ROBERT: Gotcha, okay.

BEX: The actual code for GitHub apps still lives in a Node JS module basically and the configuration file just specifies how that module runs.

ROBERT: Right, so they're deployed like Heroku instances, if you want, like anywhere you can host a node app.

BEX: Yup. Heroku, Now, yeah.

ROBERT: Interesting.

BRIAN: As a reason to that, some explorations of doing serverless deployments for Probot, I think there's a couple of issues of them. I'm not sure if anybody's shipped anything like the way they at but it's pretty much it's possible to.

BEX: Just a week ago, we even released a new version in which we update our core from Node JS to TypeScript and now that things are typed, we have big plans for serverless.

ROBERT: Nice. That's awesome, so then you'll be able to deploy to a Lambda and off to [inaudible].

BEX: Exactly.

CHARLES: Can I actually interject here, as kind of a person who doesn't really know the relationship between GitHub apps and the GitHub marketplace and what exactly a Probot is before we hear the origin story. I would love to hear a very high level view of how this ecosystem fits together.

BRIAN: I think a lot of people are pretty familiar with interacting with the GitHub API and OAuth integrations. I think I've just spent a lot of time at different companies previously to GitHub, just like making calls, either to cURL or through Node JS or more recently, [inaudible]. GitHub apps itself are a way to take all the things that you had to do to make an integration to GitHub much easier. It has a lot of cool things like OAuth, scopings, so you no longer have ask for all your repos ask access whenever someone logs in with GitHub and the connection between like, "Now have gone from OAuth to Now to GitHub apps," there was a lot of, as Bex mentioned earlier, ceremony that happens to getting set up with GitHub apps and integrations that Probot is like this tool to speed up the process of getting to the point where you just want to script some automation or some sort of workflow and it gives you all that bullet play for you. I don't know if that was a good high level for you Charles.

CHARLES: Yeah. I've kind of witnessed this second hand with Robert installing a bunch of things here, so let's use an example, like you did some sort of automation on our repos, Robert, where when someone files a ticket, there's this workflow that automatically adds a triage label, so that we know that this thing hasn't even been dealt with, so we really need to address that issue. It doesn't need to be as a high priority. It doesn't need to be closed as a duplicate of something. One of the different aspects that you described there, how do they fit in terms of serving this workflow onto the end user? Or was that a good example, even?

BRIAN: One of the cool thing about GitHub apps and what Probot does for you is that normally, if you want to add a label to an issue, either you Charles or Robert, would have to be admin or maintainer on the team for the Frontside and you could add labels. But somebody who opens up an issue, doesn't have that ability to have write access to your content, which is adding a label. What a GitHub app does, it actually takes a spot as if you would have another user on your platform, instead of creating a dummy account or a dummy user. Probot is basically building a bot for you to then, give you the ability to add that issue. That's sort of workflow that normally would have to happen through an actual real human could not happen through a bot without taking up a spot of like, "I guess, I probably shouldn't speak so ignorant about our platform and what we actually pay for nowadays for GitHub," but I know we used to have like a limited amount of seats for organization, like that seat no longer has now taken up and now, it could be just be used a bot can do something that normally us would take.

ROBERT: Right. You no longer have to create a user to do these things.

BRIAN: Correct.

BEX: [inaudible] within GitHub. It's sort of built in a way that apps can take a lot of power in your repositories.

CHARLES: So then, what is the relationship between Probot and an app?

BEX: Probot is essentially the framework for building an app. You can definitely make the equivalent of any Probot app outside of Probot. It abstracts away all of, basically, the horrible parts and leave the easy part.

CHARLES: Now, I think I'm ready to participate in this discussion.

ROBERT: That was perfect, though. That's a great intro because I actually didn't have a total grasp or understanding of the relationship between GitHub apps and Probots. That's really good.

BEX: Yeah. Additionally, going back a second. You mentioned the marketplace before. One thing to note that is that there actually are several Probot apps on the marketplace right now. The marketplace is essentially the home for any larger, usually third-party companies that have made apps and Probot is essentially supporting some of those.

ROBERT: Interesting, so then my question would then be, do you know anybody selling their Probots. Does the marketplace charge? I'm going to assume it does.

BEX: Yes.

ROBERT: Okay. Is there anybody charging for their Probot?

BEX: Yes. There is a quite a few, in-fact, charging for it. Recently, a pretty popular example is the GitHub Slack integration, which is if you open new issues, you can have them appear in your Slack channel. That whole application was recently rewritten by GitHub. It was previously owned by Slack and that was built on top of Probot.

CHARLES: And I actually remember, we upgraded to that version. It's actually way, way, way better.

BEX: I'm glad you feel that way.

CHARLES: I didn't know the story behind there. I was like, "Oh, I just got a lot of... Awesome," you know? Although I don't know what's the costing.

BEX: Yeah, I think that integration is actually free, so that wasn't the best example. I think it's for open source projects, at the very least.

BRIAN: Brandon, one of the maintainers for the Slack integration and work at GitHub, also did a really cool talk at the SlackDev Conference a couple of weeks ago, so if you're interested what were the behind the scenes. That integration is all open source as well, so if you have request or you have features that you would like to add to the Slack integration, you can pop into the repo that hopefully will show up on the show notes because I'm not sure if it's like GitHub/Slack, but I guess we'll find that out in the show notes later on.

BEX: It's Integration/Slack.

BRIAN: But for an example of a paid app of a non-third party, we're not talking like Travis or Circle or another one with the big names but rather, a solo dev created. It's Pull Reminders, which is on the marketplace as of today and essentially, this gives you reminders of your pull quest, so you can actually ping inside the comments and tell Pull Reminders to say, "Tell me about the pull request like next week because it's Friday and I don't have time to look at this."

ROBERT: That's awesome. I've also seen the one that's kind of related, that is like you can set your out of office at GitHub, which is actually kind of a neat concept.

BEX: Was that the one where we are already changing that profile photos to have the overlay or the one where is just auto-replying to messages because I've seen a couple of --

ROBERT: I think, it's just auto-replies.

BEX: Okay.

CHARLES: So, it can change like your profile pictures and really, not just related to repo and history related activities but everything?

BEX: Anything that you can access via the GitHub API, you can almost access via GitHub apps. There's a list of end points that I specifically enable for GitHub apps because there's something such as delete a repository that there's basically, a very few circumstances under which you want to give that permission to an app. Also, to things very specific like your profile or your personal page.

About a year ago, there was an official internal audit of all of the API endpoints because there are lots of inconsistencies over what was and what wasn't enabled for GitHub apps, so they went there and kind of decided, what endpoints should be enabled and what endpoints actually get enabled. Now, that list is much longer than it was a year ago. Now, it's much more comprehensive.

ROBERT: That's awesome and is this for the Rest API and the GraphQL API?

BEX: Yes. Probot does support both. The Rest API is the one that specifically had all of these endpoints audited. The GraphQL, since it's a bit newer, we sort of built those and more.

ROBERT: Cool. I really like working with the GraphQL API with GitHub. It makes it easier than trying to do a bunch of Rest calls.

BRIAN: Yeah, there's a community form, it's like a discourse form that the API team actually manages and sort of pipes in there. Again, going back to like, if there's not something in the Slack integration that you would like to have, the form, that community is actually in there, if there's something not in the GraphQL API, that you would like to see. No promises on shipping it within an x amount of time but if enough people are requesting it obviously, there's going to be some resources [inaudible] at.

ROBERT: What do you mean? We’re doing open source. It has to be done yesterday.

BRIAN: Yeah, exactly. And that form is at Platform.GitHub.Community, just a URL to get there.

ROBERT: Awesome, that will be helpful to look through and get some recommendations in there. One of my favorite things I was going to say about the new integration for Slack and GitHub is the fact that I can highlight line numbers, paste that linked in and then it just expands it and the chat in Slack. That is so nice and I use it all the time.

BEX: Yeah, I love that they built that feature. Actually, the original feature that was built on GitHub to allow those line expansions in the first place, like on GitHub itself, was actually built last summer by some folks who were also a part of my intern class at GitHub last year.

ROBERT: Hey, intern power. That's awesome.

BEX: Yeah.

ROBERT: Everyone there is doing amazing work. I'm also following along with somebody that is also an intern and it's building a weekly digest program.

BEX: Oh, yeah. That's actually a Google Summer of Code student.

ROBERT: Oh, interesting.

BEX: So, being sponsored through Google Summer of Code by Probot as an open source support.

ROBERT: Is there anything more to unpack there? That sounds really interesting.

BEX: Essentially, we submitted an application for Google Summer of Code because we thought it'd be a cool way to get more people, more students, a mentorship opportunity for the maintainers, basically and we were honestly overwhelmed. We got like almost 100 applications and it ended up being a huge of a deal but we're --

ROBERT: That's a great problem.

BEX: Yeah, definitely a good problem but we were really happy. We, initially wanted to accept more students but Google limited us to only two students, so we have two Google Summer of Code students working on projects and one team of women from Rails Girls Summer of Code working on Probot.

ROBERT: That would be awesome. What do they working on?

BEX: I'm not sure yet. They actually just started a couple of days ago but the other Google Summer of Code student is working on a background checks API to eventually do sentiment analysis of comment history of someone new to your repository.

ROBERT: That's interesting. That sounds like there will be some machine learning in there. I might just throwing out buzzwords?

BEX: Most likely, I think they're just using some sentiment analysis API, like the perspective API. I don't think they're actually doing that themselves.

ROBERT: Okay.

CHARLES: Actually, I have a couple questions. Back on the subject of Probot. How does this square with the classic mode of integration because there was a lot out there? I think the first one that I remember that stuck in my mind was like Travis and I don't know if there had to be like a special relationship between the Travis developers and the GitHub developers, that's like, they was able to make that integration happen so many years ago. I don't know how that happened. I just remember it popped up and I was like, "Woah. This is incredible," and we see kind of the integrations gets more and more rich.

For someone who's got, like you mentioned a couple of the big names, is the idea that eventually those would be able to be completely supported is GitHub apps or is it they're always going to be kind of a separate track for kind of the really deep integrations?

BRIAN: I wasn't around when Travis first integrated with Lyft GitHub and I think that's a really cool integration and I know they have a very nice sized team that's able to do that. I think if we zoom back out like Probot, the way to get started with Probot is that we have the CLI command, which is to create Probot app. I believe it was intentionally copied off of create React app and the cool thing about create React app and create Probot app is that they abstract all the ceremony and boilerplate to get started really quickly. It was like, what developers or smaller teams can get started with integrating with GitHub apps. I highly doubt that Travis is going to rewrite their entire application with something like create Probot app but they're definitely going to be moving towards the new API calls, which would have been like GitHub apps.

Part of the Checks API that we had launched at the end of May, Travis had blog post on how their integration with the Checks API works. They're making, though they have a lot of what Legacy endpoints and a lot of Legacy integrations in the way they integrate with GitHub, they are actively moving towards a GitHub app. I don't know if I could actually comment on their status of where they are today, to be honest but actively, we want all new apps and new integrations to follow the model of being a GitHub app, so that way, out of the box, you have access to all the newer features. You have all the access to all the newer GraphQL endpoints, if you want to use GraphQL and that way, we can serve one market, as opposed to everybody who had a GitHub integration from five or six years ago, that was all piecemeal together and sort of duct tape, like we run move away from duct tape everything together.

CHARLES: I see.

BEX: I definitely agree that I don't think Travis is going to switch to using Probot anytime soon and I don't think most of the large companies will be doing that but I do think, there will be shift towards GitHub apps in general. For those companies that don't already have the buildings of the GitHub app started, I think that Probot could be, in time to free some of them.

BRIAN: In addition to that too, Travis and Circle and all the CI integrations, they're doing a really good job. I think the cool thing about GitHub apps is what you take away all that ceremony of getting your checks to work, now we can start opening up the door of like what's the next sort of CICD thing like? There’s another term or another, I guess category of applications that can now be built to improve GitHub.

CHARLES: The most amazing thing about having a great platform is the apps that you don't foresee, like it just come completely out of left field and you're like, "Woah. I can't believe that's actually a possibility now." When you have started to see some of those, some Probot or GitHub apps, you're like, "Man, I didn't see that coming. That's awesome."

BEX: A hundred percent. I think it's the most exciting part of Probot because I think GitHub as a platform, we all know GitHub is the largest developer platform in the world and I think the idea that developers can build on top of this platform is the most exciting idea right now. I have honestly already seen apps that really excites me.

The other day, I saw this app that was definitely not near completion but it was essentially updating and issue a comment box over and over and taking response through like checking a box and then listening on that common edit, in order to specify your coffee order.

ROBERT: Woah.

BEX: I was like, "Do you want an ice coffee or regular? Do you want milk or sugar and cream?" and it was going one at a time. It didn't actually order you your coffee at the end but it was super exciting to watch that. You're just editing the comment. I had never seen that before.

ROBERT: That's pretty slick and that's taking the API pretty far. I'm sure there were some parsing in there and each Webhook response are like, "Was this box edited or not." That interesting.

CHARLES: Yeah. Actually, now that we're having this discussion is kind of like changing my mind a little bit. Robert and I were actually talking yesterday about trying to standardize on our release management and our plan was basically to have some software that was going to run inside of our CI provider and have kind of a shared library, just a little ntm package that was shared by all of our repos but I'm thinking now, man, we should really explore doing this as a GitHub app.

ROBERT: Yes, please. I've had three ideas that I really want to build out as a Probot. I'm just going to list them off and then we can build them all together and take equity and you know. I'm kidding. But the two that really excite me, that I kind of want to do is one concept that we work on this open source project for our clients and if somebody from the outside that doesn't have commit bits to be able to push to master, it would be really cool if we had a Probot that after it had an approved on the PR, from the maintainer, that the person that open the PR could then tell a Probot say, "This is approved by somebody that manages this project. Can we merge?" and then the Probot would then actually merge. I don't know if that's possible. That's something that I definitely wanted to explore.

Then the other one, which is less cool, would just be like if we have a couple branches on some of our projects that we want to continue and we're not ready to put it back into master but we want to continuously run the test suite against it, so the idea there would be to have a Probot that would watch for changes on master and rebase as needed and continue to run the test suite and see where you're at. Those are the two things that I'm really excited about to do with Probot but I just want to automate everything with GitHub now.

CHARLES: Right.

BEX: Yeah, definitely, that first idea was actually pretty viable. I'm curious to know like how you actually get those commit links -- is that what you called it?

ROBERT: Commit bits are more like commit permissions, I guess.

BEX: Oh, I see.

ROBERT: An outside contributor.

CHARLES: Yeah, we want to push responsibility to the person who is the maintainer who can approve it but actually, the way we do it at Frontside is the person who actually is making the change is responsible for merging it. Once you get approval, you still have to hit the go button and that's just going to make sure that you're taking responsibility for saying it's done but that doesn't work for open source because people coming off the internet are going to have the right to push but we would like to give it to them, maybe via an app, if there is a maintainer who's approved it.

BEX: Yeah. That's definitely something you can do. I've seen quite a few apps that, essentially add outside collaborators to the repo. Are you familiar with the... I forgot what it is called, like the all contributor section, where you cite everyone in your repo and everything and who's worked on it. There was a GitHub app that would add someone automatically after they merge their first change.

CHARLES: That's awesome.

ROBERT: I may have seen that on React State Museum but I'm not sure. It's a repo that we've contributed to and it has all the contributors at the bottom. It seemingly just kind of popped up there.

BRIAN: There's an app that, I would like to mention too that I'm pretty excited about, that it sounds trivial too and it's almost similar... Not similar but it's sort of related to what you were talking about, Rob, with your first app, which is the WIP bot, which is the work-in-progress bot. This is a pattern of whenever I open a PR and I might not ready for a merge but I want to share my code so I can get feedback earlier on, I'll type in WIP so that append to my title of my PR.

What this engineer did was every time you do WIP, it's going to go into the GitHub API and actually block the PR for merging, which is a feature available to GitHub. It's nested in your settings but the cool thing about this it actually blocks the PR for merging, so you don't have to worry about getting your, sort of like show and tell code merging the master without being ready.

ROBERT: That's one of the first bots that I installed on all of our repos and then you can correct me if I'm wrong, it didn't always have the ability to block the PR from being merged but with the new Checks API, is that something that was introduced?

BEX: Not exactly. The way that blocking of merging works is if you set it as the required status, so you can install any sort of CI on your account and have it not being required and ignore it whenever you feel like it, so it's really up to you to make it required. Otherwise, it just isn't checked and that's true for anyone who uses the Statuses or the Checks API.

ROBERT: Okay, so that's a Statuses API. Okay, sorry.

BEX: Yes.

ROBERT: Also, the cool thing about that that I noticed when that was rolled out was I was now able to pick and choose and use workflows on Circle CI and each workflow is broken out as a different status check. I am now required like linting and the build and the test have to pass for these browsers before it can merge, which is really cool to be able to pick and choose.

BEX: Yeah. It's awesome. I know personally on some of my repos, I have a few checks that I just don't require because I know I have to make them pass.

ROBERT: Yeah. Speaking specifically about the work-in-progress bot, do you know how that works? It’s open source, so I am sure I can go look. I think we want to go make a PR. We had some back and forth about this, Charles.

CHARLES: I actually just [inaudible] we disagree.

ROBERT: Yes. Charles opened a PR and one of his first commits in the PR had work in progress and the title had work in progress and we have this this Probot on our website and it was a blog post. You know, you make a couple more commits and you're further down, you move the work in progress in the title but the PR were still blocked because the first commit on a PR have work in progress in it.

I think if it's the most recent commit or if it's in your PR title with work in progress, it should block but otherwise, it should not and Charles feels differently.

CHARLES: I have about six commits and the very first one have WIP in the title or in the commit message and it blocked the whole thing but I kind of felt like it actually made me go back and I had to squash it down to two commits because I actually feel that your commit history should tell the story of the development, not like it should an absolute one-to-one journal of what happens but what you are intending.

I actually felt that it could help me out because there's six commits that we're kind of all over the place and just kind of slapdash together have made me kind of go back, rethink it and tell a coherent story. I think it did me a service but it was not obvious. I definitely agree with that but I was like, "Why? Why were you still blocking?"

ROBERT: Do I really [inaudible] admin privileges?

BEX: I would say, I am friends with the creator of the web app. His name is Gregory Mantis and he is actually got a huge work in progress PR shifting work in progress over to using the Checks API and one of the features that he's using with the Checks API is essentially this mark as now work in progress button that will add the special line, like feel free to merge or something like that into your original PR description at the bottom. If that is there, the work in progress app will no longer be blocking. It's essentially like a hard override and honestly, that's the power at the Checks API versus the Statuses API. That's really exciting.

ROBERT: Because I have seen the work in progress bot to get into a weird state, where I did remove the work in progress from the title but it didn't quite update and I'm still blocked. It's okay for me because I have admin privileges but other people on the team maybe not and they might be blocked from something that's actually work in progress. It's a lot like that hard override will be probably pretty helpful.

BEX: Yeah, definitely. I think sometimes, there's some confusion with that just because of the way what perks work on GitHub and the way our pages are rendered, that you may need to refresh the page before you actually see it take effect.

ROBERT: Right, yeah. Overall though, I love that bot. I go weekly, probably to the Probot apps listing and just go shopping.

BEX: Wow. I'm actually the person who approves all the Probot apps to the listings so that's pretty motivating there.

ROBERT: It's really nice. I am not even joking when I say shopping, I go through and I open up a bunch of tabs, I read through them, "Oh, this could be useful," that kind of thing.

BEX: The first app you mentioned, which was like the one that requests more info is actually one that I built, so that was kind of funny. I guess you got that from the Probot apps too.

ROBERT: Yup. That one, we definitely use on a couple of our organizations and repos. It has yelled at me a couple of times because of a blank PR.

BEX: It yells at me all the time. I think I get yelled at more than people who are actually doing it wrong.

ROBERT: I'm a little embarrassed like, "I should do better. I need to set an example."

BEX: Definitely.

ROBERT: Cool. I'm curious what both of your favorite Probot app is. This ought to be interesting.

BRIAN: The app that I'm really impressed with so far, that I actually only use on a junk project at the moment, is the weekly digest one and it's mainly because I built something for this in my previous role at the company but then we shift it, which is basically go through every single repo.

I worked at a company called Netlify previously and we had way too many repos to maintain... Oh, sorry, to keep track of and I was moving further and further away from the backend at the time so I was unable to keep up to date with all that was changing. I built a Lambda to watch Webhooks and then give me a digest of what was shipped like issues and PRs closed. It was way over-engineered and I never actually shipped that to actually make it work.

But then the weekly digesting came out maybe a couple of weeks ago and it blew me away because I was like, "This is exactly what I needed," and I was trying to make it overly complicated through like a Lambda and like a bunch of Webhooks and this person, with only a few weeks, has the scaffolding of what I needed. That's the one thing I'm pretty excited about. It was already mentioned earlier too, as well.

BEX: I guess, I would say one of my favorite ones is the unfurl a link app. I think that one it so simple but so nice. I don't know. I think having that unfurl link preview is just beautiful. Essentially what it does is it listens on issue comment creation or pull request comment creation or issues your pull request or whatever and read through the text or whatever was that issue or pull request and looks for links and then, essentially unfurls them so you can get a really nice preview of what you're going to. I think that's really beautiful and just so simple.

ROBERT: Yeah. I love that one too. I have that added to all of our repos.

BEX: It's so much nicer. Why would you not unfurl your links when you could unfurl your links?

ROBERT: Exactly.

CHARLES: I actually have a question. I think it's been touched on, probably at least twice throughout the conversation. I want to actually create a Probot, how do I actually go about deploying it? What does that look like? What does it look like to deploy and maintain it?

BEX: We have a page on our docs about deployment and essentially the TL;DR is you can deploy it on any normal cloud hosting service that you wanted to deploy it. There are a few things you need to specify. For example, GitHub gives you a private key that you need to create your JWT and that private key means to be passed into your hosting service however you do that and then, there's a few bits of information that need to be pass in. We have pretty intense docs about it. Honestly, I'm not a deployment person. I usually try to let other people do that and I have never had a problem going through our docs and just getting it working immediately.

BRIAN: It's also mentioned that there are examples like Heroku and Now and a couple of other ones. If you have a service that you already like, it's possible it's already in the docs, like steps to how to get that deployed.

BEX: Yup and any other services are more than welcome to be added to the docs. Pull request are welcome.

ROBERT: Sweet. It sounds like we need to set up a hack date to create a Probot, Charles.

CHARLES: Seriously, my mind is brewing.

ROBERT: I guess it's not directly related to GraphQL but there's something that I've always wanted to build. For prior history to everybody [inaudible], then the podcast, Brian and I used to work at a company called IZEA and one of the things that we built and I worked on a lot was we would create a collect metrics on people's social accounts that they're connected and do that and graph it over time. This idea came from when I was building up that feature all the way back in 2013, I want to graph the change in GitHub stars. Is there an API available for me to see like weekly GitHub stars or is that something that I still have to manually store and track?

BEX: There's definitely an API endpoint to get the amount of stars and I don't see why you couldn't just do that on weekly basis and compare but I don't think there's any track that change API.

ROBERT: Gotcha, like a history of it. I could do this by just stealing and looking at what the weekly digest Probot is doing because there is a change in stars section in there. I was just curious if there was now an API that was available.

BRIAN: Yeah, that's more unlikely. I'm going to say no without looking at all the reference documentation. I think as far as that database, it's something you'd probably have to collect on your own but it's also a good candidate for a GitHub app, where you build a service that you can actually track stars once you've installed it and then if you want to monetize it, you can actually pay for private repo or whatever stuff like that, if you wanted to. But it sounds like a great opportunity to see this in the GitHub/Probot listings.

BEX: I actually just look this app really quick in our docs because I was curious but apparently, you can receive the star creation timestamps. That could be doable through timestamp usage.

ROBERT: Oh, and then I just kind of loop through back and build your graph in there.

BEX: Yeah.

ROBERT: Interesting. All right. Well, [inaudible] I was going to do today.

BEX: Yeah. But I think it's exciting to bot the weekly digest and then what you could extract from that into stargazing is that Probot scheduler, which is essentially this all Probot extension we made that triggers a Webhook on a scheduled time period because right now, the way GitHub apps works are so centered around Webhooks. It can be difficult to find a way to trigger an action on something outside of a Webhook, like on a schedule basis.

ROBERT: Yeah, that would be really helpful. I can definitely see how that would be a problem, if it's very, very central to reacting to Webhooks and events that happen on the system.

BEX: Exactly.

ROBERT: You're just hoping that somebody comes through and creates an event at a specific time.

CHARLES: Can I ask you a question about, it's definitely on topic of extending GitHub but currently, just a question about, where the line is between what you can and cannot extend? You mentioned, for example in the rewrite of the WIP bot, being able to throw out a big button that says override this merge. Are there any plans to be able to actually extend the UI in novel ways? Everything there right now is happening with API calls, with I assume, UI elements that are related but the UI elements are static. If someone wants to put a novel piece of the UI, that button is going to require an extension of the GitHub UI by GitHub itself. Are there any plans to be able to, I know it's a dangerous waters, perhaps at a limited fashion at first but maybe more so, add different interactions and the actual application.

BEX: I think this is actually the most exciting future of GitHub as a platform. In the past, GitHub APIs have only specifically supporting things that you can do through the command line or you can do through GitHub's UI itself. The Checks API introduced the very first non-integration specific UI element essentially and the merge button that I was referring to in WIP is exactly that. It's essentially this button that you can change the text of it to be whatever you want and you can listen on that action and then you can do as an integration or an app, anything that you want based on that. I think that's the most exciting direction for GitHub.

Because if you look at Slack, Slack is a platform that has sort of really impressive integrations in that response. Your apps on Slack can really do all of these things, use custom UI elements, so I think the most exciting features for GitHub as a platform is all of this customization and giving the power to the apps.

ROBERT: Yeah, that sounds an awesome way to be able to extend GitHub without having to try and throw the feature on to GitHub developers.

BEX: Exactly. I feel that a lot of the struggle right now is that there aren't these nice ways of communicating via apps because I feel lot of the apps and bots end up just commenting on issues and pull requests and taking up a ton of screen real estate as a result and I just think that that's not the way that bot should ideally interact with the GitHub platform. They should have their own space to exist and that's the feature I'm most excited for.

CHARLES: Yeah. I can think of having like progress bars for CI checks and your various appointments. It's too exciting. I'm glad. That's definitely the response I was hoping to hear.

BEX: Yeah. We're excited for it too.

ROBERT: Basically, you all have a massive community of a bunch of developers that would want to do this and are willing to get their hands dirty on it. Enabling that community is probably the root of all Probot is about. That's super awesome.

BEX: Yup.

CHARLES: That's a good place to end, because gosh, it's going to be so exciting to have the millions of developers on the planet, just like surgeon to the APIs that you're developing.

BRIAN: One thing to add to that too, about the whole million developers, there's a number that's been thrown out from Stack Overflow and also, some other people who are saying like there's 50 million developers, there's 24 million developers. As far as GitHub, our public user number is 28 million, the cool thing about Probot and GitHub apps is that there's a good chance that all those people that are using GitHub today are not actually developers. They're like PMs or designers and what's really cool about this, like having interactions with that kind of platform in this way is that you can now enable all the non-developers to be able to interact with your GitHub repos and start bringing more designers and PMs onto to the GitHub platform to interact with the developers.

ROBERT: That is an interesting point. That is awesome and something that I'm always looking for is a different ways to collaborate with non-developers on my team because... I don't know, developers tend to think everything is always centered around code but it's not. The shifting at work that are awesome, needs a lot of collaboration from non-devs and non-dev skills. That would be really interesting to see. I'm excited for that to play out.

BRIAN: Yeah. There's a blog post that was published a month ago, I think about where the design team, design system teams rather, built the integration to Figma to update their icons effectively. I just posted that in the chat to look into but they also built this as a Probot app as well.

ROBERT: That is awesome.

BEX: Yeah, that one is super exciting. You would have the app comment, the diff between what the old icon versus what the new icon look like and it's just such a beautiful design change to be able to see that shift.

ROBERT: Man, I'm happy that this is happening. The future seems super bright. Where can we direct people to get resources to contribute, to get involved and start really going at this?

BEX: Basically, Probot.GitHub.io has all the Probot stuff, /app has all the listings for apps you can install today, /docs is where the docs are, if you want to get started and hopefully from there, we link up to the necessary things that you need to do.

BRIAN: Also, what I mentioned too via Probot Slack channel, there's a Slack channel as well and they do a weekly call. I think, it's weekly or bi-weekly call to actually chat with the Probot community. If you have questions, you can actually bring your questions to the team.

BEX: Yeah, we call it 'Office Hours' and it's once a week and it's under our community page, where we also have a link to our Slack. We have a link to another podcast we run and basically, how to get involved in the Probot community.

ROBERT: Those are really helpful resources. I do remember seeing that Office Hours. It's on Thursdays, right?

BEX: Yes.

ROBERT: I was going to drop in for one and then, I actually forgot. Actually, it might be going on as we talk right now in this podcast.

BEX: It starts in half an hour, I think.

ROBERT: That's awesome. Cool. Well, thank you Brian and Bex for having a conversation about Probot. This is really awesome. Is there anything that you would like to plug for yourselves? How people can get in contact with you?

BRIAN: Yeah, I am BdougieYO on Twitter. Everything you need to know about me is there and I am happy to say hello. I'm also helping with the GitHub developer program, which is sort of getting a soon-to-be announced rebranding. If you go to Develop.GitHub.com/Program and you want to have more conversation about the API and GitHub apps on the GitHub side, you can go there to sign up.

BEX: And I am HiImBexo on Twitter. You can ping me in any Probot stuff. I'd be happy to look at any Probot code. I've been looking at it for a while now so I'm happy to do that.

ROBERT: That's awesome. Thank you all for having a conversation with us. This was really fun. I'm so excited about everything you can do with Probot. This is a really fun project. I'm happy that this is happening and I will make a Probot in the future.

CHARLES: I'm looking forward too. Robert has been excited for quite some time and he definitely talks a lot about it and now, I have some insight as to what --

ROBERT: It's happening, I'm telling you. Well. Thank you for being here and we are the Frontside. We build UI that you can stake your future on. We are specializing in JavaScript. We can build anything that you want throw at us. We do functional programming, React testing, Vue, anything in JavaScript, we specialize in.

As always if you want to suggest anything for us to have on the podcast or talk about, you can reach out to us at [email protected] and like I teased earlier in the podcast, next episode is going to be all about Microstates, the immutable and functional state container, composable model system that we've been building, it's controls as a brainchild for the past two years. That is next episode and I'm really excited about that. It's a really fun API and expressive to build models with.

Thank you, Mandy for producing our podcast and we'll see you next episode.

In this episode, Chris Martin of Type Classes and Joe LaSala of The Frontside talk about blockchain development.

Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at [email protected] or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

TRANSCRIPT:

JOE: Hey, everybody. Welcome to Episode 104 of The Frontside Podcast. I'm Joe LaSala. I'm a developer here at the Frontside and I'm going to be hosting today's episode. Today we're going to be associating blockchains and other cryptographically secure technologies and everything that has to do with the web and the future of the web. We have with us Chris Martin and he's currently with Type Classes. What do you do over there, Chris?

CHRIS: Our goal is to teach functional programming with Types, specifically with Haskell and a little bit Nix. We do subscription video service.

JOE: There seems to be, I guess a bit of an overlap between people who are into functional programming and people who are involved in this new space that has opened up, this new web, I guess and that's something that I want to talk about based on a tweet that I saw you made recently. You mentioned that there's a big section of the Haskell community that is being drawn into whatever the hot ICO is at that moment there, something along those lines.

CHRIS: Some of it are bitcoin people or something else but there's definitely a weird overlap that I can't fully explain.

JOE: It seems like strange bedfellows, right?

CHRIS: Well, there's a couple of things that make sense, which I think the distributed systems in cryptography are kind of these notoriously hard problems. I think when somebody wants to convince their boss that they really need to use Haskell for this problem, I think they can make a persuasive argument in this case.

JOE: That's interesting. There's actually, a lot of technology around blockchains around bitcoins, specifically being written in Haskell. I didn't know they were technologically overlapped like that. I guess I just thought they were two very kind of passionate communities but you're saying that a lot of the bitcoin startups that you might see coming out in any given week are actually being written with an eye towards functional programming. Is that accurate?

CHRIS: I don't know about bitcoin along this bit but I think some of the people who are working for banks and trying to develop their own sort of novel internal blockchains and stuff, I think those are the people who see this. Although in the case of banks, we don't necessarily see what's coming out of them, so we can't verify whether they're actually shipping things or not.

JOE: Yeah. That means there's a lot to touch on there. I would agree with you on your initial sentiment, also just to extend to say that I think personally that both communities are really evangelical. Functional programmers, people who are into functional programming, for me it hasn't clicked yet and I know that it will come into my heart. I've asked functional programming to kind of where things are starting to fall into line where I'm certain to see the world in that way but for people who have seen the light fully, I'm sure believers once monads and functors kind of enter the conversation. They don't leave. It’s similar like when bitcoin first started and everybody's running about the gold standard. Really, it's just nothing. It was hard to find resources on it that did the most of the amount of screaming.

CHRIS: Yeah, you're absolutely right, that culturally, they're going to attract the same group of people or the people who are willing to adopt something that's not fully fleshed out yet, people who want to take what they believe and sit in this community and try and spread it to the rest of the world. I think it's the same kind of people.

JOE: The early adoption, I think is something I can consider too. I guess it's a very risk-oriented group.

CHRIS: Yeah, kind of. I mean, Haskell is pretty old, I guess but --

JOE: That's fair, yeah.

CHRIS: -- Some of the changes that really make it, it great and usable lately are pretty [inaudible].

JOE: That's interesting. You mentioned this idea -- we kind of skipped over a little bit but thanks, having their own blockchains and that's something that I think that maybe people not actively following this space, which is I will say, a very hard space to keep up for those of us who are actively following it. But those who may just know blockchain through the name of an iced tea company changing or some sensational news article or what have you or just through bitcoin even, but I know that it's not the blockchain. It's not a singular blockchain.

It’s very easy to implement the fundamental structure. It's a linked list, essentially, with the kind of a cryptographic thing that keeps from breaking that link. Those links are inserting new history, I guess the further you go back. I guess people are even exploring different data structures like directed acyclic graphs and stuff and how that could be used to map other domains but the reality is it's a linked list and you can spend up as many of them as you want and you can mine blocks based on all this different criteria.

Bitcoin is a proof of work associated with the minting of a new block and that's been a problem for them as they scale as a currency but it could be a history of anything and the minting of those blocks can be based on anything. You mentioned banks, the financial kind of sector is certainly interested in these smaller private chains but do you think there's a use for that consumer market as well? How do you think that your personal blockchain or set of blockchains might be a factor in the hobbyist of the futurist life?

CHRIS: Oh, wow. That's a different question than I thought. [inaudible] where you're going with that --

JOE: Where do you think I was going?

CHRIS: Well, we're talking about banks and so, the question is now everybody other than banks --

JOE: Well, it could be everybody, including banks too, however you want to take it.

CHRIS: Yeah. There's a much harder question, I think of what in the world we're actually saying when we are talking about blockchain, right? The notion obviously has started with bitcoin but if what you want to do is bitcoin, then you should just be as in bitcoin, so what are we talking about similar bitcoin and the general phrase people have they like to throw in here is Byzantine fault tolerance.

I'm talking about any kind of system that can have multiple participants. We're used to talking about clusters of computers and making systems that can work if one of them fails, if one of them just stops working but now, we're starting to talk about how do we make systems work if one of them gets hacked, then we still have some assurances that the whole system works together as a whole.

JOE: Would you consider Byzantine fault tolerance to be the defining factor of a blockchain because I feel like there's the timestamping element that goes along with it. I feel like they're kind of part and parcel, right?

CHRIS: Kind of but if you're not considering Byzantine faults, if you're only talking about systems where you have benign faults, which is a machine goes down sometimes, then timestamping isn't really a problem because we can just use NTP and we all have a pretty sensible idea of what time it is.

JOE: Time specifically, even just like, I guess order. I always considered sequence to be a massive part of what a blockchain fundamentally was. You have the distributed aspect of the network that gives this sort of resilience to malicious intent but not only is it protected, I guess against demolition and malicious intent by this crowd strength but also just fundamentally through the cryptographic side of it, you can't go in and insert things that didn't happen. Once that order has been said, it's been written in stone, basically, right?

Because the way I understood is there were papers coming out of Bell Labs in the early 90s and those two things set as approaches to this independently and it wasn't until the internet advance so we put them together and we're able to achieve Byzantine fault tolerance through that. Is that, I mean...?

CHRIS: It does help a lot, I think to buck up and think about what the state of research was in the 90s because I think that's something that a lot of people in blockchain space kind of lose sight of. You have a whole lot of people writing papers now who didn't used to be academics until a couple of years ago. It was the early 90s where we started having faxes and we started having what later turned into what's kind of known as raft. Like you said, they solved the ordering problem.

Even something as simple as what we call Lamport clocks which is you have sort of a virtual timestamps and as long as nobody's malicious, if you remove the timestamp forward, then we can all have something that resembles the deterministic forward flow of time. Then, that milestone that I was like to remind people of this in 1999 is when we had the paper practical Byzantine fault tolerance.

JOE: That was '99. You're talking about the... was it Castro and --?

CHRIS: Liskov, yeah.

JOE: Okay. I didn't know it was '99.

CHRIS: Interestingly, the same Liskov that the Liskov substitution principles named for, Barbara Liskov. It's also a distributed systems research.

JOE: That's swell as well. I kind of heard the concept of Byzantine fault tolerance but I never read this paper. I'm also surprised to find that it didn't come out of that same period of the early 90s and it was as far as '99. I haven't read its entirety but I did fall asleep reading it last night.

You mentioned this specifically, I guess, when we're talking today, as a paper that is important. It's the work that we're trying to do at... was it Hijro, I think?

CHRIS: Yeah.

JOE: Yeah, so what kind of work were you doing there and what is important to you, I guess about this paper specifically, when you look at all the research that went into priming the community for the space that we are now in?

CHRIS: When I joined Hijro, I got kind of a difficult and nebulous mission, which was that everyone in and around that space that was trying to sell to banks was if you said the word blockchain, you could get your foot in the door because all the banks were looking at bitcoin and saying, "Well, look, this is clearly something that's going to be big and we don't want to be missing out, so we have to figure out how this applies to us."

JOE: What year is this? They were working this in 2014-ish, is that right?

CHRIS: '15 or '16, I think. The question was trying to figure out what aspect of it was actually what they wanted here. What Hijro is trying to sell them, the details aren't even important for this conversation but we need an interbank solution. We needed a ledger of accounts that 'we weren't a bank so we couldn't be the one holding everyone's money and keeping track of the flow of money in our network.' We were on something that the banks were truly in charge of but we didn't want to necessarily have our platform be owned by a particular bank. We wanted to be the sort of consortium of all of our partners.

JOE: Consortium is a keystone word I think here, that we should definitely come back to that.

CHRIS: Yeah and people talk about, if I use the word consortium blockchain, I think sometimes in contrast with the public blockchain, with the 'free anyone can join' blockchain.

JOE: Yeah. I'm particularly fascinated by this concept. That is a term that is used. I can confirm this. But you're doing that pretty early then because I feel like that concept didn't make it out into, I guess the public understanding, until recently or maybe I'm just behind at times.

CHRIS: Yeah, I guess so. I don't know. When I start working on this, I just spent a couple of months trying to read papers about what was in space and I guess, the only big name that was trying to do something like this was Tendermint.

JOE: Tendermint? Interesting.

CHRIS: You can pick out technologies like this because the magic number is always one-third. They can tolerate Byzantine failure up to one-third of the nodes. That was a theoretical result that was reached, just sort of the best you can do. Before BFT and then BFT is one of those solutions in that category and Tendermint does something similar.

JOE: That, I guess is sort of the background to this paper and it's impacting your life. I guess, what is put forth in this paper is to solve for higher tolerance. Would that be the right way to put it?

CHRIS: Did you say higher tolerance?

JOE: Yes. You're talking about the Byzantine tolerance is 30%, right? With Tendermint? But you're saying that they're doing something similar to that's before in the paper?

CHRIS: The most interesting thing to me, I think is probably, hopefully possible to convey concisely is the rationale behind the one-third number because that took a while for me to really appreciate but I think it really clicked when it did.

One of the hardest intuitions to get people to break, I don't know, way of thinking to shift, I guess is convincing people that consensus is even a hard problem because I had this conversation a lot with people that'd say, "I've got this JavaScript library here, for instance that just lets me broadcast a message to all the nodes in a cluster, so why can I just do that?" Why can't we just use one at a time to do it and if I detected someone's trying to cheat, if I get two different messages from someone that are conflicting, maybe I can just ignore them.

JOE: Not in finance. That's kind of ironic, I guess that you found it difficult to get people to come to a consensus about the importance of consensus.

CHRIS: Right. The basic flow of all these things is we describe them as voting systems. We have voting rounds where each time, like you said the blockchain of the ledger or whatever it is, just a linked list, so the problem of using consensus build database is we're just going to iteratively try to vote or come to consensus on what the next block is. What the next ledger entry should be?

Obviously, since we don't have a synchronized wall clock to go by, we have to assume messages can come in any order. We might all sort of speak up simultaneously and propose different blocks as the next one, at which point we have to start over and retry that. But furthermore, I can send different votes to different people if I'm trying to be malicious and that's where the tricky part comes on.

The rationale for the one-third number, maybe I can just try to come around to that and say it directly then, is that when we take a vote for what the next block is going to be, we need the supermajority. We need two-thirds of the participants to have all said the same thing and the rationale for that is it's actually easier to think of it backwards. Rather than saying, two thirds of the total, what we say is, "If we're going to allow some fixed number of nodes to fail, to behave maliciously --" you know, we traditionally call that number 'F' in the paper, then what we say is we need 3F+1 total nodes to be participating.

JOE: I didn't know that was sort of codified into how conflict is resolved on things like bitcoin during blockchain. It's inherent, I guess.

CHRIS: No. This is the total opposite of what bitcoin and Ethereum are going to do.

JOE: Because I always thought it was just going to be like a majority, I guess but what you are talking about is more like how the Senate would were to pass a resolution to the constitution, like it has to be an exceptional majority. I'm starting to understand why one-third, specifically. It's 3F+1, I guess.

CHRIS: The reason is because for each vote, every time I look at the results of a vote, I have to be able to assume that some number that we called F, of the people that I've heard back from are trying to cheat me. It turns out I need to be sure that the majority of the votes that I've heard back are from people who are actually following the protocol correctly and not lying. We need to be tolerant to two kinds of failure. One is that a node simply goes down and we don't hear from them and we don't receive a vote from them and then the other kind of failure is the Byzantine failure, that they're not following protocol in some way.

The reason I need 3F+1 nodes is because we need to be able to make progress, even if F of these number is we didn't hear from at all because they're down and then, I need 2F+1 votes because I need to take into account the possibility that some F of these votes were from cheaters and then we need to have more honest votes than lying votes.

JOE: That's pretty profound. I definitely going to finish the rest of this paper while conscious later today. I guess we're a little off with regard to math at this point and it's when you said, you spent I guess a month or so just reading papers around the time you started with Hijro and I guess did you stop because I feel like I've read just more white papers than ever thought I would outside of the academic setting, just trying to keep pace with what's been going on, particularly with regard to the web. I don't if you're familiar with like IPFS but these sort of directed acyclic graph things are popping up all over the place and platforms are even now being built on this concept.

I guess, Ethereum feels impractical in a lot of ways. These dime-a-dozen tutorials, when you started talking about the global computer that is Ethereum and the blockchain and it's going to change everything in the internet and you won't have to pay Comcast like some central authority or you just pay for each transactions. The reality of it is every time you do a write against a data store have, first of all, thousands of computers go and verify that and also, you don't want to store your information on a linked list. It's not feasible for storing large data structures and it becomes very expensive for the user and for the person, if you're maintaining a smart contract for the contract itself. These are volatile, all little points of value. It's impractical.

CHRIS: It's definitely a cost that you don't want to incur. In all cases, just a confirmation time is a cost you don't want to incur.

JOE: Absolutely.

CHRIS: There is one nice thing that that you can do in some cases, which is that people is talking about the piggybacking on these blockchains like if I have a system and I just want some extra assurance to keep it honest, then I can do things like periodically publish a hash of my database onto something like bitcoin or Ethereum.

JOE: Yeah. That actually happen with anyone in financial... They do publish stuff in the paper and this was before cryptographic ledgers but to basically prove that this was the state of something, I remembered seeing this somewhere, like there would be in financial news, like there'd be some crazy number or string at the top to verify what was on the string.

CHRIS: Yes. Of course, the irony there is that you really don't need some kind of blockchain if you want to do that because the fact that we're doing that before the blockchain has existed and doubly, it's funny because the first block of the bitcoin blockchain, the genesis block includes in it, I think a New York Times headline, which was intended as proof that Satoshi or whoever didn't spend years mining bitcoin prior to releasing it. It's supposed to be a proof of the time of the first genesis actually was.

It’s funny that we are actually already had this verification system and what that demonstrates is sort of a principle of consensus that I like to talk about which is that as you increase the time scale, consensus becomes an easier and easier problem. I think the reason why something like newspaper headlines are reliable means of a timestamp is just mostly because they're big and slow, because there's only one every day. I think the whole challenge like you said of, how a lot of systems kind of boiled down to having the white paper for bitcoin refers it describes bitcoin as a distributed timestamp server, something along those lines. The reason why you need a new technology to do that, I think so that you could have timestamps that are every of couple minutes, rather than every 24 hours.

JOE: That's a very interesting take on it. I guess, the more time there is, it is easier to reach a consensus. It's just interesting to think about. It's funny as humans like the longer time passes, the less reliable memory is, I guess, less reliable history as we conceive of it, I guess. It's different when you record something than the way that you hold in the brain that sometimes I wonder how much impact that's had on. It's a little ephemeral, I guess but it's interesting.

CHRIS: Yeah. I guess my statement is limited to the on-scale where we can actually fit into memory.

JOE: Right, that most of the times, it's the only relevant scale, I guess, like a blockchain doesn't have use outside of our use of it, inherent to it, so it's going to be seen through that lens, I guess of our use of it. I think it is kind of profound, a thing to think about that I definitely considered. You mentioned using blockchains as adding a little bit of... how do you put it? Like truthiness, I guess, we'll say. I know that's not how you put it but adding a little bit of security, maybe around something else but the reality is you can get away with that on a number of other levels. I think that's important and interesting to think about.

There seems to be this trend now talking about a blockchain as part of a bigger picture or consortium blockchain or a consortia of blockchains, right? Because a consortia would be multiple and then a consortium would be... No, a consortium would be a single grouping, consortia would be multiple groups.

Basically, going back to the problem you're trying to solve with Hijro, you have multiple banks and I believe eventually, I don't know if you work on it, there was a protocol that came out of that company to unify these blockchains, like a few of them. They demoed and everything. That, I think gives you some power with regard to access control but again, I guess, that's not a thing that you really need consensus for. So, where does it fit in? Aside from things like voting and transparent finance for maybe a political cause or in the case of bitcoin, just finance in general. In bitcoin, I feel like we got Mongo DB super hard in the sense that it just got applied to every domain and it applies to very, very few.

CHRIS: My boss at Hijro, Lamar Wilson really like to say that people talked about blockchain like it was hot sauce and they sort of sprinkle it on everything to make it better.

JOE: That's sad.

CHRIS: I guess, two answer to that one. One of the places where it absolutely captivates people's imaginations too far and doesn't work and then places where it doesn't work, so I want to start with the first here because the biggest mistake that people make is that there was this notion of tokenization that came out of Ethereum, where anyone could make a smart contract that represented something and now, also that I can trade digitally. Just like it's money or some kind of digital asset, so people want to talk about putting your car, putting your house on the blockchain or selling it there.

But it's just shocking how many times I had to remind people that if I make a smart contract that represents cars and I put my VIN number on it and I transfer you my car, at Ethereum contract in an exchange for a bitcoin, if I call the police and report my car stolen, they're not going to look at the Ethereum contract, right?

JOE: Yeah. Man, you're really right. People don't think about that enough. If your car is in the blockchain, your car still on the block.

CHRIS: What we had realize when we're selling solutions like this is that they're great for some reasons but you need actual legal agreements to underpin things when you actually make connection to the real world. The magic of bitcoin that can't really be replicated is that the coin actually didn't need a pinning to the real world because the thing bitcoin was running was itself. It just depended on hoping that people were going to find the coin and ledger valuable intrinsically and bitcoin never really purported to control things in the real world.

JOE: I guess, definitely not in the paper. There are some place that can buy in from some very specific elements of society that sort of cemented its place as useful but we don't really need to go to that road, I guess. I don't know. You know, my roommate is a lawyer and we have this conversation often and I feel like if we go down law and cryptography, we're going to be talking for too long, where we are at currently.

CHRIS: Right and that wasn't your question anyway. It was just what I respond to easiest because being a critic is always the easier thing to do.

JOE: I can feel you there.

CHRIS: One of the interesting things that I never even found too much about but I noticed this in a couple of passing references as I was reading stuff about Byzantine fault tolerance in general is that it seems to have some application in things like flight control systems and space ships because when you think about a computer that you're going to send into space, you have two things that Byzantine fault tolerance applies to directly. One is you need a lot of redundancy. You need these control systems, maybe you have a dozen things computing the same result because you can't replace the hardware when once you shot something to space.

The second thing is once you've sent something outside the atmosphere, all of the sudden, you're being bombarded with a lot more cosmic rays than you were before. Now, you actually really do this idea that computers can fail, not just by stopping but by producing wrong results. All of a sudden, it becomes a lot more real because you actually have physics slipping a bit at your computers.

JOE: I don't even think you have to go as far as space if you talk about just like a fleet of something, like self-trading cards. I suppose, in domain where there is an interplanetary file system, it's good to specify the planet we're talking about. Just having worked a little bit with robots in college, they lie all the time and they produce bad data constantly, so not even bad actors just incompetent actors, I guess could definitely... This is something that has to be, I guess on our minds as we move forward as the society that has more connected devices, which I think as much as I would love to have left this conversation off in outer space, I think bringing it around to the internet of things, which is sort of where this all began months and months ago is probably a good place to stop meandering through these cryptographic weeds. You can probably put a pin in this.

I think we've been talking about for a while now, I guess and just kind of trying to see what it is and where the applications are. It's constantly changing and never clear, I think is the conclusion that I've come to. I don't know. I think, just kind of shooting the breeze about it is a fitting end to a series of Frontside engagements in this space, for the time being.

CHRIS: I've seen several people try to tackle the space of how to stop relying on things like Google Drive to store our data because I think a lot of us have realized that we're tired of losing all of our family photos every time a hard drive dies but a lot of people are uncomfortable with trusting Google with everything. This to me seems like a perfect opportunity for people to start building redundant systems among their home and friends.

JOE: Yeah, I completely agree. I'm actively trying to do exactly that right now.

CHRIS: Oh, cool. And you don't necessarily want your cluster of machines that's running on all of your family's computers to be able to go down if your 10-year old get some virus, right?

JOE: Right and also, there's definitely things that you want just within your home or even just within your section of the home. I guess you could layer chains, to kind of manage those interactions?

CHRIS: Sure. I'm not exactly sure what you mean by layering chains.

JOE: You could have consortia in this case. If you had like a hypervisor, almost like a control notice, essentially or some type of view from above of this situation, you could say, think of it as a family scenario. We have three different houses on this call that all belong to our immediate family and cousins and whatever and it's like, me and my siblings, we have information that we all want just within the siblings. We don't want Mom and Dad to know. We don't want the cousins to know, so you could basically use like a blockchain to kind of date access to data that is held within that consortium and then the consortia could communicate amongst each other. Only the pertinent information that they wanted to allow access to at that time and then, internally of course, you could have all these different mechanisms for how you actually store that data or how you actually serve it up. It's pretty complicated.

CHRIS: Yeah, I think you made a lot of sense, though.

JOE: Yeah, cool. I'm hoping so. There's been some work on it out of Microsoft, actually.

CHRIS: On the files storage problem, specifically?

JOE: I guess this is like with a smart home and kind of just teaching devices to cooperate and ask each other. If you had a section of connected devices that maybe were related to the workflow that a human being might go through to get groceries or something and then a section that's related to doing laundry or whatever, eventually, they would learn to communicate in the laundry grouping and could say, "Hey, grocery people. We're out of soup," or something like that.

It's sort of almost happened organically, I guess. I had not actually felt like I found that paper. I've only found references to it. This is where I need to get something like academic access but that was interesting stuff. I don't know how I end up here, either. This has always happening when you're talking about this domain. Anyway --

CHRIS: People's ideas, it's just sort of generally inspiring concept so people is following you everywhere.

JOE: Yeah, it's heartwarming. You know, with my ICT, I could look back and see exactly where I usually came from than [inaudible], the name of the farmer who grew with. I don't know. It'd be so much easier to fake most things, really when you think about it.

On that note, I hope that this conversation was... I know that there was no JavaScript and I apologize for that but I hope that our audience finds it interesting on some level and I want to thank you for your time. Chris, it was really great talking to you and getting your take on these things as somebody who's been in the industry for a while. Definitely, some fascinating points to consider and definitely, I will finish that white paper, probably this evening because it's pretty cool.

If anybody in the audience has anything they'd like to ask you about pertinent to this conversation or anything else, where is a good place to get a hold of you?

CHRIS: For me, it's mostly Twitter. I'm @chris__martin. I'm also at Type Classes, if you want to talk to me about our new business.

JOE: Cool. This has been Episode 104, I believe of The Frontside Podcast. Frontside, we're a consultancy based in Austin, Texas and we love writing elegant, sustainable code and just producing good stuff, really. I think that's what we're all about. I think, we can agree at least, that's a core tenet of what we do and if you would like us to produce some good stuff for you, feel free to get in touch with us.

Also, feel free to reach out via email if you have any ideas for future topics or any feedback about this episode. I also want to thank Mandy for producing this episode. You can catch us next week, I believe for our talk with Brian Douglas on Probot and Robert will be hosting that one, as far as I know. Thank you all for your time and feel free to reach out. This has been The Frontside Podcast. I'm Joe LaSala. Chris Martin, thank you for joining us and have a good day, everybody.

In this episode, Michael Jackson of React Training and Rob DeLuca and Taras Mankovski of The Frontside talk about what is a component, and what a component is specifically in the context of React.

They also discuss when it stops being a component and becomes something larger, how it has changed the way we develop UI, and thoughts on container and presentational components being synonyms for controller and view.

References

Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at [email protected] or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

TRANSCRIPT:

ROBERT: Hello, everyone. Welcome to Episode 103 of The Frontside Podcast. I'm Robert DeLuca, a developer here at the Frontside and I'll be today's episode host. We're going to be discussing what is a React component or what is a component with Michael Jackson. I'm pretty excited about this topic, a sort of off from a tweet that I sent out after a long workday, when it is something being called "component" because it was built with React components but it was more like a mini application? Then Michael replied to my tweet, as they're happening and he said, "What is your definition of a component?" which is exactly what we're going to be discussing today. I thought that was a really great question.

With me, as a co-host is Taras Mankovski.

TARAS: Hello, hello. I'm also a developer at Frontside.

ROBERT: Before we get into the discussion, I would like to make a little announcement. We've been working on building a suite of testing tools to make acceptance testing JavaScript apps like React or Vue or Ember or anything else kind of JavaScript, fast and easy to maintain over the past few months. We call it BigTest. If you follow me on Twitter, I'm kind of loud about it. I love this project that we were working and one of my coworkers just published a blog post, giving an introduction to acceptance testing on React applications with BigTest. If that sounds interesting to you, you should check it out. We'll leave a link in the show notes. Now, let's jump right into it.

Hi, Michael. How are you doing?

MICHAEL: Hi Robert, I'm doing well. Thank you for inviting me to be on the podcast.

ROBERT: Oh, no. Thank you for joining. I feel like this going to be really fun conversation. We went back and forth on Twitter a little bit and I was like, "You know what? This serves really well like a free flowing conversation."

MICHAEL: Yeah, it's something I really like to talk about, specifically, when we're talking about components or when we're talking about React components. I think there's a lot stuff there to discuss and I think that React, specifically has really, at least defined that word for me. When you were talking about your mini application, I was like, "Oh, yeah. That's cool," and to me, that's kind of what these components have the potential to be, what these React components have the potential to be. It's kind of like almost these miniature applications that you stitched together to make a bigger one.

ROBERT: Yeah, that's really cool. I was frustrated at the end of that day, just because that had so much logic crammed into it and you can kind of see that come through in the tweet but I'm not going to lie. After I sent that tweet, I was a little disappointed with myself because it came off a little bit like flangy but I guess we could just kind of jump right into defining what is a component.

MICHAEL: When I saw your tweet, I was like, "Oh, you know like --" and of course, I don't know the component that you're looking at. It could have been terrible. Totally, it could have been terrible. I'm totally willing to believe that it was not a good component. But writing React is hard, especially writing good React is actually hard. At first, I thought it was easy but I think it's easy to solve your immediate problems but to write React to that is generic enough to solve lots of different problems, I think it's actually very, very hard and it's something that I've spent the last couple years learning. Anyway, that's kind of a tangent.

But regardless of the component that you were looking at, the way that I've tend to think about these components is we used to have a model for thinking about how to build frontend applications --

ROBERT: Like MVC?

MICHAEL: MVC, that's the one. That's the one that talking about. You have, here's your model, here's your view, here's your controller. You know, there are separate logical entities and lots of times, those even live in separate files on the file system and we keep them sort of separate and spaced out. As far as I can tell, that's a sort of paradigm. I learned it in school. By the time universities catch up with industry is at least, like twenty years, so it's probably something that was invented back in the 60s or 70s.

ROBERT: I think it was like the 80s because Charles talks about it a lot and sort of Taras, actually because we're building something that's like a composable model, just like the Vue of React is a composable view, its components. I think it's interesting because I was listening to the Changelog Podcast and it sounds like you worked with Ember for a while.

MICHAEL: I did, yeah.

ROBERT: I forget, which podcast that was but we can find it and we'll link it to the show notes but I thought that was really interesting that you also came... Oh, maybe not came from Ember. You had experience with for, at least a couple years and that's where I came from. That's kind of where that tweet came from and was like, "Man, I don't like what happened to the word component," because when I think of component, it's like something that is encapsulated in a small piece of UI. But I'm okay with letting go of that.

MICHAEL: Well, yes. Ember came out of something called SproutCore, which actually originated at Apple. Tom Dale used to be a developer at Apple. I'm sure you all know all of this but just for some sort of back story for others who might not. Apple was a place where MVC was really, really big. The whole Cocoa frameworks. They're all very much like, here's your controller, here's your view, core data has all of your models, that kind of thing.

It's a software development philosophy that goes back a long time and has deep roots and I'm not here to suggest that because it's old it's bad, because lots of old things are actually very, very nice and good, especially in programming. We're starting to see a resurgence of functional programming ideas, for example, which have been around forever, since at least, the 60s or even earlier than that. It's not necessarily that I think that because it's old, that it's bad. I don't.

ROBERT: Right, right.

MICHAEL: But the thing that I do see in these React components is they kind of go very much against the grain. If you had, for example your model, your view and your controller as these vertical silos, just imagine turning that whole thing on its side and then cutting a slices of that, so that each of your React components has elements of MVC in it. They're all sort of mixed together.

I run a training company called React Training and whenever I'm doing one of my training workshops, the way that I talk about it is a component is able to encapsulate three things: markup, which is the view essentially; state, which is essentially your data or your model; and behavior, which is essentially the controller, so what happens when the user is interacting with the view and clicking on the buttons? What do we do in response to the user input? You’ve got all three of those MVC elements in the React component.

In fact, I've been meaning to kind of coin the term for a while. Instead of MVC, I call it MSB -- markup, state and behavior.

ROBERT: You heard it here first.

MICHAEL: That's right, here on The Frontside Podcast, we're coining new terms.

ROBERT: That's pretty great. I guess coining off of that, is it fair to say that MVC kind of still lives on, except it's now in React? Or it's kind of more sliced up into smaller, more digestible pieces? We can always come back to this composability element, right? Would you say like really React would made it possible to compose many little MVC apps?

MICHAEL: Yeah, exactly. The thing that people really, really love about MVC, I think you still have it in React. MVC, the thing that people always come back to is the separation of concerns. Let's just say, "I don't want everything sort of mingled together. I want it to be very clear. What is my model? What is my controller? And what is my view?"

The cool thing about a React component is if you look at it, you still have very clear separation within the single component. You have a very clear separation of all three of those concerns: your state lives in an object called 'this.state,' then your view is whatever you return from your render method. That's in a completely separate spot, since still in the same component and then your behavior or your controller usually has its own method, so you can inline those in your render method or you can pull them out if this is how you'd like to do it. You can pull them out into instance methods. You can still have kind of that separation of the concerns within a single component.

I think to your point, the React component model is all about composition, so this is kind of a term that we've actually adopted in other areas in technology. It's sort of just coming to frontend. The idea is you've probably heard of a service-oriented architecture for design in backend systems. These servers over here are application servers, these are database servers, here's our caching tier, here's our Ingress or LoadBalancer and maybe, you stitch them all together on the backend into one coherent system. You know, here's our storage and our image-resizing services. You stitch them all together on the backend into one coherent system but it benefits you to not build them all as one part of sort of monolith.

We've got a lot of benefits from the decoupling. For one, if one piece of the system fails, the whole thing doesn't go down, so you can like swap it out or upgrade it and replace it with something else. I feel like that is kind of a similar idea to what is going on the frontend with these React components.

ROBERT: Oh, microservice components.

MICHAEL: Yeah, exactly. Each component is kind of like you said. It could be like a miniature application and it could be totally self-sufficient and I could drop it onto a page and it could just do its own thing or what I could do is I could take that app, that component and I could drop it into a larger app that can speak to it and can communicate state to it via the props that it sees and then can get state back out of it via these callbacks. I kind of view it as like all of these miniature systems that they can either be completely encapsulated and self-governing on their own or you can take them and compose them with a larger app.

ROBERT: That's really interesting. I guess what is a component specifically in the context of a React. I guess, we kind of just answered that, that you can bundle all these things together, right? Does that make sense?

MICHAEL: Yeah. The beautiful thing about this composition model is you can have all three of those things in the same component: markup, state and behavior. You can have all three of them right there, encapsulated in one component or once you discover more advanced patterns with React, you can actually make it so that a component only has two of the three or one of the three.

ROBERT: And then it kind of like passes callbacks or props or state around?

MICHAEL: Exactly. It can essentially delegate the responsibilities for handling the other pieces that it misses to other components around it. There's a pattern that I kind of coined last year called render props.

ROBERT: Oh, yes. I remember hearing this on Changelog Podcast. I was actually one of the people that at first thought it literally was a prop name render.

MICHAEL: Well, I mean it's not a bad way to think about it. It could be a prop name render.

ROBERT: But then I found out it actually is a prop that you send JSX too and render whatever is there.

MICHAEL: Yeah, exactly, a prop that you used to render stuff. It's the way that I describe it. When you think about it, any component, for example that accepts a render prop is really just delegating it's rendering to some other function. It can contain the two pieces: the state and the behavior, but then it can sort of delegate this third piece, which is the markup and say, "You know what? I don't really care about, specifically what I have to render." I don't have an opinion about that. You just give me a function and I'll give you my state and possibly, some behavior callbacks and then you can tell me what to render. I'm like a component that I have two of those three pieces. I don't have the markup, you just give me a function, that I will call when I need the markup.

ROBERT: That's really powerful.

MICHAEL: Yeah, exactly. I can have all three in one place or I can also with this component model, just delegate one piece or even two pieces, using these kinds of patterns to other components, so it's really nice.

ROBERT: I'm always have to come back to this because this is where I kind of cut my teeth in the frontend world. I feel like render props are very similar to the yield pattern in Ember, where you can yield out a component and place it anywhere inside that template block. I think it's really similar. Because we have a large base of Ember developers that listen and they needed a draw like a parallel, I would say that's almost a parallel. I might be off on that. Taras, would you agree with that?

TARAS: Yeah, it's very similar. There is one little 'gotcha' with render props in React, which I think Ember deals with a little bit more gracefully. I do use React all the time now. I use it much more often than I use Ember but --

ROBERT: Same.

TARAS: Yeah and I'm kind of curious, Michael if you would think about this. Because there are certain things that, for example, JSX does, like one of the attributes of using render prop is that you want to pass stable functions, like something that is actually defined in init hook, so you're not necessarily recreating a new identity for this function every time that you pass into the render prop. Is that right?

I think for someone who is might not be familiar with this, it's a little bit counterintuitive because it just kind of like, you just pass something and then you later realize, "Actually, I can't really do that because now your components were rendering over and over again." I'm curious like where can we kind of innovate in that? Because in Ember world, for example, it's really safe to use render props. If you're delegating to the context to do the rendering, you can very easily pass a block of template into the component and then the component will know how to render that in a performant way.

My experience with render props in React was that the pattern in Ember is it's a very common behavior to delegate to the context of how the children of a component are rendered. This is the primary purpose of the yield in Ember and this is used by a lot of the components to provide APIs, so essentially, you're yielding, you're sending into the children function behavior that you want the developer to use while consuming your component.

The parallel with React is that you would have, essentially a function, like you have a children render prop, which is a function that receives so that when a component is rendering the children render prop, it's passing some data into that function and it's invoking the children function and it's passing to it some data and then that data is being used inside of the children render function.

Now, this mechanism works really well in Ember because Ember is using its own templating engine, so it manages every placeholder in the entire template as being passed into the component. It knows exactly what has changed in the function. Looking at that, the value just passing through component as a whole thing. It's actually managing each individual spot where the dynamic elements needs to be rendered. What that does is it allows it to manage the entire children function so you don't need to worry about stabilizing the render props. You don't need to assign them.

Because there's also other challenges that kind of arise when you have to move the actual function that you pass into children. You have to move into the body of the actual component. Your ability to compose the state that is within the render function is kind of limit because you now have kind of broken up into different places. I'm a little bit curious what are your thoughts about this? And if there's any innovation that's going to require or improvements that will require in the way that React handles render props.

ROBERT: I definitely remember seeing some tweets from you, Michael about this, like very recently.

MICHAEL: Yeah, just yesterday in fact, I was talking about this on my Twitter. First of all, thanks for the question, Taras. I appreciate it. I think you kind of nailed it with the difference between Ember and for example, just JSX -- Handlebars, really and JSX is that Handlebars is not JavaScript. Handlebars is a language of its own, really. As the implementers of that language, the Ember team or the Handlebars team has complete control over how things work.

For example, when functions are allocated. If they have a yield block, for example, that yield block does not have access to things like JavaScript Scope. It really is just a block within the templating language and so, they can decide when they're implementing that language. They can say, "We're only going to ever allocate one function for this yield block."

JSX on the other hand, it really is just sort of some syntax sugar over JavaScript, which is nice lots of times because you can use things like JavaScript functions scope. You can do things like refactor it, like you would any other piece of JavaScript and pull that function out into its own variable or something like that.

In a lot of ways, it's more flexible but with that flexibility comes this extra concern of what happens with the prop passing and it's a real concern but I don't think it's as big of a problem as most people have heard or might think it is. The real problem, the root of the problem is that if you have a pure component in React, the pure component is optimization tool in React, if you find that your component really is a pure component of just a pure function of its props and state, and that it will never render anything different, if it receives the exact same props and state, you can declare that that component is a pure component. Instead of just a regular component, it's now a pure component and so, it will actually opt out of the render cycle if it receives the exact same props and state on subsequent render. By exact same, what I mean is like identity triple --

ROBERT: Yeah.

MICHAEL: -- Same. That's an optimization tool that you can use in React to say for example, maybe I've got a component and for some reason, it's always receiving the exact same props and it's rendering a lot. I can say, "You know what, React? Don’t even waste your time re-rendering this component and doing the reconciliation around it and everything like that. If it receives the exact same props, don't even waste your time. This is a pure component. It received the same props. It's going to render the exact same stuff as it rendered last time, so it will completely opt out of the render cycle," so React won't even call the render method, won't even bother doing the reconciliation for that component or its descendants. It's actually a really, really nice way to get a little performance boost in that situation.

ROBERT: Interesting. Does that mean, rather than passing some JSX that returns out an anonymous function, you would rather have like a pure component over that?

MICHAEL: All it really means is that when you identify a place in your app where this is happening, instead of extending React component, you can extend React.PureComponent and now you component opts out of the render cycle.

ROBERT: Gotcha. Because I see a lot in React applications, it will just return some JSX out of anonymous function, kind of think, Taras was getting at, when each re-render happens, it's recreating a new function and all of it were done inside of it, from the JSX because it's just a new function that's being bound each time.

I think my takeaway from that and correct me if I'm wrong, is don't pass JSX and an anonymous function or I guess, from your tweets yesterday, that's kind of a premature optimization. Maybe, not pass as anonymous function but pass as pure component.

MICHAEL: I hadn't yet gotten to directly addressing Taras's concern but the idea is --

ROBERT: -- Jumping the gun.

MICHAEL: Yeah, it's fine. If you do have a pure component, that is when you're going to have a problem with this render prop pattern because you can't pass a render prop to a pure component. They just don't go together. Well, sorry. I should actually qualify that. You can pass around a prop to pure component but you need to make sure that it is always the exact same function, otherwise why are you making this thing a pure component, so there's a little bit of a problem there.

I actually wrote the documentation on React's website on render props and there's a little caveat section where I discuss how you could get around this, you could convert it into an instance method or something else but then the concern at this point and this is why I said it's not such a huge problem because we're getting very, very specific now. Let's assume that we've got a pure component that is the child that we want to render and it accepts a render prop and that render prop depends on state and/or some sort of scope that it needs in the render method.

Now, we've got a problem because we need to generate a new function in the render method and the fact that we're generating a new function and passing it to a pure component means that we are essentially negating all the benefits of extending pure component in the first place. First of all, in order to experience the problem, you have to get very, very specific and it's not easy to actually get into a point where the problem manifests itself.

But then for the second part, fixing the problem is actually not tricky, so the way that you would fix this issue, there's a couple of ways to fix it. The most common way, I think to fix it would be to just say that pure component, let's just move that down one level and we'll put it inside the render method of the component that takes the render prop. The component that takes the render prop is no longer pure but the pure component has dropped down one level and we can still get all of the benefits of a pure component and again, its whole descendant tree lives underneath it.

ROBERT: That make sense.

MICHAEL: So, we can still get all the benefits of having a pure component, while still being able to use the pattern. But again, just getting back to what we were saying at the beginning. The render props is just one example of an advanced pattern that actually lets you delegate one of these three pieces to somewhere else. It's just one pattern. It's not like there are others as well.

ROBERT: Yeah, so getting back to what is a component, is there ever a line that's drawn, like when does it stop becoming a component and it becomes something larger.

MICHAEL: It's actually interesting because for a long time, we didn't have a component model on the web and I think --

ROBERT: It's very true.

MICHAEL: -- still, like we mix to all three things together in our jQuery code. It was just like there was some state mixed in with some markup, mixed in with some behavior. It was all kind of mixed into one place.

ROBERT: Nice plate of spaghetti.

MICHAEL: Yeah, exactly. As soon React came along and actually gave us a real component model that really worked where we could actually identify these pieces, then all of a sudden, everything is a component and you really can make if you want, like if you really wanted to, you could make your entire application out of components. It could just even behavior stuff like, "I want to fetch some data," that could be a component or, "I want to listen to the window scroll or the window size," that could be another component. "I want to render an image or a bit of text or do some measuring or I want to do some parsing of some data or something like that," all of this stuff could be represented as components if you wanted it to.

Of course, you can still extract those functions out into their own bag of utility methods and lots of times when I write a React Apple, I have a little bag of utils and I'll go and reach in there and grab those as I need them. But for the most part, most of my React apps are just components all the way down, so there's not much that I can't do with a component. The cool thing about that is what do you get when you have components, where you get reusability and sharability. I can make a component and I can just share it with you, Robert. I could say, "You want a component for listening to the windows size? Here you go. Here's the components. Got to render --"

ROBERT: Drop it in.

MICHAEL: "-- It will give you the size when you need it," so that ability to share code is, I think super important.

ROBERT: Yeah, I think so too and it really helps you build applications rapidly because you can just start dropping these little components that are contained in composable throughout your entire app.

I guess, I'm still clinging onto like there is maybe a line that is drawn and I think from the React community, there were a couple of terms coined called the container component and the presentational component, in which I immensely mapped those to basically being synonyms for controller and view. It's like the container components is kind of like a controller, like it delegates the view... Or decorates the view, not delegates. And the presentational component is just like we're talking earlier -- pure component. It's just taking props and rendering that. Is that fair to say?

MICHAEL: Yeah. As far as I can tell, that's a pattern that was first talked about by the redux community, specifically I think Dan is the first to discuss that that pattern and it's a pattern that I think can work well. I haven't ever found it to be especially useful in my code but I can see how other people could like it for their code. I really just think it has to do with how your brain works. If you prefer structuring things like that, if you prefer like the vast majority of your components to just be these little view layers and then your main container components to hold all of the logic, I want fault you for that. I'd say, that's fine you can build your app like that.

But I do think that when you're thinking about components like that, you are thinking about the much less like these miniature applications. Basically, in my opinion it's kind of a false separation. It's a separation that doesn't really need to exist because essentially, the thing that I really love about these components is you have encapsulation. You encapsulate everything. As soon as you adopt this pattern of containers and essentially, just these presentational leaf nodes, they're not as useful on their own. They just encapsulate some of the rendering logic.

ROBERT: That's very true and they're not reusable. I mean, it's very, very hard to make those reusable.

MICHAEL: Well, yeah. Most of the time, they're designed to be used with a very specific container. It is like, "Why couldn't we just put that in a container." Like I said, I really don't fault anybody for using them. It's just not how my brain works. I tend to think more about components as if they were these miniature applications and they're going to be useful on their own for the most part.

One place where I have started to do that, the fourth thing that your components can encapsulate is style information, which is really just kind of the markup but it's the fourth thing and I think that I've really started to employ that kind of pattern when styling comes in. But it's not for this separation of containers and leaf nodes. It's just because I would like to encapsulate some of the styles down at a lower level or be able to reuse some of the styles down at a lower level, so that's when I'll typically start breaking up one of my components into multiple kind of tightly-coupled components but it's just for the sake of the styling, not really in any of the control flow or the logic.

ROBERT: Right. When I first got into doing React, I was first like a little befuddled and then, I fell in love. I was like head over heels. When I hear about separation of concerns, it's always talked about like we need to separate HTML, JavaScript and CSS. They're all different things. They just need to be separate. I understand that. I kind of come from there but for me, my personal opinion is coming from the context of single-page apps, there is no feature that you can ship without the three. I don't think there is a complete feature that exists.

Sure, there's edge cases that's like a blanket statement but I think those lines of separation is way more blurred these days and I think that's what React just unlocked. That's kind of where all of this is sort of rolling downhill and it's not a train. It's really powerful to be able to encapsulate all of those things together and then just think of your UI as these components. That's why we call them components. They componentized.

Like when I have a butt-in and I drop it on the page, I don't want to have to go and make sure that I have the right class that's wired up in some other file. I can just drop the button in there and it's going to do its thing. I can pass the props, it'll change it, that's fine. It lives within itself.

MICHAEL: Yeah, I would say you're absolutely right. You can't ship anything meaningful without having, at least some styling in there, unless you're shipping very, very basic behavioral style components. It's kind of one piece, I think like the React components are able to encapsulate their own styles but there's no, I guess officially recommended way to do it, which is where I think React get some of the critique, like some people come in and say like, "There are a million different ways to do styling in React and therefore, React is supposed to something like --" I guess, yeah, some of the other frontend frameworks have like, "This is how you do styling in our framework."

ROBERT: Right, like the lack of convention.

MICHAEL: Yeah, exactly. It's a blessing and a curse, though. If there's a lack of convention, it's harder for newcomers to know exactly what to do.

ROBERT: Yeah, or like what's best for their use case.

MICHAEL: Yeah, exactly but then on the other side, it's kind of a blessing because people are free to experiment and they don't have to feel like if they're experimenting, they're going sort of against the grain of what the community has already accepted to be the answer. I think that freedom to get out there and experiment is really valuable as well.

ROBERT: You can see but I'm nodding.

TARAS: I'm just curious what your thoughts were. This Suspense API is something that's... React kind of lead the way with components and now, the changes that are coming in with Suspense API coming in and it'd be great, if you can, are you able to explain a little bit about what it does for people that are not familiar and I'm curious what your thoughts about it.

MICHAEL: Yeah, for sure. The Suspense API, I think is actually, with regards to what we've been talking about, with the encapsulation of markup, state and behavior and possibly styles, I think the Suspense API is kind of the React teams attempt to sort of encapsulate or generalize, at least one more thing, which is asynchronous behavior.

The truth is, the most common async behavior that we know of, that most people are familiar with is a fetch, a data fetch -- you go and fetch some data. But there are others, there are things like loading of images and animations and navigation and things like that, where you have some time that passes in between when you initiate an operation and when you're actually able to render as a result of completing that operation.

How do we manage or how do we generalize that and how do we think about it? The Suspense API is basically a way to declaratively say, "I need this async operation to be done." Let's just use the example of a fetch. I need this fetch. I need to have fetched this data in order to render this view and don't even attempt to render this view, unless the data has been fetched. Before the async API or Suspense, as they're calling it, you would basically have to manage this asynchronous behavior yourself. You would basically have to say, "Go and do the fetch," and while we're doing the fetch, maybe I'll set a loading flag in my state and say, "Loading is true," and then when the fetch gets back, I'll say, "Loading is false," and then I'll render. Maybe, while loading is true, I'll show like a spinner or some loading dots or something.

What the Suspense API allows us to do or what they're hoping to do, again it's all very like... I don't know if I made this clear. It's still very, very, very, very early days for this API and I don't actually know when it'll be ready. But anyway, the idea is to be able to say --

ROBERT: Would you say the Suspense is killing the community?

MICHAEL: The suspense around suspense.

ROBERT: A terrible pun.

MICHAEL: Anyway, the API is basically just a more declarative way to indicate where this asynchronous stuff is happening and give React sort of clues, if you will, to say, "There's some asynchronous stuff happening here, just so you know." That has many applications in the real world.

Let's say for example, you were navigating in a master detail view and you're tapping down the master view and loading these detail views, if you tap a master view and you haven't yet loaded the information for the detail view, instead of sliding to the detail and showing the data still loading there in the detail view, you might want to show some sort of loading indicator while you're still in the master view. Then, if it's taking a while to load, they can actually select something else from the master view and in that case, you would cancel the old fetch and start another fetch. It's just supposed to make things like that, kind of feel a little bit more fluid and a little bit more intuitive to the programmer, so you don't have to think so hard about managing a lot of that complexity in your own head.

ROBERT: Yeah. By the way, I love the mobile first language that you used. You tapped here, you tapped here, that slides in.

MICHAEL: Yeah, for sure. It's all we're building these days.

ROBERT: Yeah, it's very true.

TARAS: It's interesting because the Suspense API, you wouldn't really imagine it to be within the scope of a view in a traditional sense, to [inaudible] but considering the scope of a component in React, it makes sense but I think people might not imagine as being something that would become part of core, potentially in React. I'm curious like what do you think other areas of React and I'm glad that the scope of components in React is so broad because it kind of opens up this question to be pretty much anything in React ecosystem. But is there an area of React building or the aspects of applications that you would like to see an improvement in or some kind of a change or something that hasn't seen the right amount of innovation in the same way that we've seen in other areas?

MICHAEL: Basically, is there a place where I would like to see the React ecosystem improve?

TARAS: Yes.

MICHAEL: I know this goes kind of contrary to what I just said but I would like to see a little bit more cohesiveness. I feel like in some ways, the freedom is good but I also feel like in some ways, for the last couple of years, we've been just sort of like rehashing the exact same old problems again and again because React really made everything else so easy, like a lot of the stuff that was hard about building web apps, just got really easy when React came along.

I'm not saying that because I have React training company. Of course, my livelihood right now depends on React but honestly, if it wasn't for React, I think I probably would have quit and done something else because it was actually getting really, really difficult for me. I was trying to build an app in Ember before I started with React and I just couldn't do it, you know? I just couldn't get the level of polish that I wanted in my app and get all the bugs out and get it working exactly how I want it to. It frustrated me, actually that I've spent a lot of time.

I spent about 18 months, about $100,000 of my own money, just down the drain trying to build this app, trying to get it out the door and I wasn't able to finish it off. At the end of the day, I really started to question like, "Was it me? Do I just suck? Am I not a great developer? Is that the problem?" You really have to start asking ourselves hard questions like that when you put everything you have into something and it doesn't work out and then React came along and I was like, "I was just using the wrong tools." The tools were the problem. It wasn't me. There is a different way to think about this about building stuff.

I thought the way that I was doing it was the only way that existed to build things but it turns out, it's not. I used to not understand what were people talking about when they were talking about functional programming or what do they talk about when they're talking about composition, solving problems with composition, instead of inheritance. I didn't even understand what that meant. But all I knew is really smart people would say stuff like that and I was like, "What are you talking about?" Now I feel like, because of React, I've gotten it.

Again, to get back to your question, Taras, React made a lot of the stuff that we used to worry about, that we used to think about. It made it easy and so, we could build amazing things now a lot more easily. But now, for the last couple of years, I feel like we've just been sort of rehashing a lot of the same stuff.

I would really like to see us, as a community sort of tackle the next level problems. I think the React Suspense stuff is definitely getting there. That's a problem that I really don't see anybody else sort of address, which is how do I make it easy to deal with the fact that applications by their nature -- these networked applications -- are asynchronous. How do I deal with that in a declarative way? That's why I'm encouraged by that work because I do think that it's kind of one of the more forward thinking things right now that's going on in the React community but I would like to see us in general, sort of like get past talking about styling and get past talking about service and rendering and move on.

ROBERT: Right and I'm going to assume you have this really unique experience since you do a lot of trainings. I follow you on Twitter and it's just always talking about where you're flying to and who you're training, so the things have to come up there where you see these things in pattern over pattern over pattern.

MICHAEL: Yeah, exactly. I see like a lot of and this again, gets back to Taras's question. I train a lot of people who are very new to React and I see people who are new to React, they really don't have a ton to go on besides just like blog posts and Medium pieces and podcast like this one and who am I? A lot of people in their React community don't even know or care who I am. It's like, "There's a guy out here who are saying stuff about React. Maybe I should listen to him. Maybe I should listen to somebody else," and it's confusing. It's confusing, I feel like, for people who are just getting into React. It's confusing. Like I said, experimentation is good but I guess, I wish the experience of coming to React was a little bit more like the experience of coming to Vue because --

ROBERT: Oh, like it was a beaten path.

MICHAEL: Exactly. I don't actually think there's not a whole lot about the Vue technology that is compelling to me and let's not dig on it. It's just --

ROBERT: A personal preference?

MICHAEL: Yeah, exactly, just preference but I do think the thing that is very compelling about the Vue experience is just the cohesiveness of it all. You go to Vue and there's like a way to do server-side rendering with data fetching and styling and --

ROBERT: They have a CLI and --

MICHAEL: And a CLI and a component and all these stuff. Yeah, and a router built right in. Anyway, I think that's a way that the React community could improve. I don't know if that'll ever happen because the React community at heart is artists and hackers and those people are traditionally very reluctant to be corralled and like I said, it's a blessing but I think from the perspective of people who are new to the community, it does tend to cause some confusion.

TARAS: I want to add to what Michael is saying. What's interesting and I'm sure Michael sees this in his training but the kind of people that use React is very diverse. There's this kind of original group or there's kind of mentality that prompted the early adopters of React and now, we're seeing these companies that are traditionally enterprise-y with MSE backgrounds and coming into React. It's really interesting to see all this kind of worlds collide and then see what's happening as a result. It's definitely interesting on what's going on now.

ROBERT: This is an excellent stopping point. I really agree. I come from Ember background so I would like to see a little bit more convention but I think it's okay. It would be nice to see that.

Thank you, Michael for coming on. Is there anything that you would like to give a quick plug for and where people can reach you?

MICHAEL: If you want to support the work we're doing, you can sign up for one of our upcoming workshops. We've got one right now on ReactTraining.com. We've got a workshop coming up, actually in my hometown of Carlsbad. You can come out here in July and hang out with us and do some React training. We got a really awesome host here who's right here in town. We're doing some React training workshops on July 25th through 27th, I think and then, other ways that you can support what we're doing is publish in all my open source code at GitHub.com/ReactTraining or you can follow us on Twitter at Twitter.com/ReactTraining or at my personal account at @MJackson -- Michael Jackson.

ROBERT: Awesome. I really appreciate you taking the time to come on.

MICHAEL: Yeah, thank you so much. It's been a pleasure.

ROBERT: This is a great talk. Cool.

Thank you everybody for listening. We are The Frontside and we build UI that you can stick your feature on. If you would like to give us feedback, you can always reach out to us on Twitter at @TheFrontside or you could email us at [email protected]. We're always looking for any new topics or things you would like to talk about or things that are interesting to you.

As always, thank you Mandy for producing our podcast. It's @therubyrep on Twitter and on June 28th, we're going to have Chris Martin on to discuss blockchain development.

In this episode, Harry Kaplanian of EBSCO joins the show to talk about the FOLIO project: a community collaboration to develop an open source Library Services Platform (LSP) designed for innovation. He discusses the why behind the the decision made to embark on this project, the benefits it brings to the market, and what makes it different from current offerings and other open source projects.

Harry also shares where he sees FOLIO going in the future, challenging and unexpected outcomes of making the choice to go open source, and advice for other businesses that are considering embarking on a similar journey today.

Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at [email protected] or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

TRANSCRIPT

CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 102. My name is Charles Lowell. I’m a founder and developer here at The Frontside and I’m going to be today’s host. So today, we’re going to be talking about the business of open source with Harry Kaplanian. Harry’s someone that we’ve had the pleasure of working with over the past year and collaborating with on a very unique project, which we are going to get into later. With me is Robert DeLuca. Hey, Robert.

ROBERT: Hello.

CHARLES: And before we start out today, we just wanted to take care of some quick news. Just so you know, we released BigTest React. This is actually something that grew out of the work that we’ve been doing with Harry. It’s a set of React helpers to acceptance test your React applications so that you can make sure that you know that your application is actually working on actual browsers in actual life. So, that’s exciting. You can go check it out at BigTestJS.io. And with that said, let’s get on with the project. So first if all, welcome, Harry.

HARRY: Thank you.

CHARLES: I teased this in the intro, but we’ll go ahead and say it outright. The project that we’ve been working on with you and with EBSCO is a project called FOLIO. And it’s one of the more unique projects we’ve ever had the pleasure of working on. So, maybe you could just give us a brief overview of what exactly FOLIO is and how it came to be.

HARRY: Sure. So, FOLIO I think can best be described as an open source platform for services. Our focus has always been the library market and so, currently this platform exists in the library space. That said, there’s nothing about this platform that is library-specific. It can actually be used anywhere, anytime, for anything. The platform itself, all communication occurs basically via HTTP. It’s microservice-based. It’s language-agnostic. And it is really the core of what we’re building. However of course, a platform on its own is not very useful. And at least for right now, libraries are overall expecting to get to a point in terms of features, functionality, apps, and services that are being built. So FOLIO can actually take over the enterprise-wide day-to-day operations of what it takes to actually run a library.

CHARLES: And these are libraries like university libraries, the Library of Congress, the library at Alexandria. I mean really, when you think of library, like library [3:00 inaudible].

HARRY: Yes. However, we decided to focus on a particular market, at least initially or I guess a subset of the library market. And so, that subset we’ve actually chosen to focus on is the academic library market. And so, really mainly colleges and universities all around the world. That said, there is no reason why others can’t use this software. And it is all open source. So, if any changes are ever needed, modifications or additional applications are needed to support those additional markets, that can certainly happen at any time.

CHARLES: Historically, it’s a very complex problem, right? There is a lot that goes on at these libraries. But historically, the software that’s driving it has not been open source.

HARRY: That is correct. So, it’s sort of an interesting history. And I guess you’re leading into what I think was maybe your second question [Chuckles] which was: What are the circumstances or the thinking that lead to the creation of a project such as this? And really, libraries have been pretty much operating the same way, to be honest, for probably about the last 40 years. And I’m sure we either all know or have heard, most libraries are facing shrinking budgets. They’re really challenged in terms of space and storage requirements. And just in general, users have changed dramatically in the last 40 years, the last 20 years, maybe even the last 10 years. Most people don’t really ever expect to walk into a library and actually conduct research anymore. They expect that to happen elsewhere.

And so, in many ways, they’re really facing what amounts to Google and others, because that’s where people expect to go. The vendors that typically created the systems and software that supported these libraries, the day-to-day operations over the years, many of them have consolidated. And there are just actually very few options left. These are really old, monolithic systems. They were built initially with the best intent. And for the first couple of years, many features and functionalities were added. But over time, these systems grew to be so large. There really was never any one person anymore that fully understood it. They find themselves in situations where if they add a little feature here or modify something there, it breaks something somewhere else within the system. And so really, they’ve gotten to a point where libraries have generated lists of features and functionality that they need that are frankly years long. And the vendors just can’t deliver any of it. They just don’t have the ability anymore. The systems are too old.

In addition, really they’re sort of building these walled gardens where they really try to take over all the day-to-day operations of the library but are actually starting to try and expand out in other areas of the university as well. And as they do this, they really tend to lock the system down. They’re not really open to integration with other systems or other vendors. And they really see it as they are the one company you should go to that can completely manage and operate everything that goes on in your library. And when we talk about innovation in these systems, really they’ve been operating the same way, as I mentioned earlier, for the last 40 years. Really, the only major, major innovations is there’s maybe one company now that’s offering these services on the cloud. One size fits all. And the real issue there is, all of these libraries we talked to, all of them see themselves as being unique in some certain and specific way or sometimes multiple ways. All of them believe they’re bringing something special to the world in terms of knowledge, research, understanding and learning. And they tend to cater or specialize often to the institution they’re a part of.

And so for example, if a library belongs to a medical school, of course their collections are tailored that way. A lot of their workflows and operations tailor to students that conduct research in that field. And oftentimes, even to a hospital that may be associated as well. And this will oftentimes be very different from what might exist for example in an engineering library. And so, for most of them, they look around at what’s available to them. Not only has nothing changed, not only has there been no innovation, but on top of it, they’re forced to choose essentially a single system. And that’s not really getting them what they want or where they want to be.

So I, as well as some others, spent quite a bit of time looking around at the market and trying to assess and understand all of this. And one of the things we felt was, as we look at all of this, really we’re living in a world, these libraries are living in a world of closed systems, lack of transparency, lack of change, lack of innovation. How do we change that? How do we spark that innovation? And it seemed like what we really need is some sort of an ecosystem, a sustainable ecosystem or really, openness and transparency. And it seems like the only way to get that really is open source. And in fact, we actually conducted a survey and out of that survey, 100% of the libraries we spoke to really believe in open source. And when you think about it…

ROBERT: Whoa.

HARRY: Open source really in many ways aligns itself really nicely with the mission of the library, right? The library is there to not only promote learning but to make sure information and knowledge that normally you may not have access to is accessible to everyone. They’re really leveling the playing field. And that really is a really nice analogy for what open source is doing in the marketplace as well. And so, this seemed like really, and at least, an initial ideal path to head down. And so, we did.

CHARLES: Yeah. And so, you did. And I’m curious to explore more about that decisions. Because – now this is a little bit of a dated quote – but Steve Balmer, when he was the head of Microsoft, called open source communistic and un-American, then how do you reconcile that? Because obviously you represent a business that ultimately needs to be profitable and is engaging in this in order to make a profit. And so, where does the balance lie and how do you reconcile that? And obviously you all perceive this as a strong business move. And so, yeah, how do you balance those two concerns?

HARRY: I think from our perspective, we looked at it as if a single vendor or maybe a group of two or three vendors end up locking up the entire market with systems that operate the entire library that are not open and they’re not willing to integrate with other systems and services that exist out there, in essence that’s an attack on what is the basis of our business as a company. We provide services and we provide content that libraries use and ingest and make available to their users. And essentially, it looks like they’re trying to lock us out. And how does that really help in terms of creating an open and fair marketplace where people get to make choice? It doesn’t. And so, what can we do to disrupt that? And building a system that allows everyone to play at least puts us on a level playing field where if an organization or a library chooses to adopt it, we’re now back in a very competitive situation where really, the vendor or the organization or the individual that provides the services that best fit that library’s needs wins. And that’s what we really want to happen.

And so, that’s in essence how we win. We believe we offer better services than most others in the industry, if not everyone else in the industry. We think there’s a sizable percentage of the market that truly believes that. And we just need to make sure that the mechanisms or the systems are in place that allow us to compete in that manner. And in the end, if what we end up with is a platform that allows 3, 5, 10, or 20 companies to actually compete in a reasonable manner fairly, really it’s the customer in the end that wins. It’s these libraries and it’s the users and everyone else conducting research.

ROBERT: So, I’m still kind of reeling from 100% of libraries said that they would like to have an open source platform. How many did you survey?

HARRY: So to be truthful, it wasn’t a large number.

ROBERT: That’s still insane to me. [Laughs]

HARRY: Right. We focused on, however, surveying different segments of I guess really representation within the library. So, the people that do the work, the middle managers, and then really, the folks at the director level that are really responsible for running and organizing a library.

ROBERT: The ones that will experience that pain of being locked in, right?

HARRY: Right, right. And trying to get decision-makers at many different levels. And we tried to also cover both very small libraries to very large, enormous libraries as well. And all of them saw a benefit. One of the pieces where things sort of maybe went in the other direction as far as the statistics are concerned, if you ask them though “How many are willing to adopt open source?” the numbers aren’t quite the same. In fact, they’re rather dramatic. And so, at that point it’s roughly about 33% said they’d be willing to adopt.

CHARLES: So, why is that?

HARRY: So, we asked. And interesting question. And what most of them came back and stated was, “Well, we love the idea of open source. We fully support it. We’re willing to do what we can to help it and make sure this happens. However, we ourselves don’t believe we’ve got the staffing, the resourcing, or the knowledge to host this ourselves.” And so, this leads to another really interesting thought or idea as far as open source is concerned, is so this really implies that there really needs to be sort of an ecosystem of organizations that are providing these types of services. And to be honest, the faster we can make that happen, the better off the market is.

Libraries are now getting to choose vendors that they get to get their services from, which is rather interesting. Because for the first time, not only do they get to choose the vendor but if they’re not happy with the vendor, they should be able to switch vendors but keep the software and the data the same. Today, in the library market, if a library chooses to switch vendors, that means essentially they’re completely starting over in their library. They completely have to migrate to a fully new system which means enormous amounts of training, enormous amounts of data transfer, and all the pain that goes along with it. I had a librarian tell me once, “The next time we migrate to a fully new system, I either want to die or retire.” I just want [14:30 inaudible].

ROBERT: Man, that sounds painful.

HARRY: That’s how painful it was.

CHARLES: Yeah, wow. Because the complexity intrinsic to these systems, it does, it boggles the mind sometimes. Just even the little slices of the ecosystem in which we’re operating, there’s just a lot at play there.

ROBERT: Yeah. Like trying to work with other vendors and be agnostic so anybody can adopt these things that we’re building. And since we had that vendor lock-in, it’s hard for you to adapt the two systems, because they were built in complete silos. So, trying to merge that is an interesting challenge.

HARRY: And I think everything I’m saying here, I’m talking about it from the library perspective. But if you look at other industries, I don’t think it’s really any different. If you look at any of the enterprise-wide management systems that are used in corporate organizations today, most of these corporate entities will stick with the system they chose for a very long time. Because it’s incredibly painful, it’s disruptive, and it’s expensive to switch from one system to another. And so, the idea of you’re not happy with a vendor and hey, I can go to somewhere else and maybe keep the system I have in place is really kind of interesting. And even better, if the vendor’s not able to provide some of those features that I need but for the most part I like the system, wouldn’t it be great if I can hire someone to do that work and to have those pieces built for me? And those are some of the things that open source offers.

CHARLES: Right, right. So now, I understand that for example to kind of put a concrete bow on this, [Chuckles] to move away from abstraction of what it means and provide an example, so we have this open source platform, this FOLIO platform. Which if I’m a library, I could in-house, I could either use it on premises on my own servers or I could run them on AWS or I could run them on Google Cloud – there are all these different deployment options and some libraries are doing that, but that’s something that they might not want to do. So, I understand that EBSCO is actually going to be for example one of the services that y’all are going to be offering around FOLIO, is actually hosting the platform so that the overhead of managing all of the servers and provisioning accounts and doing all that stuff is going to be taken care of for you. So, I can just sign up.

HARRY: Yes. So, that really fed into the results of the survey. For those libraries or organizations that felt they couldn’t do it themselves, where would they go? And who could provide those services? So, we’re absolutely going into the business of providing these services for libraries that choose to. But at the same time, we’re really strongly encouraging other vendors and organizations to provide these services as well. Because for instance, you may represent a series of libraries in let’s say Hungary. You may have a vendor there you enjoy working with in the past. It’s provided great services for you. There really ought to be no reason why you should not choose that vendor to provide those services for you.

And again, it’s an open system. There’s nothing there that’s excluding me and the organization I work for to provide additional services, to provide content or what have you. It’s an open system. And so, we should strongly encourage that. And the reality is, if we’re going to have a disruption in the market, it seems we can either have one organization or one company trying to usher this disruption along. But what if we could get 10? Or what if we could get 20? Or more companies out there ushering this disruption along simultaneously worldwide. It feels like we’ve got a lot more of a disruption happening in that case. And so, that’s what we’re strongly encouraging.

CHARLES: Right. But at the same time, I can see it from if I were considering making a play like this, one of the things that would worry me is, “Okay, so we’re going to disrupt the market by allowing a large tent where lots of vendors could compete.” But then, I immediately experience fear of, “Well then, how do I differentiate myself?” Because ultimately I want to be competitive. How do I make it so that I’m not a commodity in this new market?

HARRY: So really, I think that’s key for any vendor that chooses to compete in a market like this. Do you believe as an organization you have not only what’s needed to compete but those key differentiators that at least a certain segment of the market would be interested in you and the services you offer? We believe we do. Another company that just recently announced that they’re going to be supporting FOLIO and providing services around it is a company called ByWater Solutions. They’ve actually been in another segment of the library market for many years providing services to libraries as well. Longstanding, actually, with open source codebases. And so, this very much appeals to them. They believe…

ROBERT: Oh, interesting.

HARRY: They have a niche that they can provide and they are going to be doing that. And we strongly encourage it. What’s again great about it is if they set up a library with FOLIO, they’re not building the walled garden. They’re building or providing the open platform that we can connect our services to. So in many ways, yeah there are some areas we’re going to compete. But there are actually many areas that we’re also going to be complementary. And I think that’s what’s really, really interesting to us.

CHARLES: So, it sounds like you’re also counting on just by having the ecosystem in place and having this sea as it were filling the ocean to enable trade, one of the bets too is that you’re going to open lines of business that weren’t even possible before.

HARRY: Correct. So, another way to look at it – we’ve got our iPhones or Android devices. Apple built a platform is really what that phone is. When it was released, you could make voice calls. You could do some simple text messaging, some basic email, and I’m sure there are a couple other of things in there that I’ve forgotten. I do not believe that Apple had any idea that they’d actually be able to create a marketplace that had hundreds of thousands of people and vendors providing features and functionality for that platform. I am pretty sure no one at Apple had ever imagined the guitar tuner would be released. I don’t know, a compass app, flashlight apps, whatever. You name it. And not only that, as a user of that platform, you’re not happy with the standard email app? Well you know what? I can get a different one. In fact, I’ve got a choice of many and I can find the one that suits me best. And that’s fine. It’s an open marketplace.

And so, with FOLIO today, we’re in early stages. We’re building out that platform. We’re building out some of the basic functionality for that library that they need to operate as a library. But once this gets released, it’s at that point when we believe the more interesting things are going to happen where we build a cataloging app for FOLIO. Well, we know already that there’s other organizations that are starting to look at and think about, “You know what? We’ve got a whole other way or a whole other interest in terms of how we’d like to support those workflows on the FOLIO platform.” Or even better, librarians starting to think about, “Hey, if I’ve got this open platform just like Apple does, this means I now have the option to build features and functionality that take me where I want to be five years from now, 10 years from now. And I’ve never had that ability on the existing systems that we use today.” And so, one of the other I think advantages or benefits that something like FOLIO or a platform like this brings to the market is the ability to create that marketplace very much like Apple has done and Google has done with Android as well.

ROBERT: So, we’re pretty far in, but you mentioned FOLIO a couple of times. Do we want to unpack what FOLIO actually means?

HARRY: Yes. FOLIO actually stands for the Future Of Libraries Is Open.

ROBERT: Right there in the name. I love it.

HARRY: Absolutely.

CHARLES: So, we’ve talked about this platform. We’ve talked about this marketplace. We’ve talked about the business incentive of why you would want to do this, why it makes a lot of sense. Clearly, this takes an enormous investment. So, we think, I think, a lot of people think of open source as a bunch of wild developers running around.

ROBERT: Pushing commits wherever they want.

CHARLES: Pushing out code and doing stuff. And then it kind of organically grows into something that someone then picks up.

ROBERT: And then you burn out.

CHARLES: Yeah. [Chuckles] But that’s I think a lot of people’s experience with open source. But an initiative like this takes a staggering investment both in terms of capital resources but also in terms of will, in terms of management, and putting all these enormous forces in motion. There’s developing the software, developing the awareness, and I think right now there are hundreds if not thousands of people working on this right now. How do you even go from zero to 6,000 like that? And I’m not talking about people. I’m talking about velocity. [Laughs]

HARRY: Right. Early on, when we were conducting research, market research, one of the things we did, we spent some time looking at what we believed were successful open source projects. And I think what was interesting was in many cases it took a single individual or a company to actually create what amounts to that first piece, that first core building block that others could start to expand upon. And very often, they literally just created it themselves, made it available out there as open source, and basically told the world, “Here. Have at it. Have fun. Do with this whatever you wish.” So, we actually thought we’d like to do that. However, building a system on this scale is not that easy. Understanding the operations of a library day-to-day is not that simple. We need help.

And so, what we decided early on was: could we kick off and start this project while at the same time [25:42 inaudible] that community as early as possible? To get people excited, interested, and to get this project in a place where we’re not the only contributors, where there are many others contributing as well. And when I say ‘contribute’ I don’t necessarily mean software developers. But that is certainly one aspect of it. But one of the key pieces of building software is gaining access to subject matter experts as well. And it’s absolutely key and critical. And so, our goal of course was to build this community, have that community start to provide that in-depth knowledge, those subject matter experts that we need so we can determine what it is we need to build, how we need to build it, and really go from there. And by including those people as early as possible, I think one of the things we find that happens with this project which is really sort of incredible is the excitement that starts to build. The word of mouth advertising, marketing, as librarians, libraries, vendors and individuals start to talk to others and really spread the word about this project. In many ways, it starts to compound or snowball and build on itself. But that was really challenging.

And it was really actually kind of slow going in the beginning. Because we started with nothing. And one of the issues you face is, “Well, you want me to contribute my time to this project, yet I see nothing.” Right now it’s just a dream. And so, one of those early, early issues was, “Can we build a team small enough, focused enough, where we can start to build some of the basic, basic, basic core pieces, to really prove to the world that this project is real? This project is actually moving forward and this project is actually delivering.” And now that we’re in a state where people can actually see working software, the excitement is just starting to expand and compound rapidly. And we see it everywhere.

CHARLES: So, do you find libraries or people in the target market, there’s that key point where they start to feel empowered? It’s real and then the thing that I think that you’re going for is to have the realization dawn that not only is it real, I can put my hands on the wheel and I could control my destiny. And I can contribute now because there’s this critical mass.

ROBERT: You have the power to make change, which never existed in the library world before.

HARRY: Or at least, not in this specific area. Because to be truthful, I think libraries as a whole believe they’re making change around the world all the time. But it’s really related to content. But this is actually making changes in the actual operations of the library. And they are actually empowered to get involved, to contribute, and to help us get this done. And it seems to really resonate with folks. Because it’s something they haven’t been able to do previously. And it seems genuinely exciting. And we announced this really, well the market learned that this was happening I’d say a little over two years ago. Maybe more like two and a half years ago. And it was sort of a gentle drip in terms of a roll out. People started to learn because we started talking to them. There was no real active marketing going on. But of course, those people started to talk to other people. And so, it happened. And when we were able to provide those first demonstrations, no matter how rudimentary it was, that’s when things seemed to really kick into a much higher gear where people started talking to each other. Librarians started talking to each other and say, “Hey, this is real. This is exciting.”

ROBERT: It’s not vaporware.

HARRY: And this is happening. Right. It’s not vaporware. And we need to get involved. And so, they have.

CHARLES: Yeah. And the energy and involvement just in the course of the time that we’ve been a part of the project is apparent. Every kind of gathering is larger and the diversity of topics that are discussed is increasing. And yeah, the conversations have burned from “What can we do with it?” to the last time the project got together as a group, it had much more of a conference-y feel. And the topics being discussed were like, “How do we actually deploy this to our real systems?” Which has been fantastic to see. And so, just to actually feel the traction is just, it’s so gratifying. So, I guess one of the questions that is on my mind is – so you mentioned that you had been at this for about two and a half years. What is in your mind the most pleasant, unexpected outcome of this project that you didn’t foresee two and a half years ago that you’re experiencing now?

HARRY: So, I think one of the one’s that’s surprising is I’ve never actually personally been involved in an open source project before. And I think one of the fears constantly working for organizations that really have been closed source – in fact, I’ve been that my adult working life – and you sort of walk into this with some [trepidation]. Because oh my gosh, everything I’m doing, everything I say, everything that gets documented is going to be out in the open for everyone to see? Including competition and everyone else? And I have to say, one of the most interesting things, or one of my favorite pieces here, is: it is so freeing. It’s a release. It’s actually amazing to not care about what your competition or anyone is doing or thinking. And it’s even more amazing whenever you’ve got a question and someone’s out there asking you for access to documentation, you can simply point them to the website, to the URL and say, “It’s there. It’s all there. Anything you want is there. Go take a look.” I think that’s pretty amazing.

The other one of course are the relationships between many, many different people who I’ve just never really been – or I never would have had the chance to work with before. And really hearing all these different perspectives and points of view as far as what people think are right, correct, or what we should be doing – it’s great to see. And it’s great to see this wildfire word of mouth message that seems to be moving everywhere. We’re hearing back from people not just in North America, not just from the EU, but from the Middle East, from South and Central America. There’s really just people interested everywhere. And it’s amazing to me, because I don’t think I spoke to anyone over there. So, it’s happening. And that’s just an exciting thing to see.

CHARLES: Yeah, yeah.

ROBERT: It’s really cool that open source can connect you with the rest of the world like that. It’s just so powerful.

HARRY: It does. And it’s an amazing thing.

ROBERT: And the amount of collaboration that happens, I’ve never experienced it in any other way. It’s really cool. [Chuckles] I don’t know how else to put it. It’s just, it’s almost mind-blowing that you are able to across timezones, across the world, collaborate with somebody on something that you both feel passionate about and you’re pushing it forward in an open manner.

HARRY: Right. And it’s also amazing when you have these meetings and there’s people you’ve been collaborating with for months if not a year or more. And getting to meet them face-to-face for the first time. That’s really a pretty amazing experience.

ROBERT: Yeah. And it’s pretty awesome. At our last gathering that we had at WolfCon, I had the absolute pleasure of chatting up a bunch of different librarians. And hearing their experiences and what they’re looking for out of an experience, it’s just really cool to be able to talk to those people and see how they work and help build this into the platform that they’re wanting to use.

HARRY: Right, right.

CHARLES: Yeah. I would say on the whole, there’s been a lot of those wonderful, unexpected outcomes. Were there any that presented a particular challenge or wasn’t quite so much a walk along the path of roses?

HARRY: So, you know I think the biggest one is – I mentioned earlier we embarked on this project a little differently versus what we saw as normally successful open source projects, right? We did not have that core, beautiful, shiny object to unleash onto the world and let them know, “Hey, have at it.” And so, it wasn’t so hard in terms of getting interest. But what’s been hard is the amount of interest has generated enormous numbers of organizations that are interested in contributing to the project. Which also implies then that now, not only are they coming to us asking us, “Hey, how can we help? What can we do here?” but then there’s a certain aspect, because this is a first version of, “How do you manage the building and construction of that very first version of this software project when the reality of the matter is, you’re not really responsible for most everyone working on the project?” And how do you get everyone aligned and organized? How do you get everyone onto that same path along with those same milestones that we’ve all agreed on? And even worse, how do you get agreement on those milestones so we can all walk that same path and deliver that first version?

And so, I get asked sometimes by folks that are involved in other open source projects, “How do you handle this situation? Or how do you manage all the work that goes on?” And when we tell them, it’s kind of surprising because it’s not what they’re used to seeing. And a lot of it is because of the way we started, the interest that was generated early on, and the fact that we did not have an initial version. And I don’t want that to sound like, “Oh, this is a huge problem,” or, “If I were to do it again, I would not do it this way again.” I in fact would do it this way again. I think there are a lot of benefits and it’s been a great and interesting way to go. It’s just the management aspects of it are definitely challenging. And I think more than maybe we had initially anticipated. Going into this next time, though, I definitely know what I’m facing and I’ll be prepared.

CHARLES: Yeah. So with that in mind, given that you’ve been through this, do you have any advice to offer someone who might be considering embarking on a similar journey? And undertaking a similar Herculean task.

HARRY: Well, I think you’ll find it’s harder than you think. And be sure to plan for that. But I guess at the same time, I think my biggest advice or my best advice would be: you need to keep an open mind. And when I mean an open mind, you need to be open to other thoughts and ideas. And I think you need to put yourself in the perspective of what if you were one of these other people that are working on the project or trying to contribute to this project? What are the things that you’re doing or rather the things that you’re doing now, the way you’re acting, the way you’re reacting, how does that look to others on the project? Because you’re not the only one contributing. You’re not the only organization contributing. And are the things you’re doing reflecting badly in terms of others’ perception or optics as to what this looks like as an open source project? And I think for me and others, there was a huge learning experience. Because your first thought is, “I’m going to tackle this like any other software project,” and it’s not. It’s not like that at all.

CHARLES: I think that’s…

ROBERT: That makes sense.

CHARLES: Yes, that makes sense. That’s excellent. That’s excellent advice. And I think that’s one of the things that makes open source so powerful, is because there’s that aspect just baked into it from the get go, you have to be mindful of a bunch of different perspectives. And that ultimately results in a solution that’s going to be workable for a bunch of different perspectives, that’s going to be flexible to accommodate for all the different use cases that all the different participants in the community might bring to the table.

HARRY: And you have to be very mindful of how your actions are perceived. Because normally, your actions are perceived by the company you work for, what tends to have a particular culture. But on an open source project, you’re actually dealing with many different cultures.

CHARLES: Yes.

HARRY: And so, that’s a tight line that you have to walk.

CHARLES: That was a powerful note to end on. Thank you everybody for listening. We are The Frontside and we build software that you can stake your future on. If you want to get in touch with us, continue the conversation, you can reach out to us on Twitter at @TheFrontside or drop us an email at [email protected]. Thank you so much Harry, for being on the show today and talking to us about FOLIO.

HARRY: And thank you very much for having me. This has been great.

CHARLES: And if you want to, if there’s something that you want to learn about or a topic that you want to discuss, please, please let us know. We always are open for your feedback, especially when it comes for things that you would want to hear. And if you want to get involved or learn more about the FOLIO platform, you can just head on over to FOLIO.org. There are resources for librarians, developers, and anyone who is curious about becoming a community member.

Thanks as always to Mandy, our producer. And we’ve got a really great podcast coming up on the 14th of June. We’re going to have Michael Jackson on the podcast to talk about separations of concerns in React. So again, thank you Robert. Thank you Harry. And we’ll see you all next time.

In this episode of The Frontside Podcast, panelists Charles Lowell, Rob DeLuca, and Sam Keathley, discuss how much the distinction between frontend, backend, and fullstack developers matter in both personal and professional senses.

The differences in mindset between these categories are also discussed, for example, how does a fullstack developer solve a problem vs how a backend or frontend developer? And also, how clear (or fuzzy) is the line that separates them? What are the skills a frontend or backend developer needs to consider themselves fully fullstack? And finally, is there any sort of tribal separation between the factions?

Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at [email protected] or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

TRANSCRIPT

CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 101. My name is Charles Lowell. I’m a developer here at The Frontside and I’ll be hosting today’s episode. Today we’re going to be talking about the different developer profiles that are out there. You might have heard mention of them on Stack Overflow, on job boards, on the Twitterverse. Things like frontend, backend, full stack, half stack, short stack. [Chuckles] Things like that. With me to talk about these are Rob and Sam. Rob is our director of open source here at Frontside and Sam is a software engineer here at Frontside. So, hey y’all.

SAM: Hey.

ROB: Hey yo.

CHARLES: Alright. So, before we get into the meat of the topic, there are a few announcements that we wanted to make. First and foremost, this is some really exciting news. This week, Taras Mankovski officially joined the team at The Frontside. And we are really, really excited about that. [Cheers]

ROB: That’s exciting.

CHARLES: Yeah. It’s super exciting. Not only is Taras an exceptional engineer, he’s got amazing code skills. He’s extremely empathetic and a great person to work with. He’s great working with clients and he’s also fantastic at really working with developers who are climbing that ladder and helping them level up. So, he’s been involved in mentorship literally since I’ve known him. I think that was the first time that we ever came into contact with him was through his mentorship work in the Ember community. And we’ve been collaborating with him for years on several open source projects. And so, we just are so excited and know that he’s going to come on and do some amazing things by helping us be better developers, helping us be better community emissaries. And so, lots of good stuff coming out of that.

ROB: Absolutely.

CHARLES: Yeah, yeah. No, that’s really exciting. So, definitely wanted to throw that out there.

ROB: Too bad he didn’t join a little bit earlier. We would have had a good time with him on this podcast.

CHARLES: I know. Well he’s actually, I think he’s been on the podcast twice.

ROB: [Laughs] That’s true.

CHARLES: But yeah, there’s definitely a couple of topics where his input would have been absolutely critical. I think it would have been great to have him along when we were trying to run our own apprenticeship programs. Those would have worked out I think a lot better. Well, not to say that the outcomes haven’t been stellar in some cases. But I think having his expertise would have made it a lot smoother. That said, before we jump in then, just wanted to let everyone know that as always, if you want to work with us you can get to us at [email protected] or send a shout-out on Twitter @TheFrontside. Okay. Y’all, let’s jump into it. Like what is even a stack?

ROB: [Laughs] So, do you want to kind of set up where this came from, Charles? I think it came from you and I going back and forth on Twitter. And I was like, “You know what? We need to talk about this on the podcast.”

CHARLES: Yeah. I think I was actually on vacation.

ROB: [Laughs] That’s right. You were trying to ski.

CHARLES: [Laughs] I was on the ski lift. And I saw you tweeting and I was like, “No, no, no. I got to respond to that.” Probably because there was maybe a little bit of disagreement but also because I just needed something to do. Looking out the majestic scenery of the Rocky Mountains wasn’t enough. So yeah, what’s the backstory there?

ROB: So, I can’t remember what I was actually tweeting about. But I kind of feel like there is a distinction between a frontend developer, a backend developer, and at this point I don’t know if a full stack developer truly exists. I mean, it does. But it’s used more often than it really implies what they’re doing. Usually when you hear of a full stack developer, it’s like, “Man, I can sling some code on the backend and I can do a little bit of architecture stuff on the frontend. But CSS, keep that away from me.” And in my opinion, if you’re a full stack developer, you need to sling CSS, too.

CHARLES: Really?

ROB: Yeah.

CHARLES: No, no. I certainly agree. Because I was going to ask, is it fair to say that full stack developer is code for like, startup developer?

ROB: Yeah. That’s a good – like a utilitarian, like a jack of all trades but not a master of any?

CHARLES: Right, exactly.

ROB: I can take that. So, I guess the way we can start to dig into this one is like, how much distinction is there between a frontend, a backend, and a full stack developer? And does that matter in a professional sense?

CHARLES: Right. And so, I think my take was that the skillsets that you need in both places are actually much more convergent than you think, than people might think. In other words, the skills that you utilize on the backend actually translate very well to the frontend. I think my stance is that what makes a frontend developer and a backend developer is more the problem sets that you gravitate towards naturally, the things that interest you. I actually was a backend developer. And now I consider myself to be primarily a frontend developer. But the skills that I had developed writing backend systems in Java translated shockingly well into frontend development with JavaScript. But it was working on the portion of the program that interfaced with the human was, that was the thing that fascinated me. And so, it’s what I gravitated towards. And so, I guess in my [6:15 inaudible] or the way that I have been thinking about it is that what makes a frontend developer and a backend developer is more what gravitational pulls you respond to, rather than one particular skillset.

But I know that you’ve got a perhaps more refined take on that, or a different take.

ROB: Yeah. Before I do, I want to know what Sam’s thoughts are on this. This would be a good one.

SAM: Where I come from in the understanding of frontend, backend, and full stack is I – background on me: I did a bootcamp before working here. So, I did a development bootcamp where they were really excited to tell you at the end of it that, “Oh, you’re a full stack developer because we’ve introduced you to everything. Like, touched on every sort of little topic. You’re full stack. Tell everyone you’re full stack.” And it’s like, “Well, you’re not really a specialist in any of the sense.” So, what makes a difference to me, I’m going to specifically talk about full stack, but it’s like before you can say you’re full stack, having knowledge of frontend and at backend, you need to have expertise in at least one of them first, or understanding of that mindset first. Like if I say that I like frontend work more then I need to understand frontend work more before I can say that I understand backend work, you know?

ROB: Yeah.

CHARLES: So, do you feel like the bootcamp was doing you a disservice? Or do you think they got…

SAM: I don’t think they did a disservice at all. So, they did a really good job. So, bootcamps are really for introducing you to everything. And then whatever you take from that is your own. So, they introduce you to all the little things like database working and then JavaScript, Ruby, whatever it is. And then it’s your job to figure out in those introductions, what you resonate most with. So, I think they did a really good job in that. I think that they shouldn't tell you what you are, like tell you that because they touched on whatever it was, that you’re full stack.

CHARLES: Right.

SAM: So, I don’t think they did a disservice at all. I learned a lot. But I wouldn't say I’m full stack at all.

CHARLES: So, if you feel as though you’re not full stack, what do you feel that you are?

SAM: Definitely frontend.

CHARLES: Definitely frontend.

SAM: I gravitate more towards frontend.

ROB: Why would you feel that way? Is it because you’re more pulled towards the UI of things? Or is that where you feel like you’ve gotten most of your experience now?

SAM: Actually a little bit of both. I tend to like the UI of things a little bit more. It’s interesting. Whenever I was going to the bootcamp, I thought I was going to be more backend because I thought I really like working with the behind the scenes sort of. You don’t see this work but you know it’s there. But I definitely like the UI of frontend a lot more. Just personal.

ROB: I see that.

SAM: And it’s where my skillset is, because this is all frontend work that I’m doing here at The Frontside. So, it’s what I know most at this point.

CHARLES: Yeah. I’m curious too. Isn’t it true that there’s also a conception in the wider tech world that frontend is limited to CSS and HTML?

ROB: Ooh. Yeah, that could be.

CHARLES: Like when you see job posting for frontend developers, typically it’s like, we want someone…

ROB: Yeah. It’s kind of morphed from – JavaScript developer is now a single-page app developer instead of frontend. Yeah. Yeah, I see what you're saying. It’s now, it could be considered as HTML and CSS and not JavaScript anymore. [Chuckles]

CHARLES: Which is so bizarre to me.

SAM: [9:42 inaudible] a lot of places when a frontend developer who is also a UX designer. Someone who has the knowledge of designing things from the ground up and then only working in things that look good, rather than logic.

ROB: Yeah. This can be probably an entirely other topic. But that’s like the frontend of the frontend and the backend of the frontend, is like [10:03 inaudible] call it. Because there are [10:06 inaudible] developers. And single-page apps have gotten so complex these days, between your data layer and your testing and managing state on the frontend. There is a backend, an architecture, that you need to consider when you’re developing a single-page app. And I’ve worked on teams where there are developers that are working on the frontend but they still don’t like CSS. They don’t do CSS things and they don’t consider layout or any design. They just take the ticket and they get the data going. Get the data from the server, request it, display it on the page. And then another person would come through and style it up to the spec or the mock. But yeah, that’s interesting.

So for my take on this, and where this actually really came from, is we were going through some hiring. And we were trying to figure out how we can place somebody or hire someone that can be effective in the role that we immediately needed. And all of our immediate needs were in frontend-specific things. And we can actually talk about if they’re frontend-frontend or frontend of the backend. But where this kind of came from or was born was: if we’re hiring somebody that needs to fill a frontend role and they’re primarily a backend developer, there are gotchas and things you have to know to be an effective frontend developer. Like quirky browser things that happen or like how to set up a Babel transpilation setup. And what are the gotchas here? Kind of the history of the frontend web, because there’s a lot of things that are there that can cause a lot of headache if you don’t know the backstory.

And I know from your perspective Charles, you think – and this is isn’t wrong – but you think that if somebody has a really talented backend developer, it’s really just concepts that you can apply to the frontend. And I agree with that.

CHARLES: Right. But you have to want to do it. [Laughs]

ROB: Yes. That is also a key.

CHARLES: You have to be gripped by the problem set of the frontend. You want it to inspire you to leverage those solutions.

ROB: Yeah. So, would you say there’s a different mindset between a frontend, backend developer, and full stack? Does a full stack developer solve a problem that’s different from how a backend developer or a frontend developer would?

CHARLES: That’s a subtle question and probably one that might offend people, my answer to it. So, I’ll go ahead and answer it. [Chuckles]

ROB: Hashtag [12:23 inaudible]

CHARLES: Actually, maybe not. Just in my experience historically – I want to underline the fact historically – I think that it is people who gravitate towards the outside-in mindset, in other words the very first thing they’re thinking of is, “How is this going to feel to a person who’s going to use this?” If that’s your first question that you ask, then you probably are going to gravitate towards the frontend. Then in terms of the backend, I’d say historically – and like I said, I want to underline that, and I’ll get to that later – I think it’s people who are more drawn to: I want to attack the most complex problem that exists. Like distributing state over 10,000 nodes, managing huge deployment infrastructures that drive these massive websites that happen at this mind-boggling scale. And so, there you really are thinking computer to computer and, “What’s the ideal interface for doing that?” And then on the frontend you’re thinking more like human to computer, because that’s where the interface lies. Now the reason I say…

ROB: I feel so let down. Where’s the controversy?

CHARLES: Well, okay. Well, because I think that basically – I think the controversy is saying like people who are more naturally empathetic. I don’t know. That would be the controversy thing. But I want to say historical.

ROB: Yeah. I can see that. [Laughs]

CHARLES: So, I want to say historical too, because I feel like one of the things that’s been magical about the last two decades of software development is the dawning realization that no software you write exists in a vacuum and that it’s all interconnected. And so, I think that I for example feel very strongly while I try to think about the user experience first. And the developer, I’m also thinking about developer experience first. The way that you want a system to feel is going to inform the design of the UX workflow and that’s going to affect the architecture of your frontend. And if you’re interfacing with it through different media, like websites, phone, I don’t know, even text messages, Slack, what have you – that’s going to inform then the next level of how your APIs are shaped, your public-facing APIs. Which then inform the structure of your internal deployments.

So, recognizing that the decisions you make in one end of the stack and ripple through completely and that they’re not what we hold as dear these concepts of separation of concerns and complete and total isolation of layers. That really is false. But what it does is it enables us to change the individual layers to more – ironically the reason you want to have separation of the layers is so that it more easily lets you change them provide a more integrated experience. So, I think that’s a long way of saying that I think frontend developers are more aware of what’s going on in the backend and that they might be drawn into the backend. And the same thing goes for backend developers, realizing that the decisions they make are affected by the frontend and affect the frontend. And so, I think there’s been a dawning more of a collective responsibility for design, for operations, for developer experience. And I think it’s great.

ROB: Yeah. And to [think back off] that. So, I was kind of wondering where the controversy was, because that’s kind of my exact answer, too. Where do you gravitate towards on? The difference of mindset is like, if you’ve got a problem and let’s say you’re a full stack developer, so whatever that manes, but if you’re given a task where you have to implement the frontend and the backend, where you gravitate towards first I would say is how you would attack solving a problem.

For me, I would immediately go to the frontend and see how a user would immediately interact with it and then work out that way. Mostly also because I like having a tight feedback loop. And the frontend provides that nicely. I can change something and immediately see the difference there. And in the backend you can spend a little bit of time, unless you’re TDD which you should be – you can spend a little bit of time piecing together things and figuring out the architecture. And then you’ll have something that you could show for. It’s just nice to see UI get thrown on the page. And it’s real and you click a button and something happens. That’s a really nice feeling. And that’s kind of where I gravitate towards. And if yeah, if I had to attack the problem, I’m going there first. I get the endorphins from it. [Chuckles]

CHARLES: Right. So, if we want to add controversy to the other side, because you got to always be controversial, right? So, we said the really blunt horrible oversimplification is that people who are more naturally empathetic gravitate towards the frontend. You could also say that from the other perspective, people who are more internally validated will gravitate to the backend. Because if you need to get those endorphins from working on the frontend, basically what you’re saying is, “I want to put it in front of people and get the feedback from those people and know whether it’s good or bad.” Whereas you could say, “Actually, I don’t need validation from other people. I’ve got this concept of this architecture that is going to be the ideal thing. I know it. I’ve got this vision and I’m going to chase it, regardless of what’s going on.” I think you can more readily do that on the backend because you’re not as open to the feedback of a whole bunch of different users. And like I said, I think those are gross oversimplifications.

ROB: Yeah. I agree. And so, as a devil’s advocate towards the backend developer that is less empathetic, I think actually some of the best backend developers I’ve ever worked with were the most empathetic people ever. Because they know that software is for humans. And humans are going to be consuming the API that they build. And they take that into consideration.

CHARLES: Absolutely. And I actually think that empathy pervades good software development just wherever you find it. Because yeah, someone’s going to be using your APIs whether it’s software as a service or it’s a library. If it’s software as a service, it’s got to be easy to work with. It’s got to be performant. It’s got to have a nice command line. And so, you have to be thinking at all times, “What is it like to use this software? What is it like to consume it? What is it like to link it into my library? What is it like to call it from a web client?” So yeah, I think you’re absolutely right. I think it’s actually one of the great virtues of great software developers.

SAM: Yeah. So, something that I’ve always kind fo had a question with, especially coming from that bootcamp setting: is there any sort of tribal separation between what you would consider a frontend or a backend developer or even full stack? Like, “I’m better because I understand data layers than I understand how a button fits on a page,” that sort of thing.

CHARLES: I would say absolutely yes. If you at the, just do a quick poll of the Twitterverse, it seems like people tend to hang out in little circles of similar interest. So, there’s definitely a bunch of people that I follow that are always tweeting about backend stuff.

ROB: Yeah. Twitter is ‘build your own echo chamber’.

CHARLES: Yeah. And there are people who I follow that are tweeting nothing but mostly frontend – when I say frontend, I mean frontend of the frontend. Well basically, from CSS down to nothing deeper than React components. And then there’s people who are talking primarily about the backend of the frontend. So yeah, I do think that people – there are clearly, there are different areas of the stack and I think that people do tribalize around them. So, the question is: Who are the border agents? Because always cross-border trade. Any time you have borders, there’s an exchange of ideas and information and things that happen at those layers. And actually, one of the things I’m really curious about is: How does that happen?

ROB: Yeah. You might have the best perspective on this because you did – you were using Java Swing back in the early 2000s building UI. And that’s like backend things. And then you had a lot of experience with Rails and you’ve moved into the JavaScript world. And the thing that I’ve noticed with frontend is, we’re applying a lot of concepts that existed on the backend. And we’re moving all that complexity into the frontend. And that’s kind of where that fuzzy line of, “Are you the frontend of the frontend? Are you the backend of the frontend?” comes from. And it’s interesting that – like this is going to be another podcast. We’ll end up talking about this – but we have – MVC lives on the frontend. Like in React, your C is a container component. The controller is a container component. The model is probably your Redux layer if you have it or if you’re using micro-states. And the view is your components, your view layer components that you're rendering down. So, these concepts are moving from the backend to the frontend. We’re just kind of renaming them and making them our own concept. But they’re there. So, how does that knowledge sharing happen? Is it really just a mass exodus of backend developers interested in frontend developers now?

CHARLES: I don’t know. I think it goes both ways. So, I can only speak to my own experience. And that was when I first started doing frontend development was back in 2003 I think. So almost 15 years ago. We were building a touchscreen interface for an electronics vendor in the UK. And it was just so much fun, because we were getting to build these interfaces that literally looked like nothing else. And you could touch them and you had support for rudimentary gestures and there was no keyboard. And basically the only interface was your fingers and like a price scanning gun. And everything, all the entire UI had to be developed out of that. And so, it was such a novel system and it was so fun to implement that I just gravitated towards it. I think the thing that was particularly compelling was it was very interactive UI. It was high-touch, literally. This is a clerk who’s sitting there using this thing as rapidly as they can to sell stuff and move people through the line. So, it was like a unique problem.

But the thing that was cool about it was I realized so many – we kind of already touched on this in this conversation – so many things that I had learned on the backend applied there. And there was in order to provide that experience, there had to be a pretty complex machine behind it. And that was fascinating, that machine. And so, we were able to apply a lot of the concepts. And so, in that time on the backend I’d just come off working off a backend that had basically an event bus – we would probably call them microservices now, although we didn’t call them that then – were coordinating based on all these events. And that translated over into the frontend really, really well. And I remember using a lot of the techniques for exception handling – doing it on the frontend and doing a lot of the multithreaded stuff that we were doing on the backend, trying to reconcile that with the frontend and really understanding. So, there were all these analogous concepts.

And it could be – so, there was an original exodus of backend development, for me personally. And so for me, it was like I felt like I moved onto the web pretty much exclusively in 2006. And it was a good – I would say 2013 maybe is when web UI development finally caught up with Java Swing. Like it was like, that whole time I was like, “I’m using the web because it’s an awesome deployment platform. And it’s got all this great stuff,” but man, the developer experience is not as good as like a stateful fat GUI was back then. And now, I would say it’s actually surpassed quite significantly. But now, I think there are a lot of people maybe who either – I think there’s a casting back of people who are in frontend development and casting back to the web.

So right now, my love affair with immutability and functional programming started by using a Clojure web framework which borrowed a lot of the ideas from Clojure. So, I guess there was an exodus there – people from Clojure wanting to develop apps, wanted to have their goodies. But then I found that and I was like, “Whoa, that’s awesome.” But then that really set the hook for me. And so now, I try and go back to the well, the backend well or the shared computational well, as much as I can. So, all of that stuff of basically discovering all this functional programming stuff, this highly formalized functional programming, all came from saying, “Wow. I got a taste of that. Let me get more.” So, it’s very much like trying to run through the village of the backend and ransack the stores and take as much as I can and bring it back, because I know that it’s good.

ROB: So earlier in the podcast, you said that you were a frontend developer. You described yourself as a frontend developer. And that’s funny, because I actually consider you a full stack developer. It’s because you can jump in on the backend and sling any kind of code as well as anybody could, and then you can also do the same thing on the frontend. So, the question I have here is: Do you think actually someone that truly is a full stack developer – and we can define that in a second – but do you think they’re at an advantage here, because they have all that experience? You can answer yes. But why? Why do you think they have an advantage?

CHARLES: I think they have an advantage in the same way that a person who’s bilingual has an advantage. So, if you are living in North America, it behooves you to speak Spanish because you are now open to an entire set of markets that were previously closed to you. Well, not entirely closed but like you can trade with Mexico and you can trade with South America. You can buy and sell goods. You have access to yeah, emerging technologies that might – something special might be happening in Mexico City, or in Medellín, Colombia, and you’re going to have first access to that. And so, if you don’t, if you’re not bilingual, then you’re going to have to go through an intermediary who is.

And so, there’s a premium: you get to be the middle man so to speak. Or you get to be, maybe that has kind of a negative connotation, but you get to be the broker of new ideas and new technologies. If you can, if you are fluent in backend so to speak, then you can go into backend-landia and you can talk with the developers there and see what kind of cool stuff they’re doing. And then you can take it across the border into frontend-land and sell it. And so, that’s – I think we’re very much first to the gun on – not first to the gun but we’re ahead of the pack in terms of functional programming. Because we’ve seen that. We’ve seen it proved out and we’ve now actually started to integrate it into your day-to-day routines. And we’re ahead of the pack on that, right? And so, I think that’s kind of a keystone analogy for me that I think really, really captures what is the advantage in being a full stack engineer.

ROB: So, well how do you define a full stack engineer or developer? What things do you have to possess to actually claim that title? In order to be a full stack developer I personally believe you have to know, you have to be comfortable with CSS. You can hate it. You can yell at it. But I think you have to be able to put together a layout if a designer gives you a comp in order to claim full stack. And in the same token, if you’re a full stack developer and you mainly came from the frontend, you should be able to implement backend features. I don’t actually have – so, I’m strong in the frontend, not so strong in the backend. What would be the analogous of CSS in the backend? Would it be like mocking your controller actions? [Chuckles]

CHARLES: I would say you should have a familiarity with HTTP and REST, would probably be the equivalent. Kind of like a foundational technology that just every single technology is oriented around it, or most. Regardless of the protocol you’re using – there are things like GraphQL which are not really RESTful, although it’s a blurry line there – but they’re still delivered over HTTP. And so, understanding things like CORS, understanding the things that are going to be universal to APIs.

ROB: I think a lot of people try to claim full stack. I try to claim it. And I know I’m not. I can put together a pretty crummy Rails API on my own for personal projects. But I’m not going to be the one that’s setting up indexes on a database to optimize a database or anything. I think that does come in time, but you have – borrowing from Brandon Haye’s talks about career development – if you’re a full stack developer, I think you end up having to be in the industry for a long time. Longer than what we consider a senior developer these days, I think. Because you could be a senior developer and be specialized. And we see that all the time, and that’s okay. But in order to amass that knowledge and experience, I think you have to be in the industry for a long time and done those things a couple of times to really know.

CHARLES: Yeah. I agree. So, can I add something there? To continue the analogy of being full stack is like being bilingual or multilingual. I go back to those analogies a lot because that’s what I – linguistics is what I studied in school. But when I was studying linguistics, one of the things that was going on there was they were kind of redefining what…

ROB: That makes so much more sense of your vocabulary. [Laughs]

CHARLES: What it means to be bilingual. There was kind of a reorientation of that definition that was going on while I was in school. And that was being bilingual doesn’t necessarily mean you’re able to converse about poetry or like deep technology or give speeches in another language. It really is, it’s as spectrum of…

ROB: Ooh, that’s quite interesting.

CHARLES: The definition of bilingual is like: Do you use another language in your life? So, if you are let’s say someone who is a recent immigrant to a country and let’s say you’ve got less than 1,000 words but you’re using them to buy groceries, to pay bills, to do things like that, then you are bilingual. Bilinguility is not an exclusive club. It’s really, are you actually using a language? So, if…

ROB: Ooh, so that actually gets my wheels turning. Does that mean that you can have a junior full stack developer? Because like, if you just merely speak the both languages, technically by that definition, I jive with that. You can speak two languages. You are bilingual. You can write in two different languages. You might be full stack. But does that mean in the software industry you are a junior full stack developer and then as you go on and get tasks that are full-stack-like, you get better on both sides? Or is it as an industry, we really have to specialize?

CHARLES: To start on the first point, I think that if you – let’s just restrict it to one language – if you’re doing JavaScript on the frontend and using Node.js on the backend, if you're writing Node code you are I would say by definition, and certainly by the definition of bilingual that I just proffered, you would be considered full stack, a junior full stack developer like I was saying. And I think that it’s just been my experience that as you go on in your career, you will cross multiple layers of the stack just because you can’t keep your hands off. If you have an ownership mentality of, “Here’s this thing that needs fixed,” and it’s on the backend, you know what? I’m going to go ahead and learn a little bit of how to do this, because I need it to work with the thing that I’m working on.

ROB: Yeah, that makes sense.

CHARLES: You will just naturally be drawn over borders throughout your career just because someone's got to do it, to do the thing that…

ROB: You got to solve a problem.

CHARLES: Right, when you’ve got to solve a problem. So, I think that people become more and more full stack over the course of their careers. But that said, I do think that there are clearly areas where functional specialization is absolutely a requirement. Like if you say, “You know what? We’ve got this API and we need to support 600 queries per second and we’ve got this huge, crazy deployment…”

ROB: I will not be your person to do that.

CHARLES: Yeah, exactly. That’s something you’re very much – that is something that you’re very much hiring for. And you want to be hiring for like you said, someone who has the skill and someone who, that’s what they want to do.

ROB: Yeah. If you need better state management and rendering performance and testability on the frontend, I’m your person. [Chuckles] If you need me to scale your API, to handle hundreds of thousands of requests a second, nope. [Laughs] So yeah, I agree with the specialization. So Sam, I want to know. Has this conversation swayed you any way? Are you more interested in being full stack or are you leaning to a side more? [Chuckles]

SAM: So, I think full stack is, it’s as much about skillset as it is about personality. So, like you were talking a little bit earlier on how someone who’s frontend might have more empathy towards the user. And someone who’s backend might have more empathy towards the computer and the developer, rather than the end user. I think someone who’s full stack has to have a wider range or empathy so they can empathize with all rather than just one or the other sets. I think personality-wise, I’d be a fine full stack developer. But I think professional-wise, I do gravitate towards the frontend because that’s just how I am. As a person, I like to see the visual rather than the concept. I do a lot of painting. I do a lot of drawings. So, I’m a very visual person. So, it’s really helpful to me, especially for someone who’s junior and who’s still learning and who came from that bootcamp experience, to be able to see what I’m changing. So, I think it does kind of go a little bit into experience as well. So, I think over time when I start touching on maybe some more backend work and I see some stuff that interests me, definitely I’ll gravitate towards it, just because I want to learn. But I don’t know that it’s like an intrinsic quality, you would want to be full stack or be backend or be frontend, you know?

ROB: That’s interesting. Yeah, I agree with that.

CHARLES: Yeah. That is actually a really interesting point. Because I think what I heard you say there is that when you have – software is a hidden world in many ways. You talked about it in the beginning of the conversation, the areas of the site unseen. Like you know it’s there but it’s hidden from view. So, there’s a certain amount of vision that needs to develop. So, you kind of internalize what software, like this hidden software, looks like. So what does a deployment of some load-balanced microservice clustered thing look like? Most people would not be able to answer that question. But the more time you’re exposed to it, the more it becomes burned into your inner vision.

ROB: Mental model?

CHARLES: Yeah. You develop a mental model. Your brain literally wraps around that. It takes time. But on the frontend, especially if you’re a visual person – but I would say even if you’re not – I think the same would apply to someone who’s using assistive technology. It’s still something that you can feel with your sense and you don’t have to develop a sixth sense to perceive it. So, there’s literally a problem of perception there. And so, maybe frontend work is a great on-ramp for everybody, because it’s so perceptual.

ROB: That’s exactly why I picked it. I was trying to do iOS dev before. And I could not do it for those reasons. I didn’t have that nice tight feedback loop of even though it was UI, in Objective-C you had to construct your UI and buttons out of Objective-C. Unless you wanted to use Apple’s Interface Builder and that was, meh. Everybody built it procedurally. And what I loved about HTML and CSS, was I could instantly throw something on the page, attach some CSS to it, and see it change immediately. And that felt so good. [Chuckles]

CHARLES: Yeah, yeah, no. And it’s important to get those really tight feedback loops, especially when you’re starting out.

ROB: So, if we had to tie this back together, did we decide that there is a distinction between frontend, backend, and full stack? And if there is, or isn’t, why?

SAM: I think there’s like…

CHARLES: I don’t know if we’ve… go ahead.

SAM: Kind of a distinction. But it’s also really fuzzy, I would say. So, if I’m going to explain what the difference is between frontend and backend to someone who maybe isn’t a developer, I would always go back to a video game. So, when you see your guy…

ROB: Ooh, this is interesting.

SAM: Yeah. [Chuckles] When you see your guy running around and you’re like, “Oh, this game looks really good. I’m really into these graphics,” but do you ever think about what it takes to save the game or what is actually being saved when you go to save it? So, if you’re more interested in making the guy run and making the guy and the environment look good, you might gravitate more towards frontend. But if you’re really interested in saving the data, like well what is being saved when I hit ‘save to this slot’ or whatever? Then you might gravitate more towards backend.

ROB: Or like the network layer of the online multiplayer?

SAM: Yeah, yeah.

ROB: [Laughs] That’s interesting. I’ve never used video games as an analogy. I always go like, you know, if you’re a frontend developer, you know that button that you click? That’s the button I create. And then the action that happens is usually what the backend developer does. I think I like the game analogy better. [Laughs]

SAM: I think the game analogy is something that most people can grasp. And most people can grasp. Like I’ll tell people the difference between frontend and backend if I’m talking about Facebook. Like what I do for a job is I’ll show you everything that’s on your Facebook page. And when somebody, or the backend is somebody who makes all of that come into play, kind of, you know? But I think video games are easier to conceptualize that abstraction of data being saved rather than trying to explain the intricacies of Facebook to somebody.

ROB: [Chuckles]

CHARLES: Yeah. No, I like that. I like that. So, I guess if we achieved consensus, would we say that these do exist as broad functional categories? And a full stack developer is someone who will move in between those functional categories through the course of their career. And that generally, the trend is that the longer the career goes, the more you will do that.

ROB: Yeah. I can get on board with that. I’m going to use your career as like the guiding post of that. The way you just explained it, it kind of made something click for me. You describe yourself as a frontend developer. And I think in our industry with software development and the way teams work, I think you end up specializing no matter if you call yourself a full stack developer or not. Because I do think you’re a full stack developer. But you’ve mainly been working on frontend for the past what, three years, four years? So, I think it’s okay to call yourself a frontend developer. But you are a full stack developer. But as you specialize around and amass that knowledge, that’s where you become that full stack developer, right? And so, at one point in your career, you were a backend developer. And then now at this point in your career, you’re a frontend developer. But now you have those experiences and you can draw on both of them and apply them across the fields, right? That’s super interesting to me.

So, maybe it is that you have to specialize in order to achieve the full stack. And you’re never truly a full stack developer in your role. But it’s possible, depending on the team and the team dynamics. It’s just interesting that you can be a full stack developer, also at the same time be specializing as a frontend developer at that current time, right? Yeah, that’s interesting.

CHARLES: Alright, so it sounds like consensus achieved. Let’s all virtually hug. [Chuckles]

ROB: Send the hug emoji.

CHARLES: Alright everybody. That is our show for today. We are The Frontside and we build software that you can stake your future on. We would love to hear from you, especially if you have an idea for a future podcast topic. Any news that you think is something that we should discuss, even if it’s not the theme of the whole episode. And we will see you next time. As always, you can give us a shout on Twitter at @TheFrontside or just drop us an email at [email protected]. If you enjoyed today’s podcast, it was produced by Mandy Moore, the inimitable @TheRubyRep. So thank you, Mandy. And see you all next time.