Intro/Problem Statement
We at Marlin love Oyster Serverless, it allows us to use AWS Lambda-like functions but with decentralization and TEE protection. Upon provisioning the serverless protocol, we soon found ourselves in a very slow feedback loop. We wrote some code, we put that on-chain, and then utilised that code in a serverless call. I did the same thing cause I didn’t know better, but upon provisioning, a few minutes went by, and no result was posted on-chain.”…Hmm, what might be the issue?”.
Upon countless hours of debugging, I found out that the bug was in the deployed code itself; I forgot to close a bracket (how stupid of me). But this was a valuable insight, “If I could miss a bracket, so can someone else, and that someone might not be familiar with TEEs and scouring through debug logs might not be something that they would be comfortable with”. So the problem at hand was to speed up the feedback loop and provide a higher success rate of execution when the function is put on-chain.
Web-workers to the rescue
We’ve all seen those 2 column layouts with the editor on the left and the output console on the right. It’s great for iteration and gives you real-time feedback on the code you wrote. We wanted to implement something like that, but with a leaner approach. Most of the popular sites that let you execute code in-browser have complex backend infrastructure that enables them to evaluate your code. This seemed too bulky for our use case. I mean, come on, having a separate backend just so that you can use a decentralised backend infrastructure? Seems a bit counterintuitive.
Here come web workers to the rescue. Now, what are web workers, you ask? Let me give you a brief idea:
Picture this: you are a wizard who lives inside a beautiful castle (your webpage). Inside your castle, a lot of things are happening: buttons are being clicked, images are loading, and little animated SVGs are dancing around. One day, you decide to build a verrryyy big magical cake (a big, slow task — like loading a giant file). But, while you’re mixing ingredients, you can’t answer the door, feed your dragon, or play your favourite medieval trap music, because all your powers are required to bake the cake! The whole castle freezes, waiting for your cake to be done.
Suddenly, a tiny helper wizard (web worker) appears. He lives outside your castle and communicates only through scrolls (messages). You ask the helper wizard:
“Hey Bythe, can you bake this cake while I do other things?”
The helper wizard nods and runs off to their own mini-cottage (a separate thread), where they bake the cake quietly without bothering your castle chores. Now you can keep clicking buttons or feed dragons, and as soon as the helper wizard is done, they send you a scroll which says:
“The cake is ready, Lord Asyncara.”
Here are some key parallels drawn in the story:
- Your castle = The main thread (where your webpage runs)
- The helper wizard (Bythe) = A separate thread that can run code in the background
- The scrolls = Messages passed back and forth using postMessage()
Our implementation
Since web workers were the way to go, we decided to implement them with some custom functionality that supports our use case. Following are some of the things that we built on top of web workers to aid in a better UX:
- Custom logging messages
- Adding support for function inputs as Text, JSON, and Binary files, to emulate and test the inputs that go into actual serverless execution
The above approach lets us do a lot with a very limited amount of resources. Here are some of the key benefits:
- Cuts down the feedback loop by ~99%
- Saves gas cost (as you deploy fewer iterations of the same code)
- No extra network load since everything is running locally (except if you have external API calls in your code)
- Be able to navigate the website while the code is being run
Oh, by the way, you can check this out right now; just navigate to https://hub.marlin.org/oyster/serverless-sandbox/ and get started! 
Final thoughts and future improvements
Having a lean sandbox environment is very helpful for us serverless enthusiasts. With faster iteration speeds and feedback, devs can focus on building rather than debugging. With that being said, we aren’t completely done yet (wink wink). Until then, write code, test, iterate, test again, and deploy! A one-stop shop for all your infrastructure needs. What are you going to build next? And as always, Happy Fishing!