(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.
At NDC Oslo, Sean Trelford did a lightning talk on composing 3D objects using F# and OpenGL. Oh, and he’s 8 years old. Sean (and his dad, Phil) talk to Jon about learning coding with Small Basic and F#, and how it’s fun to learn coding by building video games.
(1:13) Jon asks Sean whether he showed slides or did live coding.
(1:39) Sean made an army from one 3D man model.
(2:09) Jon asks how difficult it is to call OpenGL from F#. Sean’s dad, Phil, explains how Sean used a domain specific language – about 50 lines of code. You can use it to create shapes like cubes and spheres, color them, transform them, etc.
(3:30) Phil explains how Sean used the F# REPL to create and modify 3D objects interactively, then used functional composition to put the parts (head, arms, legs) together to build the army man, the used functional composition and aggregation to create the army.
Learning Small Basic and F#
(4:37) Jon asks Sean if F# is his first computer language; Sean says he started with Small Basic. Jon asks if he found it difficult to move from Small Basic to F#, Sean and Phil explain how F# is actually a pretty natural step from Small Basic. Small Basic has no functions with parameters, so when they had a project that ran into that limitation they just moved the code from Small Basic to F# and used the Small Basic library to construct 2D shapes (leveraging WPF).
(7:02) Phil said that last year he and Sean rewrote Small Basic as Fun Basic (available free in the Windows Store). It’s an IDE with IntelliSense, code completion, etc. It’s got backward compatibility with Small Basic, but includes function with arguments, pattern matching, etc.
Learning programming with video games
(8:02) Jon asks about what next for Sean. Recently they went to a game jam and made a platform game. Phil says the REPL environment is huge for game building.
(9:04) Jon mentions the IoT lab at NDC and asks Sean if he’s done anything with IoT; Sean says no. Jon says it seems like people try to get kids interested in coding with IoT, but maybe games are more fun to get started. Phil says that Sean’s got a Minecraft channel on YouTube. Jon asks Sean about making videos about making games.
(10:38) Phil says he got started on computers with games – he made his first game when he was 11, but his first commercial game was when he was 14 – Flint Eastwood.
(11:44) Jon asks Sean if this is his first time in Olso, and his first conference. It’s his first time in Oslo, and his first "speaking" oriented conference.
11:28 Jon asks if they’ve got any last messages, maybe to encourage kids to get started with coding. Phil recommends the Hour of Code, as well as other resources online. Phil says his older son got into programming by adding levels to games, then writing scripts for AI’s, etc. Phil says that’s how he got started – looking at other peoples’ code and going from there. Don’t necessarily get hung up on fancy coding concepts, just script something and have fun!
(0:48) Ian explains that "micro" doesn’t imply number of lines of code but "A bounded concept/business capability within your Domain" (put forth by Martin Fowler and James Lewis)
(1:20) Ian talks about breaking the domain problem down further and further for simpler testing, better fault tolerance and incremental releases.
(2:20) "If you can’t QA everything you need to be able to monitor and respond to issues rapidly."
(2:42) Scott Allen asks if Devops is a driver for Microservices rather than physical deployment or team size.
(3:00) Ian talks about the scale limits of developers and teams and how component based architectures.
Have we been here before?
(4:00) Ian talks about how Microservices is the next generation of component-based architectures after DCOM, CORBA, SOA and the importance of understanding what worked, what didn’t and why.
(4:49) Asking a component for a cup of tea vs telling something how to make tea highlighting the difference between Microservices vs RPC. RPC was very coupled to behavior which lead to fragile APIs.
Finding the "micro" sweet spot
(5:50) Jon asks how you manage the complexity of orchestrating many smaller pieces.
(6:15) Ian advises against going too small – Nanoservices – where the overhead of a service overshadows the utility value of it.
(6:30) "It’s really hard to get a feel in a new domain of where those points are that you can slice effectively" – one solution is to start exploring the domain in a traditional monolithic way and to break the parts apart at the seems to get the tradeoff right.
Tooling and support
(7:06) Jon asks what a good way to manage these services including profiling and monitoring.
(7:20) Ian recommends some tools to help:
New Relic for introspective monitoring and diagnostics.
Logstash or Splunk for log analysis and the usefulness of adding a GUID to a request that flows through messages and logs to correlate the activity.
(02:05) Kevin asks Rob about his Xaml platform work with Caliburn.Micro. Rob says he’s transferred that work to Nigel Sampson, and it’s alive and well.
Comparing Aurelia with Angular
(05:25) Rob also wanted to target transpiled languages so it worked well with ES6, ES5, TypeScript and Coffeescript. By comparison, Angular was pretty focused on Dart and AtScript.
(06:12) Jon references Rob’s post comparing Angular and Aurelia code and asks about conventions. Rob describes how conventions work, how you can create your own conventions, and how you can override conventions by providing metadata (but only for overrides, not all the time).
(08:56) Rob describes how binding and the templating syntax work. Aurelia minimizes additional markup for binding, whereas he sees Angular syntax focused on theoretical tooling experiences that could be built, but nobody’s committed to. Also, while Angular’s syntax is technically valid, it doesn’t work with cases like SVG. There’s a secondary binding syntax to work around that, but having two syntax doesn’t seem like a clean solution.
(12:31) Kevin asks for examples of conventions in Aurelia. Rob explains how custom elements work with EcmaScript 6 modules and exports. No metadata is required, as compared to Angular which requires specifying metadata in all cases even if you’re not using them. Rob also explains custom attributes (again using a simple exported class). Naming conventions set up the mappings so no metadata is required. Value converters are yet another example – the naming convention assumes that any class ending in ValueConverter is automatically registered and configured.
(16:43) Rob says that in Angular you need to declare all directives you’re using in your view models. That really bugs Rob because the implementation details in the view shouldn’t be reflected in the viewmodel. That was required for lazy loading, but he sees it as a design problem and a maintenance problem. Rob says that Aurelia uses an import in the view and doesn’t touch the viewmodel, using the EcmaScript 6 loader. Rob says that this design makes some conventions impossible.
The Aurelia Pitch
(21:08) Scott K says he likes the class-based design in Aurelia and asks Rob for a quick pitch for Aurelia to sell it to a team. Rob talks about the clean, standards based design that allows decomposing complex screens without requiring extra configuration. It’s easy to build, extend and maintain. Rob also talks about the binding syntax, and the ability to plug in other binding strategies by dropping in an adapter. The binding strategy system has been tested out with Breeze.js and Knockout, allowing you to use your existing models without requiring unnecessary dirty checks.
(26:42) Scott K asks how object.observe works with tranpilers. Rob says there’s a polyfill that generates getter / setter pairs if object.observe isn’t available. Rob explains how this works with the micro task queue, and how it allows for queued tasks to handle queued work efficiently. Rob talks about the task-queue in Aurelia, and how it can be used outside of Aurelia as well. Rather than directly observing DOM elements, the task queue allows for batching changes for efficiency.
(35:15) Kevin asks if Aurelia handles a persistence layer. Rob says that rather than building that, they’ve worked to make it easy to plug popular persistence libraries in. He also discusses the validation system they’re working on.
(38:22) Jon asks if Rob’s looked at PouchDb and references Herding Code 181, in which Max Thayer explained PouchDb.
Why not write my own framework?
(44:40) Jon asks if Rob thinks people will use SVG. Rob says it’s more about building a production-quality framework, then gives some possible usecases like graphs, mapping and custom elements. Rob says that people do all kinds of things you might not expect when they use a framework, and building a real framework requires it. Kevin says at his last job they’d started converting image sprites to SVG, and it was a pretty good use-case.
(49:05) Kevin asks about Rob’s thoughts on React. He says it’s a good renderer, but it’s not a framework. He and Scott K agree that React is a library, not a framework. Rob says he wrote a blog post in which a custom Aurelia element uses React as a custom renderer. The Babel transpiler allows mixing JSX with ES6 code, and this allows continuing to use Aurelia binding. In general, Rob says really smart, but if you need a framework you’ll end up cobbling a bunch of things together to use it. Instead, he’d recommend using a framework like Aurelia and just pulling in React when it’s required.
(53:22) Kevin asks if Rob’s considered adding a virtual DOM to Aurelia. Rob says it’s not clear that there would be an advantage in most cases.
Questions from Twitter
(57:25) Question from Twitter (@cecilphillip): "What’s the rendering perf like compared to ReactJS?" Rob says that React is going to be a lot faster for initial render time, whereas Aurelia is probably going to be faster for updates. It’s hard to give an accurate comparison; Rob says they’re mostly focused on being fast enough rather than the fastest. He says Aurelia’s not slow now, but they’re focusing on some upcoming performance enhancements that he’s expecting big results from.
(1:02:09) Question from Twitter (@csharpfritz): "can you talk about what lead to the choice of architecture with JSPM?" Rob explains how JSPM integrates package management with module loading. Aurelia isn’t directly dependent on JSPM, so you can use other package managers and loaders if you want. Jon says the one thing he wants JSPM to integrate rate limiting so he doesn’t hit the GitHub rate limit; Rob says this is being addressed in a future release since most cases don’t require the hitting the rate limited API.
Scott K’s Packaging Rant(tm)
(1:08:11) Scott K has a "short rant" about NPM, JSPM and all package managers in general: they all use existing config files (like gitconfig) and should be tested behind corporate firewalls and proxies. And then there’s the nested package thing, which doesn’t work well on Windows due to path length limits. Jon says he uses the flatten-packages package. There’s a short group rant about the file path length limit on Windows.
Final questions and wrapup
(1:13:40) Jon asks if there are any patterns or thoughts on server-side development for Aurelia. Rob says there are starter kits on the way, and people are using Aurelia with lots of back ends (.NET, node, MEAN, etc.). He talks about samples on the way, including a Todo app (even though he thinks Todo apps aren’t useful for application frameworks).
(1:17:15) Kevin asks where Aurelia’s at in a release cycle. Rob says it’s currently in preview / alpha phase but targeting a beta around June or later. Don’t go to production with it now, but get ready for the release after that.