DEV Community: Ben Greenier

I'm Joining Rainway 🚀

Ben Greenier — Tue, 09 Nov 2021 16:04:43 +0000

Hello, I'm Ben Greenier. You might know me from my WebRTC work at Microsoft, where I helped create and improve things like Mixer, browserd, webrtc-unity-plugin, early versions of winrtc, and MixedReality-WebRTC. I also had a chance to work on closed-source software directly with external engineering teams to solve all kinds of problems, though I primarily focused on those in the real-time media space. I chose to leave Microsoft in June 2021 to decompress after a challenging stint working on Microsoft Teams. I wanted to build some tech to help make creating games more approachable, and take some time to figure out what I wanted to do next. I also had the extreme privilege to be able to actually do that, so I did.

In parallel, I'd been following the work Rainway was doing on their journey to create an ultra-low latency streaming solution. I first heard about them through Twitter and their work with Xbox Cloud Gaming - which is pretty impressive. It was actually through Twitter, that I found myself sitting down for a slice of pizza with Rainway's CEO, Andrew Sampson to learn more about what they're building these days. Suffice it to say I was pretty impressed. 😁

You can learn more about Rainway's ongoing work on the Rainway blog - I'm especially excited about the opportunity to work with a bunch of great folks, use Rust, explore the in's and out's of Bebop, and of course to help make creating ultra-low latency applications much easier for folks.

I'll be starting in a few weeks, and hope to be able to share more with you about the work we'll be doing together going forward! 🚀

💙🌈
-Ben

I'm joining Mixer 📺

Ben Greenier — Sat, 14 Mar 2020 12:29:39 +0000

Hi! I’m Ben Greenier — I’m currently an engineer at Microsoft working to create awesome open source projects with our partners. We get to create software to help solve really tricky problems, and share our stories as we go. This means that as part of my current job I get to play with lots of new technologies, learn how to use them, and help other folks do the same.

However, lately I've been feeling like my aspirations aren't quite aligned with my career - the things that I'm passionate about aren't things I focus on in my day-to-day role. I like being able to create Open Source Software (OSS) but not when I don't have the time to focus on building those OSS projects over time. I'm also finding that specific applications of technology are more exciting to me than others - and while working with customers on lots of different problems can be a great learning experience, It can also be super limiting. I already spend much of my time thinking about Streaming, and how I can help to create tools and platforms to enable broadcasters to be more successful, so...

I'm making some changes - Starting in April I'll be joining Mixer full-time, to work on their video platform team - contributing to things like FTL and the broader ingress and egress services that help make broadcasting quick, easy, and reliable on the platform. This also means I'll be moving from London to Seattle (more on that in a different post, perhaps). I'll be able to keep working at Microsoft - A company I really respect and enjoy working for - but focus on problems and technology that are much more my style. I'm super excited to get started!🎉

Thanks for reading - If you'd like to further support me and see similar content, follow me on Mixer and/or Twitter. Curious to learn more about what a role at Mixer entails? Leave a comment below and I'll be sure to do my best to explain or connect you with the right folks.

💙🌈
-Ben

Azure: Validating B2C Token Issuers with EasyAuth

Ben Greenier — Tue, 10 Mar 2020 11:57:14 +0000

Hi! I’m Ben Greenier — I’m an engineer at Microsoft working to create awesome open source projects with our partners. We get to create software to help solve really tricky problems, and share our stories as we go. This means that as part of my job I get to play with lots of new technologies, learn how to use them, and help other folks do the same.

I'm currently working on an Azure App that runs in Azure App Services and uses EasyAuth to validate Azure AAD B2C credentials before allowing a user to access the app. Overall things work pretty well for users, but it's come time to add some integration testing, and I need an automated way to retrieve a user credential so that the testing can authenticate to the service.

To allow automated authentication without a browser, I've created a separate B2C user-flow with ROPC authentication enabled. I'm then able to issue a simple POST request from my test runner, and retrieve a token! I thought I was done, but the test was still failing even when using this token - weird.

I loaded both a user token and an automated token into JWT.io and realized they had different issuers - what a pain! Since I had EasyAuth configured to verify that the issuer of all tokens matches a specific issuer (and only one issuer is supported) I'm stuck again.

