The gang gets together to talk about what they’ve been up to, year end wrap-up, and some random odds and ends.

Topics:

K Scott’s been focused on cloud stuff – moving apps to the cloud. Kevin’s been working with rearchitecting an application to Node based microservices. They’re using Docker some in dev, but not in production. There’s a discussion about Docker based deployments.

Note: This was recorded several months ago. Our site was offline for a while, the dog ate our collective homework, etc. Sorry about that. The main thing that’s changed since we recorded was the addition of user profiles.

(00:17) Jon G asks Jon Skeet about what he does at Google and how it relates to .NET. Jon’s working to make the Google Cloud Platform great for .NET developers. This is two-fold: if you’re a .NET developer he’d like GCP to be a great place for you to host applications, and if you’re a GCP developer he’d like .NET to be an obvious choice for you to build your applications.

(01:50) Jon G asks about what languages GCP supports, and how .NET fits in. Jon Skeet says it’s an obvious fit on the server-side, and he also sees that .NET has a great cross-platform and device story for clients. .NET Core landed at a great time for them to embrace it.

Note: This was recorded several months ago. Our site was offline for a while, the dog ate our collective homework, etc. Sorry about that. The main thing that’s changed since we recorded was the addition of user profiles.

(00:17) Kevin introduces the Daniel X Moore and Jenn Schiffer and asks what Glitch is. Daniel explains how Glitch is different: you can create or remix a web app instantly without needing to setup or configure anything.

(03:38) Jon likes the way that the getting started video references the whole view-source culture of the early web. Jenn talks about the value of removing the fear of breaking things when you’re getting started.

Why did you make Glitch, and why now?

(04:20) Kevin asks what led to the creation of Glitch. Daniel talks about how he’s been tinkering with pixel editors and online tools to make weird things for a long time, but finally the tools, browsers, and community have matured to a point where tools like Glitch are viable. Jenn points out that at least three members of the team that have made art editor apps and like to make weird stuff that you didn’t know you needed but you really do.

User experience overview of building a new Glitch app

(06:40) Jon asks about the experience of creating a Glitch app. Daniel talks us through as he creates a Slack bot app live while we listen in a few seconds. He points out that you start with some working code rather than having to build up from nothing.

GitHub integration

(09:10) Jenn says that there are apps like simple static site generators that are useful even if you don’t know anything about coding, don’t want to deal with deploying, etc.

(10:30) Daniel says you don’t need to set up an account and log in to get started. Jenn says that you can log in with GitHub or Facebook, and you can easily import from and export to GitHub so you’re not locked into anything. Daniel says anything that works well on Glitch should work on Heroku, AWS, etc.

(13:06) Kevin asks if the GitHub import is live, so changes to the repo will affect the live site.

(13:40) Kevin asks about the live update features. Daniel says that they’ve got things down to around 1 second latency to see your changes live, and how the development experience has changed as the latency improved.

Nerdy tech stuff about how they actually built it

(15:10) Jon asks for more info about how recent browser technology changes have made it possible to build Glitch.

(16:32) Jon asks about the backend. Daniel explains how things are wired up using Docker containers, web socket connections and magic.

(19:30) Jon asks about how things are sandboxed so one app doesn’t affect others users.

(20:55) Kevin and Jon ask for information about how many apps have been built, how many are actively used, etc. Daniel gives some high level info and talks about some popular apps like a Twitch proxy.

Glitch for teaching new users

(24:25) Jon asks if people use Glitch to teach coding at in-person classes. Jenn talks about some examples of courses, including online courses like A-Frame. Jenn says that she likes focusing on teaching one thing rather than complicating it with also teaching deployment. Daniel talks about the excitement of making a change, seeing the result, and having a positive feedback cycle quickly. Daniel and Jenn talk about how the simplicity of Glitch lets people build things that people would even build otherwise.

(29:22) Jon asks how Glitch fits in with tools like Codepen. Jenn talks about different ways people use Glitch for sketching and sharing app ideas.

Nerdy stuff like licenses, rollback, secret storage, embedding

(30:55) Jon asks if there’s a license for the code and how it works with remixing. Jenn says you can include a license file, but they don’t want to complicate people early on.

(33:25) Kevin asks if there’s support for rolling back in case you break a live app.

(35:30) Jon asks how things like API keys and passwords are handled so you’re not accidentally checking them in to GitHub. Jenn and Daniel talk about Glitch features to integrate with APIs and services.

(40:20) Jon asks if it’s possible to just iframe a Glitch app to build something like a Twitter app.

The Glitch logo is friendly and approachable. They’ve put a lot of thought into being friendly to new users.

(41:20) Jon asks for more detail about the Glitch fish logo. Jenn and Daniel talk about it, then go on to explain how they’ve designed the Glitch interface to make it friendly and approachable. There’s an interesting discussion of how that goes into tutorials, teaching. Daniel talks about how there’s so much stuff out there that no one is an expert, and Jenn talks about she thrives on being overwhelmed and loves to be able to sketch and prototype in Glitch to experiment with new things.

(51:35) Jon says he’d like to be able to click on users names to see their profile information. Daniel and Jenn talk about things they’re working on in that space. UPDATE: User profiles on Glitch have shipped since we talked.

(53:25) Jon says he really likes that their getting started tutorials have a lot of games, and he’s seen that kids really like to learn with games. Jenn says that kids are natural storytellers, and gravitate to games and art focused apps.

A JavaScript joke

(55:00) Jon asks if they have any JavaScript jokes.

What’s next and wrapup

(56:15) Jon asks what’s next. Jenn is heading out on the road to talk to people and thinking about community things like making it easy to ask for help. Daniel is working on new features like versioning, rollbacks, branching, etc.

