January Tool Roundup
Tool Roundup is an opinionated list of interesting software tooling developments over approximately the last month with a bit of history.
JavaScript
A common theme this month is #0CJS (zero config js). As people get worn down by continuously writing and updating configs for compilers, bundlers, applications, plugins, test frameworks, and more, #0CJS is swinging the pendulum in the other direction. Tools like create-react-app straddle the divide (because of libraries like react-app-rewired) while tools like parceljs and microbundle try to take their config from the environment (html files, package.json, etc).
microbundle
What happens when you have a lot of packages? you have a lot of package build configuration. Microbundle is a #0CJS solution for building tiny modules. It comes from the creator of preact, mitt, and unistore, (and workerize), so is definitely influenced by the pain of maintaing multiple packages across multiple repositories. Microbundle can also be used by a multi-package tool like lerna or yarn (with workspaces) to be the “standard config” for building new packages. As someone who has built a bunch of multi-package repos in the past, you end up trying to share a bunch of this configuration anyway, so having a rollup-based solution focused on libraries is incredibly useful.
Workerize (and greenlet)
Recently I’ve been doing a lot of work with web workers to offload computation; Specifically I’ve been using worker-loader to deal with the bundling of content and attaching babel in the loader chain. Worker-loader is great, but workerize is like worker-loader on steroids.
Moves a module into a Web Worker, automatically reflecting exported functions as asynchronous proxies.
If that isn’t enough, check out the forward-compat path for module workers:
Stockroom
Stockroom is the continuation of “what happens if we start treating PWAs as multi-threaded applications by default”, and the future is pretty cool. I really like this idea for handling Apollo-Client so might look into building that. Definitely look into this one as the beginnings of a wave of worker centric modules.
Stockroom seamlessly runs a Unistore store (and its actions) in a Web Worker, setting up optimized bidirectional sync so you can also use & subscribe to it on the main thread.
After.js
Jared Palmer announced after.js on twitter on Jan 15th.
A Next.js-like framework for server-rendered React apps built with React Router 4
I’m personally excited about having another option to point people to vs next.js. I’m a user of Jared’s other similar projects (Razzle and Backpack) which really help bootstrap new server side JavaScript projects. After.js follows the recent trend of #0CJS (zero config js)
react-automata
React Automata was at the center of an interesting discussion about finite state machines in UI code. The most interesting part of using explicit state machines in UI code is that transitions between states can be locked down. For example, if you’re rendering a stoplight, state machines can make sure that you never go from yellow to green. While that sort of logic can be enforced by disparate redux actions, etc it’s nice to have it explicitly defined in the code in a single spot.
Bolt
Multi-package repos are all the rage right now, whether it’s component libraries, test tools, compilers, or design systems. You can even gain the development benefits of a single package with the bundle size benefits of multiple packages using import destructuring, multi-package build tools, and babel-plugin-import.
Bolt, then, is the next evolution of JS multi-package repos built on top of Yarn. This succeeds Lerna and Yarn workspaces as the highest level multi-package tool in the ecosystem. Bolt is a drop in replacement for Yarn :mind-blown-emoji-that-isnt-available-in-your-font-yet:. Personally I’ve used Lerna quite a bit (including for design systems work at Dropbox) and I’m hoping boltpkg turns into a more performant Lerna with a higher level of abstraction (read: jest as a default bolt test command). The workflow for initiating new company-wide design systems, component libs, and general-use packages should be much enhanced by Bolt (or at least, Bolt will inform Yarn about which features make sense to adopt).
J.A.R.V.I.S.
J.A.R.V.I.S. is another webpack dashboard tool that runs as a plugin. (Yeah, that means it’s CRA-approved with react-app-rewired). Do you need this? Ehh, maybe… But it sure is sweet to be able to see estimated load times for the entire bundle. J.A.R.V.I.S. lists the following totally cool, original features for your enjoyment:
- Shows you the count of ES Harmony module imports which can be treeshakable and the CJS ones which are not.
- Shows you how well your assets perform in 12 different connection types.
Emotion v9
Emotion is a CSS-in-JS library that is pushing the boundaries of what’s possible. Emotion’s v9 release contains support for instances, which in turn can support CSP nonces, varying class prefixes, and enables CSS processing plugins.
Apollo-Link-State
link-state is part of a rising tide of GraphQL adoption as more people realize the powerful effects of declarative data modeling. With apollo-link-state, the GraphQL ecosystem has entered full force into the “alternatives to redux” category . Using link-state, the Apollo cache can be the single source of truth for your PWA or native application using serverside APIs and client-side logic. This is an exciting alternative to redux/mobx/etc sprawl problems that is early in it’s lifecycle. Redux has served me well for years since we started using it at Docker and if you aren’t on GraphQL yet, definitely check out keajs to continue using Redux into the future.
I am super excited about the combination of preact-cli (4.5kb)+emotion(5kb)+apollo(~25kb) as a minimal, but full featured, application base. That’s a react-compatible component model, routing, dynamic styling, and data management for 35kb. This is what I feel is a very solid lower bound that doesn’t require a ton of effort to manually piece even smaller libraries (with potentially less features) together. You can, of course, get even smaller by going with straight GraphQL strings and fetch(), but the additional features of Apollo are worth the cost in the case if you’re building a large complex application.
Apollo will only become more useful over time as more and more people realize the power of the GraphQL model over REST (especially for UI development).
Prisma
Prisma is a realtime GraphQL database layer. PostgREST might have been my first experience with a tool that auto-generated APIs on top of a database. The problem with PostgREST is twofold:
- You have to write Postgres schemas to define your APIs, auth, etc which means a high barrier to entry
- It exposes REST APIs which are not known for their introspect-ability or developer friendliness.
Prisma takes a different approach in that it uses the GraphQL SDL to define the database schema rather than the opposite direction of defining the API from the database schema. For me, Prisma seems like a good fit for one of MNTNR.Systems’ use cases. The use case goes something like this: Events come into Kafka, a bunch of processing happens, then the output is piped into a datastore for mostly read-heavy access patterns. Prisma is going to get a bunch of database connectors in the future, so be on the lookout for Postgres and more. Johannes Schickling gave a wonderful talk on Prisma and posted the slides.
Special Mentions: CSS Gridish
IBM (yeah, that one), released a library that underscores a trend that’s bubbling up in the UI world. Building on top of explicit component abstractions (which have mostly been around for a few years now) people are turning their minds to a wider range of platforms. These platforms include the obvious web (React, etc) and native (React-Native) but also include the less obvious design tools (Sketch, etc), Chrome extensions, and a long list of others (CLI, PDF, .docx, etc).
As an industry we are now on a path that brings designers and engineers closer together through significantly better tooling. Rendering design system primitives to multiple platforms ensures that from concept through prototype to production everyone is on the same page. When everyone is on the same page we can integrate processes rather than rely on the far more common waterfall/page-and-redlines deliverable dynamic. Integrating processes means we can develop components that compose well together instead of building each page as a one-off. Lining this path are a number of tools like react-sketchapp, compositor, and a wide range of CSS-in-JS technologies that make design systems first-class.
Kubernetes
Unsurprisingly, KubeCon happened in December and there were almost 200 talks given. One big topic was the service mesh: Envoy was constantly mentioned and Istio was given ample stage time as well. Service meshes seem to be poised to take over through the end of 2018 into 2019 and the use cases they enable are super awesome: Blue/Green deploys, traffic shadowing, fault injection, A/B testing, canaries, and more.
One of the most exciting approaches service meshes enable is a more comprehensive “test in production” mindset. Under this approach services can be deployed and feature flagged to determine how they behave under production traffic load and in production traffic environments without “pushing the deploy and hoping”.
Cilium
Cilium takes advantage of BPF/XDF to secure microservice communication in kubernetes clusters. Part of why this is so exciting is the ability to dynamically update security rules without touching applications or container configuration (and oh shit it even is aware of Kafka). Being able to restrict access to specific topics using kubectl and labels is *mind blowingly cool*.
I’m not a huge fan of the constant Star Wars-based examples because I think it can obscure some of the concepts more than helping (but I’m a Star Wars fan anyway so it’s not an issue for me).
Cilium and Istio have an interesting relationship as detailed in What Cilium and BPF will bring to Istio. One of the craziest topics in that post is why an in-kernel proxy is faster than not running a proxy at all.
The in-kernel proxy is capable of having two pods talk to each other directly from socket to socket without ever creating a single TCP packet.
…
The difference in the two lines between “No Proxy” and “Cilium In-Kernel” is thus the cost of the TCP/IP stack in the Linux kernel.
SPIFFE/SPIRE
SPIFFE is An open standard for identity in cloud native environments
SPIRE is an implementation of the SPIFFE specification.
There was a great blog post around the 0.3 release of SPIRE entitled Securing the Service Mesh with SPIRE 0.3 that works with Envoy.
Virtual Kubelet
The Virtual Kubelet project is super cool. A Kubelet is the agent that runs on each kubernetes node. The Virtual Kubelet enables custom implementations, such as being backed by ephemeral container instances.
Understanding kubectl logs with Virtual Kubelet