To get unstuck, I went spelunking in the Azure B2C portal to see if there's a way to control the issuer for different user-flows. As it turns out, there is! In the portal, you can pick one of two values for the issuer. One that is unique to the user-flow, and one that is unique to the B2C instance.

It turns out that the user-flow that my actual users leverage was using the value unique to the flow. In order for EasyAuth to validate that both tokens are issued by the same issuer, I set both user-flows to use the issuer that is unique to the B2C instance. Since both flows are in the same instance they then have the same issuer. You can see the difference in the URIs here:

Issuer that's unique to the B2C instance:

https://authsucks.b2clogin.com/db6edc22-a637-4e4a-a6cc-e9ec7d8aae45/v2.0/

Issuer that's unique to the user-flow:

https://authsucks.b2clogin.com/tfp/db6edc22-a637-4e4a-a6cc-e9ec7d8aae45/b2c_1_flow1/v2.0/

After updating both user-flows to have the issuer https://authsucks.b2clogin.com/db6edc22-a637-4e4a-a6cc-e9ec7d8aae45/v2.0/, and configuring EasyAuth to use that same value for verification, tokens from both flows validated successfully and my tests started to pass!

Thanks for reading - If you'd like to further support me and see similar content, follow me on twitch and/or twitter. If you're stuck on a similar problem, or you were and this helped, I'd love to learn more about that situation - leave me a note in the comments.

💙🌈
-Ben

P.S: Header photo by Chris Barbalis on Unsplash

Debugging Terraform with Fiddler

Ben Greenier — Thu, 30 Jan 2020 20:43:07 +0000

Lately I've been working with Terraform to help manage infrastructure for a new app. The app itself isn't support important to this post, so I'll omit a description. However, it's going to run on Azure and will be built on Azure Functions. To help limit downtime, the plan is to use Blue/Green Deployments backed by App Slots.

While I was configuring this setup, I ran into some platform errors (from Azure) saying that my azurerm_app_service_slot block was failing - yet it was a really simple configuration. Again, the actual error here isn't a focus (maybe that's a good candidate for a second post) - but I couldn't find any solutions online, and felt it was time to dig deeper.

I first used TF_LOG=DEBUG to get a bit more visibility, but I wanted to be able to see the full HTTP traffic (including bodies) to and from Azure, as terraform ran. No amount of logging seemed able to provide that. I decided to try and hook up Fiddler - my favorite tool for this kind of thing.

With Fiddler running, I disabled explicit traffic capture, and set the go's http proxy environment variables in my shell session to point at Fiddler. On Windows this is two quick commands:

set HTTP_PROXY=http://localhost:8888
set HTTPS_PROXY=http://localhost:8888

I also went into the Fiddler options, and disabled https decryption for the Azure CLI Authentication endpoints - we're not interested in this traffic anyway, and while the CLI has more advanced solutions, we don't need them here.

These are the sites I disabled decryption for:

login.microsoftonline.com
graph.windows.net

After that, I was able to see my Terraform traffic in Fiddler - and inspect the differences between my desired configuration and what was actually being sent to Azure over the wire. With that, I was able to fix my issue!

💙🌈
-Ben

P.S: Header Photo by Marc Kleen on Unsplash

Why Replace React when bundling?

Ben Greenier — Wed, 08 Jan 2020 14:20:52 +0000

Lately I've been working on a browser app called Overlayed - it helps broadcasters interact with their viewers in new ways, using overlays. Under the hood, Overlayed is powered by user-defined modules (using ESM), that export React components. You can learn more about that, here - but it's not what this post is about.

Recently I've been investigating replacing React in bundled code for the browser. A friend asked me why I needed to do this - shouldn't the bundler do the correct thing? This post is about my specific use-case, where-in the bundler can't do the correct thing, because it isn't aware of what's happening.

The specific bundler I'm using is rollup - it's very good at creating ESM bundles for the modern web. When rollup runs, it tree-shakes your code, scope-hoisting shared dependencies as it goes. Take a look at this example:

# module-1.js
import React from 'react'

export default React.createElement("p", undefined, "hello module-1");

# module-2.js
import React from 'react'

export default React.createElement("p", undefined, "hello module-2");