(58:20) Jon asks if there’s something like Glitch Enterprise on the way that will result in features being turned off or something. Jenn references Anil’s post on How we won’t screw up Glitch. Daniel and Jenn talk about some potential additional features that people might want to pay a reasonable amount for, in the “pennies a month” range.

(00:44) Standard Lib is a registry for serverless microservices. It’s kind of like a mix between npm and heroku, so there is a central registry, but rather than just installing the services locally, they handle deployment for you. There are command line tools available via npm that make it easy to create (lib create) and deploy microservices (lib up).

(02:23) Jon says he’s pretty impressed with the interactive experience on the website, where you can very quickly deploy a service. Keith explains how they set up a service that handles the tarball packaging to allow creating a service in the browser. They expect that developers will usually start with the cli tools, but the browser based onboarding experience is nice for new users to get familiar with the service.

(04:22) K Scott says that essentially he can just write a javascript function and have it running as a service. Keith agrees, but says it’s also set up so you don’t need to manage servers – it automatically scales and self-heals.

(05:34) K Scott asks about how the monitoring and exception handling works. Keith says they work with several monitoring systems. Currently the output is just a text dump, but they’re working to improve that.

(06:15) K Scott asks about how you handle persistance. Keith says that currently they don’t offer their own persistence layer, and he recommends just using compose or Dynamo or RDS. They’re talking to some companies doing some neat stuff with GraphQL and gives a shoutout to Graphcool who runs a really cool GraphQL backend as a service.

(07:48) K Scott asks about their pricing model. Keith says they’re going to be going with a Twilio-style system where you fill up a wallet and pay per compute, so you only pay for what you use.

(09:09) K Scott asks how they differentiate from AWS Lambda and Azure Functions. Keith explains how they’re providing another layer of abstraction. The existing infrastructure and infinite scalability are great, but the workflows are too complex, so stdlib provides a nice layer on top of that.

(10:42) K Scott asks about their versioning system, in which development is mutable but releases are immutable. Keith explains that service immutability is a point of trust for API consumers. When you’re developing, you’re not supporting consumers, so you can continue to change your service, but once you deploy your service can’t be changed.

(12:42) K Scott asks how clients will reference an API by version. Keith talks about the syntax for referencing a specific version and says if you don’t specify a version number you’ll just get the latest.

(13:55) Jon asks what to do if he deploys a package with a really bad error. Keith explains how you can use “lib down” on a package, and discusses the monitoring and notification systems they’ve got in place to communicate with consumers.

(15:17) Jon asks about the view templates. Keith says that they started building view templates for internal use as backends to single page applications, then realized they’d be very useful to other developers. They also have templates for Alexa apps including a Delores Abernathy (WestWorld) sample app.

(16:44) K Scott asks about what some of the biggest challenges they faced putting it together. Keith says that AWS Lambda can be a black box and talks about the process of finding the right developer abstraction.

(21:35) Jon asks about Keith’s NtSeq library for DNA sequencing. Keith actually dropped out of grad school in bio chem, so he had the background and some code lying around.

Collaboration, Dependencies, and Documentation

(22:50) Kevin says that a lot of function as a service samples are petty simple, but real solutions will require multiple collaborative services. Are there thoughts on how to assemble collaborating services effectively? Keith explains that these were some of the design goals for stdlib.

(25:22) Kevin asks if there are ways to track service dependencies. Keith talks about the static analysis opportunities, and mentions that all dependent services you’ve been calling will show up in your dashboard.

(26:15) Jon is pretty impressed with the service documentation and asks how it’s created. Keith talks about the markdown and service json based documentation.

(27:25) K Scott asks about what prompted Keith to create stdlib. Keith talks about the history, starting with the nodal platform. nodal has been pretty popular as a platform, but many really liked the workflows for deployment and service management, but didn’t necessarily want to learn a new platform, and many didn’t have data persistence needs.

(29:40) K Scott says that he finds the Nodal sample very easy to read – ES2015 classes that extend a base controller. Keith talks about the unique time in JavaScript history when Nodal started. He’d made a bet on io.js during the Node / io.js split, and had leveraged ES2015 syntax. When io.js and Node merged back up, Nodal was the one of the first mature Rails-like frameworks.

(31:35) K Scott asks about the ORM. Keith talks about why he built the query composer. Nodal’s ORM is called the composer, and it uses method chaining, then reduces everything down to one query. That gets around the n+1 issues you’ll run into with ORMs like Active Record. There’s a GraphQL example at graphql.nodal.com which can take a GraphQL query and translate it down to a single Postgres query. They’re looking at breaking the composer out to allow use in other GraphQL applications. K Scott asks more about the join syntax and lazy / eager loading.

(35:21) K Scott asks about the extends keyword and object orientation. Keith says that the JavaScript community is growing so quickly that as long as developers can read the code easily, they’re just happy that it’s there. A lot of these newer developers aren’t that opinionated, and developers are happy to work with opinionated frameworks.

What do you do for fun, music apps, what’s next?

(36:35) K Scott asks Keith what he does when he’s not working on stdlib and nodal. Keith says it’s the majority of his time now. Keith says he used to run.

(37:28) Jon noticed Keith’s audiosynth.js lib on GitHub. Keith says that audiosynth was done before webaudio and webmidi, and he stumbled on someone who was generating simple sine wave audio files in JavaScript, and he extended it to use some more interesting string synthesis algorithms to make some more advanced tones. There are some more advanced audio APIs available now. Keith says that the most interesting outcome of that work was the connection he made to the first engineer they hired at stdlib.

(40:22) K Scott asks what’s coming up. Keith talks about the authentication and authorization layers as well as multi-language SDKs and support that are coming out soon. K Scott asks about the current auth story, and Keith says that currently you code it all yourself.