I met Connor Hicks through work. We both work on webassembly powered projects in our day job and he builds a really cool platform called Suborbital. Which you can think of as a lambda for webassembly modules. Actually I like to compare it to architect. It’s a framework that tells you how to build your project, split up the code into functions (or
runnables as suborbital calls them), and then tell you how to connect those functions together to build an application.
Connor saw me lamenting on online about the state of websocket powered subscriptions for lambda powered projects. There are not many solutions that aren’t services for this out there and not many that are production grade. (I have thoughts here for another post.) And invited me to join him and David McKay to build a GraphQl client for Suborbital to be used by webassembly. We did it live and it was really fun!
There was so much I want to gush abou that didn’t make it into the stream;
- wizer instantiates your WebAssembly module, executes its initialization function, and then snapshots the initialized state out into a new WebAssembly module. Imagine if you could do this for any app or webpage!?
Working with Suborbital was a joy and I’d pair with Connor and David any day.
My lament about web socket subscriptions on lambda;
This thread can be found at toot.cafe includes 26 statuses.
Trying to get graphql subscriptions working in a serverless world is like pulling teeth. It’s very possible but every layer of the stack has peculiarities.
Dev servers aren’t standard in half a dozen different ways and their websocket implementations are all over the place.
Graphql Websocket protocols are all over the map, graphql-ws started with a protocol which is great but none of my dev tooling speaks it in favor of the Apollo protocol.
I’m finally up to the point where I’m editing my node_modules and adding in proxy debuggers to find out why urql can’t get updates when they’re being sent.
I’m also trying to patch both the subscription servers and the dev tools to have enough leeway to work together.
New frustration level webpack caching node_modules and ignoring changes. I'm sure it's much faster but oh boy that was an hour lost.
graphql-ws ships both .js and .mjs files - I didn't actually know which I use with next.js's webpack config 😂
It's the .mjs btw
Firefox devtools or probably an extension I'm using just crashes firefox all the goddam time. And not hard crash but like slow eat all your ram Chrome is so much more functional here.
I had a hunch that one of the most popular graphql websocket clients wasn't subtly broken but afaict that's where the problem is. The fantastic chrome debugger helped me step through the code and determined my server is infact doing something funky.
These ids do not match
The fix in my fork of an alpha library that is fantastic as it is untested. If this works I'll have my first pr on the upstream project. 🕺
(Maybe second, but I didn't open the other one because I don't know if the author actually wants them.)
With the power of serverless I can publish the fix to my test graphql websocket server package, npm install it, rebuild and reload my code and not even drop the websocket connection.
You can see the mixup in ids here in the db (dynalite local ddb)
💃 Wooo!!!!! 🕺
Now to actually do something with it =p
If you want to follow along at home for this one line change 🤷♂️
So the big reason for my fork of subscriptionless is that Architect (http://arc.codes) has a fantastic sandbox for ddb, lambda, sns, and api gateway http, but gives you non aws like functions for websocket management.
So my next step is either get arc to convincingly fake whatever the ApiGatewayManagementApi class talks to or get hooks to replace the calls to that class into subscriptionless. They work fine in my fork but who wants to maintain a fork?
Stepping through the aws sdk source is a lesson in misdirection. I think I'm going to turn off all the retries and hope the errors tell me something good.
oh hey it's worth showing the sub/pub code. The warning is http://nextjs.org not understanding non standard subscribers, but other than that it's fantastic.
This is my custom hook that is called instead of the aws code. It uses arc/functions's websocket helper.
This is the same thing roughly but with the ApiGatewayManagementApi from connectionless
Arc under the hook looks for some configuration from it's clodformation setup. Connectionless on the other hand uses the info from the context of the websocket message event passed to the lambda. Both work in production but the data needed in the development sandbox isn't there.
So only arc will work in the sandbox. I want to fix that if I can.
So it looks like the class assumes https at somepoint becasue connectionless only provides a host and path. This sucks because I don't have https in the sandbox.
I can probably use the arc's supplied config (process.env.ARC_WSS_URL) in both prod and the dev sandbox but connectionless making the url from the event in dev sandbox can't happen as it will always assume https.
Anyway realizing what you want is impossible is a good time to goto bed. I plan on waking up wanting different things.