# app-entrypoint.js
import React from 'react'
import moduleOne from './module-1'
import moduleTwo from './module-2'

React.createElement("div", undefined, [moduleOne, moduleTwo]);

Don't worry too much about the code itself, we're more interested in the import statements, and their implications. If you were to step through this code the way an interpreter would, you'd probably do this:

Import React (into app-entrypoint.js scope)
Import Module 1 (into app-entrypoint.js scope)
Import React (into module-1.js scope)
Import Module 2 (into app-entrypoint.js scope)
Import React (into module-2.js scope)

As you can see, you're trying to get React three times! Of course, many JavaScript runtimes (like node, for example) use a module cache to prevent "actually" loading React many times, but to my knowledge this isn't possible in a browser - so your interpreter needs to evaluate the contents of React three times. This is where bundling (with scope-hoisting) helps us.

Rollup can statically analyze the above code, and realize that many things will need React. Therefore, when it creates a bundle (recall that a bundle contains all dependencies and the authored source) it can include React once, and effectively pass "references" to it in all cases. In other words, scope-hosting gives us:

Import React (into an isolated scope, let's call it bundled scope)
Reference React from bundled scope (into app-entrypoint.js scope)
Import Module 1 (into app-entrypoint.js scope)
Reference React from bundled scope (into module-1.js scope)
Import Module 2 (into app-entrypoint.js scope)
Reference React from bundled scope (into module-2.js scope)

As a result, only one instance of React is included, meaning our bundled source size is smaller (only one copy of React, not three). This is good news, because it means our browser needs to download and interpret less code. And it's all supported "for free" with Rollup - how great!

Now we can talk about why I'm investigating replacing these imports for Overlayed. Overlayed has an architecture that allows for third-party developers to create plugins. This is great for extensibility, but bad for bundling.

Recall that in the example above we use static analysis to determine what can be scope-hoisted. If Rollup can't determine what is being loaded when it runs (during the "build" phase of Overlayed) it can't choose to only import one copy. This presents a problem with the plugin architecture - if a plugin depends on React, and is "built" using a separate run of Rollup (as a plugin is a separate project, maintained by a third-part developer) it won't know that it's being bundled for Overlayed (and therefore will already have a copy of React) and will include a copy. This eventually leads to a slow experience for plugins, because they all contain (and load/interpret) React, even though we already have an instance loaded.

To workaround this issue, we can write a rollup plugin (or use an existing one) to replace React in the plugin's bundle, with a small "shim" that simply references React in the parent scope. We can be confident the parent scope will contain React, as plugins are only designed to be loaded by Overlayed - they won't run anywhere else.

Take the example code above. If we introduce the following as a "shim" module:

# react-shim.js
export default globalThis.React

Bundle our code with a plugin that rewrites import React from 'react' to import React from './react-shim', and split module-1.js off into it's own third-party plugin (with it's own build) we end up with the following flow:

Overlayed app build:

