tholm

One of the co-founders of Nitric here, and I'll bite on this one :)

I hear the separation of concerns between IaC and application code argument quite a bit, but always see an inherent coupling between the two. If changes to your IaC require changes to your application code for your application to continue working then where is the separation of concerns? If its just deployment and runtime, this separation still exists within Nitric: https://nitric.io/docs/reference/providers/custom/building-c... (this is the same way we build our own deployment providers).

With Nitric the primary goal is to increase cohesion between an application and its running infrastructure without increasing coupling to that infrastructure. With current IaC application and infrastructure cohesion is inherently very low, while giving the appearance of low coupling (despite it being quite high).

What about the framework 13? I'd class that as thin and lite.

Great question my original implementation was actually with WebSockets for this. I ended up going with WebRTC as I'm using AWS APIGateway and streaming data for things like audio and video end up being very chatty or you end up buffering to reduce chattiness (and cost) but introduce lots of latency. I decided to shift to a peer to peer model to try and keep the latency down and use the websockets implementation I'd written as a signalling server instead.

Websockets are way easier to comprehend and implement than WebRTC (learning the connection negotiation process for NAT traversal isn't much fun). But in the end using WebRTC meant I could host a more cost effective demo that could still scale reasonably well.

Looks like the linked game is a GBA game, for now this is just a GB emulator (can probably play some GBC titles as well). Was considering making a GBA version of this though.

The lambdas themselves do very little, most of the work is actually done by the game host. The bulk of the work for the lambdas is to process websocket events for signalling to establish peer connections.

I used https://github.com/roblouie/gameboy-emulator which I forked and made a very minor tweak to allow streaming audio over WebRTC. Code was super well organized and easy to understand. Was also very easy to integrate into the webapp.

Thanks for sharing this, wasn't even aware these existed, it's actually something I was thinking to working on next.

Great idea! Will look into adding that in.

That's exactly what inspired me to make this, I wanted to learn about WebRTC and used that idea as a base but also wanted the potential to play more real-time titles as well.

Correct, just a webapp with peer to peer multiplayer (where players compete or cooperate using shared control of a single Gameboy)

Not at the moment, but that's possible to implement by extending the emulator and this webapp. This implementation was more inspired by something like twitch plays pokemon (multiple users competing for control), but on a smaller scale and also playable with more realtime titles.

I haven't exhaustively tested the emulator, but haven't found anything that doesn't work so far. Pokemon battles work well, was testing it with some friends today, with shuffled controls it was pretty fun.

Good idea! Adding that to my to-do list.

If a document in plain-text provides instruction to a human on how to sort a set of things in a generic way, wouldn't this be implementing a sorting algorithm that runs on humans as a hardware platform?

What is the value add here? It appears to be a closed source project that strings together many open-source projects, but the transparency is blocked by a paywall?

That's the intent. This approach doesn't preclude the need for underlying IaC (DSL or programmatic). The idea here is to allow an application to express it's needs and intent in abstract cloud-native terms in order to inform a deployment engine.

In the case of nitric we take the requirements given by an application and use a deployment engine we've written using Pulumi to deploy it.

There is potential here to allow hooking into custom deployment engines and internal platform implementations to help standardise the way application developers integrate with cloud resources while still giving platform engineers the control they need.