(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.
(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.
(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.
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.
(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.