Import React (into an isolated scope, let's call it bundled scope)
Reference React from bundled (into app-entrypoint.js scope)
Import Module 2 (into app-entrypoint.js scope)
Reference React from bundled scope (into module-2.js scope)

Module 1 build:

Import React from ./react-shim
Configure global reference (Referencing React from bundled above)
Reference React from bundled (above)
Import Module 1 (into app-entrypoint.js scope)
Reference React from bundled scope (above, into module-1.js scope)

By replacing React with an explicit reference in the "Module 1 build", we're able to remove React from the plugin bundle, while still loading the correct instance of React at runtime, from the parent (Overlayed) environment.

Phew! This got complicated quickly. Hopefully this can help to clarify why Overlayed isn't able to leverage the "free" scope-hoisting of React in the plugin case. If it's still not quite clear, let me know in the comments. Perhaps some revisions will be needed.

Thanks for reading,

💙🌈
-Ben

P.S: Photo by Rural Explorer on Unsplash

Replacing JS Imports with Rollup

Ben Greenier — Tue, 07 Jan 2020 16:01:52 +0000

Previously, I wrote about accessing globals from within modules which is a precursor to what I'd like to share today - Replacing imports with rollup. Rollup is a JS bundler, meaning it's job is to combine some code, along with all of it's dependencies, into one file. Let's take a look at a pattern I discovered (not invented) for replacing dependencies with alternate versions when Rollup runs.

First, we need to define a valid replacement. Let's use React as an example, and build on our example from the last post. We can define a React replacement like this:

export default globalThis.React

Which will just provide a default export that's value is set to that of the globalThis React variable. It only makes sense to do this if you know React will be provided in the global scope - Like in a browser where React is included as a script dependency, that loads before your script.

We can then use Rollup and Babel to rewrite any React imports that look like import React from 'react' to import React from "our-replacement.js", effectively. This makes use of babel-plugin-module-resolver. You might be wondering why Babel is introduced here. It's a great question, that I don't have an answer to. The build logic I modified to get this working uses it, presumably for a great reason. Given that I'm still learning, I've stuck with it to minimize variables.

Here's the babel configuration addition that makes this possible:

Note: You may need to modify some other configuration, depending on your setup.

{
  "plugins": [
    ["module-resolver", {
      "alias": {
        "react": "./react-shim.js",
      }
    }]
  ]
}

In conclusion

Using Rollup, Babel, and babel-plugin-module-resolver, I was able to redirect React imports to a custom module, that loads React from the global environment, which reduces the size of the produced browser bundle, and prevents duplicated versions of React appearing in sibling modules. However, this only works if React exists in the global environment.

I plan on learning more about this approach, and using it for overlayed going forward. Hopefully that will come with more tangible examples.

Thanks for reading,

💙🌈
-Ben

P.S: Header Photo by Paul Esch-Laurent on Unsplash

Accessing globals inside JS modules (ESM)

Ben Greenier — Fri, 03 Jan 2020 12:23:10 +0000

While working on getting things ready to import remote modules, I've been investigating replacing shared dependencies with a single version. For instance, since all remote modules will depend on React, I want to load React only once, and allow the modules to reference that single version.

As far as I could tell, this should just work, but I couldn't find any documentation that explicitly stated this. So, after a bit of googling around, I built a quick test.

Testing

To be sure this worked as expected, I created a quick test using a locally served "module" and JSFiddle to do the import. I tested with both Chrome and Firefox, and saw the expected results! 🎉

Here's the module code I used:

"use strict";

// notify that our esm bundle loaded
console.log("loaded");

// see if we have a react global
console.log(React);

And the loader code (Note: React is imported by JSFiddle, so we don't need any code to do that):

// validate React is set
console.log(React)

// load our esm bundle
import('http://localhost:5000/test.js')

And here's the results:

In Firefox, everything looks great!

In Chrome, everything looks great!

As you can see, the test is pretty simple - just a JSFiddle that loads React, and runs our import, and a locally served module, that logs loaded when it loads, and prints the React value from inside the module. Given that the React object both at the parent level and inside the module look the same, I'm happy to conclude this works great.

In conclusion

Globals (that is - things defined in the environment from which import will run) "just work" inside modules (the code inside the module, that import is running for us). That's the take-away. 😁

Thanks for reading,

💙🌈
-Ben

P.S: Header photo by Kelli McClintock on Unsplash

Learning Go - Delivering my first contribution to AzBrowse

Ben Greenier — Tue, 10 Dec 2019 11:52:53 +0000

What is AzBrowse

AzBrowse is an interactive CLI for interacting with Azure resources - inspired by https://resources.azure.com. It was created by a few of my colleagues here at Microsoft to allow for faster Azure resource management directly from the shell. Written entirely in Go and maintained by folks down the hall, AzBrowse seemed like the best candidate for me to learn a new language and start contributing quickly.

lawrencegripper / azbrowse

An interactive CLI for browsing Azure, inspired by http://resources.azure.com/

AzBrowse

An interactive CLI for browsing azure resources, inspired by resources.azure.com

Status

This is a pet project which has matured thanks to support from awesome contributions.

Warning: Please familiarize yourself with the code and the how-to's before using it in a production environment.

Cool what else can it do?

Lots check out the guided tour here.

Edit/Update resource
Multi-resource delete
Actions on resources such as restart and list-keys
ASCII Graphs for resource metrics
Interactive command panel for filtering and more
Build custom views from Azure Resource Graph Queries

For advanced config review the settings page here. For command line arguments and docs see this page.

Contributing

Take a look at the guide here for a guide on the design of azbrowse and then a look here for how to get started on deving

Install/Run

Pre-req: Ensure you have the az command from Azure CLI setup on your…

View on GitHub

Learning Go

I decided I needed to learn Go given it's increasing prominence in backend stacks like Kubernetes. As I begin to need to work with folks using these technologies, being able to understand and even modify these Go implementations will be super helpful. To begin, I read the entirety of the Effective Go documentation. That was a great start, and genuinely a well written resource. However for more practical stuff, I found myself using Go by Example quite a bit - My colleague recommended it and it doesn't disappoint. Go By Example includes little snippets of code for solving common Go problems - so not only do you get a brief description of a topic, but a fully runnable code example as well.

My first actual Go task was to add some additional regex parsing logic, and increase the test coverage of that logic. It was actually just an open issue on AzBrowse that one of the core maintainers directed me to. It ended up being a pretty great place to start, given that I had an understanding of regex already, so the only new thing was Go.

Regex in Go

AzBrowse was already using regexp for regex parsing, which as I understand it is the "Way to do it" in Go. I actually found the package documentation to be a little convoluted - I was surprised that the docs referenced other sections of the same doc for seemingly simple concepts. For example, FindAllStringSubmatch references a definition of All that isn't linked nor inline. This added a tiny bit of extra friction to the development process that I wasn't expecting. That said, the library itself seems pretty feature rich - Regex101 even has support for it's regex pattern format. This made it easy to test the regex as I was working with it.

Testing in Go

AzBrowse uses testify for authoring and running tests. This was pretty easy to get up to speed on - In fact, I didn't even need to read the docs. A few existing examples and previous experience with other test frameworks was sufficient. This made authoring and modifying tests even faster.

One challenge I did face was invalid assertion messages. When I broke the existing tests, the assertion failure messages were all the same. It was obvious to me that the assertions (all on different values) were not all failing for the same reason. Can you find the issue in the code below?

// testCases is an array of objects, where each object contains fields:
// desc, input, output
// describing the test, providing the input, and the expected output
for _, test := range testCases {
    t.Run(test.desc, func(t *testing.T) {
        t.Parallel()
        output := stripSecretVals(test.input)
        assert.Equal(t, output, test.expected)
    })
}

If you can, that's awesome! If not don't worry, neither could I. The answer is lies in how go closure scopes work. As I understand it, this occurs because our actual test run occurs inside a closure, and at some point in the future. Because of that, the variable test is bound to the last value in the actual slice (testCases) for all assertions.

To fix this, and make the assertion failures correct, I used shadowing - to ensure that the value of test would be correctly bound to the right value in each iteration of the loop.

// testCases is an array of objects, where each object contains fields:
// desc, input, output
// describing the test, providing the input, and the expected output
for _, test := range testCases {
    // shadow test value to ensure assertion failures
    // print the correct test.expected value
    test := test

    t.Run(test.desc, func(t *testing.T) {
        t.Parallel()
        output := stripSecretVals(test.input)
        assert.Equal(t, output, test.expected)
    })
}

After making that change, my assertions correctly displayed the right errors! That made it pretty easy to add more entries to testCases to add more data-driven tests to the project.

New features

With my newly learned Go skills applied, I was able to open a PR that added more masking of secret values to the --demo mode of AzBrowse. This mode is super useful for demos or videos, where you want to prevent displaying these sensitive values. I tried it out with my Azure subscription, and got to see everything working! The new masking is added from v1.2.531 and up.

In Conclusion

Learning the basics of Go was pretty straightforward, thanks to the great documentation put together by the Go team, and some external resources on the web. I was able to transition from learning Go to contributing in under 3 days!

Thanks for reading. If you've had a chance to learn and use Go, let me know what you thought about the process in the comments below. If you'd like to support me personally, follow me on twitch and/or twitter.

💙🌈
-Ben

Resources

Introducing Overlayed - Streamer Overlays Powered By React.

Ben Greenier — Sat, 30 Nov 2019 20:53:02 +0000

What is Overlayed

Recently I've been thinking about how we might create tools that can enable broadcasters to interact with their viewers in new ways. I spend a lot of time watching broadcasters on platforms like twitch, and feel pretty strongly that today's tools for interaction aren't where they could be. I'd like to experiment with some ways I think this interaction could be improved. Overlayed is the first meaningful step toward this experimentation.

Overlayed is a tool that enables streamers to see their overlays atop their desktop. I built it to interact more seamlessly with my viewers. If you want to interact in faster, more interesting ways it may be built for you too. ❤️

I'll be honest, I haven't done much work on this project over the last year. Part of that is due to some big life changes (international moves are time consuming 🎉). However, part of that is because I wasn't quite sure where I wanted the project to go. That last bit has changed - now I think I know what I want Overlayed to become.

React-powered

At it's core, Overlayed is a platform for running small visualizations that are surfaced as a part of a 2D video feed. An explicit goal of the project is for those small visualizations to be easy to create as well as consume. React seems like a logical choice for this creation, given it's adoption numbers and (in my opinion) it's ease of use.

In Overlayed, broadcasters pull in React components, align them on a grid, and get streaming. That means creation of new overlays, is as simple as writing a new React component. For instance, take a look at this clock overlay. This also means that if something already exists as a React component (say, on NPM, for instance) then it's already a valid overlay.

Okay okay - Nothing is ever that simple. Of course there's configuration to consider. Balancing broadcaster use-ability and developer-like options (sometimes your component just needs 2129 props 😉) is quite a trick. So far, my approach is to use a contribution model, just like VS Code. Consider the clock example from above - it supports a configurable locale to render time in. From a developer perspective, the author simply demands that this configuration be contributed. Once that's in place, Overlayed knows to prompt the broadcaster for such configuration. It does so using contributes-form a small module that generates a webform using the json-schema content from the contributes entry. For the clock example, the end result that the broadcaster sees looks like this:

I think this is a pretty solid model, but there's definitely work to be done, and room for feedback.

Electron-support

One of the value propositions of Overlayed (in my opinion) is that it leverages electron to create full-screen overlays that can be embedded in your desktop, atop all your windows, or behaving like normal windows. This means that as a broadcaster, you're able to see the content your overlays provide, in exactly the same way your viewers can. Electron makes this possible, giving us a cross-platform way to create these os-specific windows (and behaviors) as well as enumerate overlays (remember, these are react components) from disk.

The experience this enables is pretty cool. On my dev machine right now I have a folder in my user directory of overlays, and when I start up overlayed, electron loads them into a transparent full screen window on top of all my other stuff.

Again, there's still work to be done (especially with regard to the interaction model - ie: can you type into an overlay? Always? Sometimes?) but I'm pretty excited about where things are headed.

Roadmap

I've never come up with a roadmap for a side project before, so I fully expect this to be a bit off. That said, here's the stuff that I'd like to focus on, to improve Overlayed in the near future. If you'd like to help, starting a conversation with me about one of these things is probably the best place to begin.

~~New product site~~ (Live at overlayed.app)
Find reliable cross-platform testers
Prettier configuration UI
Support running in browser (without electron)
Better dev environment
Better overlay alignment options
Layout management (different, loadable layouts)
Camera example
Audio example
WebGL example
Testing. There is currently no testing. There should be testing. 😓
Overlay "store"

That's all for now

Phew - looks like a lot of stuff ahead, better get off DEV and go write some actual code. Thanks for reading! In the future, I'll post deeper dives into the technology choices (and hurdles) that made Overlayed into what it is today. As we add new stuff going forward, I'll be sure to post about that too (this post is part of a series just for this kind of thing).

If you'd like to support this work financially, buy me a coffee. If you'd like to support it with love, follow me on twitch and/or twitter.

💙🌈
-Ben

Hello, World.

Ben Greenier — Fri, 29 Nov 2019 22:05:58 +0000

Hi DEV - I'm new here. I used to post stuff over on Medium but have heard great things about this platform and wanted to give it a shot. Hell - if things are even remotely as easy to use as setup has been, I've got high hopes.

I'll be posting more and more (I hope) about overlayed as I focus on building it out (live on stream btw)...so stick around.

Right well, that's all I've got for now - have a lovely evening.

💙🌈
-Ben