Oh cool. Thanks but no thanks. I entertain the idea that I might support other platforms.
webcode is about decentralized compute using the web as the application server*. Observable happens to be the best code storage and IDE for the web, but if you take a close look at the URL structure I am taking “observablehq.com” as a prefix, with the idea I can federate over other code hosting platforms (e.g. Github). That said, the killer 120ms “instant deploy” live-coding feature can only work with Observable so I am not in a hurry to support other platforms yet.
So the last few weeks I have been trying to work mainly on reliability and smoothing rough edges.
I have been working with the new webcode endpoints and they are so much nicer to work with, but that performance came with various cache invalidation bugs.
Cache is actively purged now when a notebook is published using the “On Version Hook”
Fixed a race condition where cache was loaded twice for a slow function. This fixed a fairly common occurance of the first cold request failing.
Furthermore, I have installed a ton of active monitoring (see “healthcheck” notebook, blogs). I have caught various login bugs, require bugs and stuff but the little bugs are slowing down now. Now I see errors before you do! Which is great. The theme of the last few weeks is productionization.
The developer experience of webcode.run is lush. It’s a total game changer that you can leave a “debugger” statement in the middle of a request handler.
I have upgraded many of my old notebooks, and I am seeing great performance improvements. For old serverless cells you can opt-in high performance with {reusable: true} in the options.
Rate limits have been greatly relaxed for webcode.run (or for serverless cells with the “reusable” flag set to true.)
Previously, we had draconian rate limits to avoid putting pressure on Observablehq servers, but because of the new performance improvements, pages are cached and we don’t put much pressure on Observablehq domain anymore. Thus now you can no do a sustained 10 requests per second with a 100 request burst for endpoints that cache pages. I can probably do higher.
I fixed some race bugs today too which caused some endpoints to permanently get trapped in a bad state. Generally, I have noticed if you toggle the “live coding” flag, this cache is reset and you can recover. This is the equivalent to turning something on-and-off again, another one is publishing a notebook, also resets the cache. The cache seems to be where all the bugs seem to reside (yay stateful services).
We had a 7 hour outage recently in us-central1 region. I think this used to happen regularly but I did not notice as I primarily use eu-west4 and active monitoring is only a recent addition
Now I have active monitoring I am prioritising reliability. I am not quite ready to set an SLO and hold pager so if its timed badly (like the one recently) it might be off while I am asleep.
I have made a public status dashboard. Unfortunately UptimeRobot is under DDoS attack right now and new dashboards are not provisioning ATM, doh. It should be here
Root cause was a glitch in the Google Cloud logging SDK. I only added the logging SDK to support development with user facing logging, but I have since cooled on the value of eventually consistent logging. I think webcode’s traffic tunnelling and live debugging is a much better approach to visibility so I will just remove the logging code to 1. reduce dependencies and to 2. make the binary more portable to other Clouds/self host.
Apologies again, I am working towards making this service good so just bare with me
Major Feature: Serve public APIs from private Notebooks
I have been busy making https://webcode.run suitable for commercial use. There is a better landing page at https://webcode.run, and we now have a paid option which allows team notebooks to serve public APIs without exposing their source code.
My heart is in open source, but I think this is a balanced way of generating an income stream and still supporting the open source ethos.
To make an endpoint publically available you just need to upload an Observable API key in the admin panel
Because the source remains secret it simplifies building external connectors as you can now place credentials in the private notebook. In an ideal world I would be able to reuse Observable secrets but they currently are not available even to API_KEY holders (hint: API_KEY to get secrets and databases · Issue #347 · observablehq/feedback · GitHub) so you will just have to hardcode them or place them in webcode.run secrets.
I am building up resources for a marketing push. I would love some testimonials or product enthusiasm I can repost to my website. Ideally, twitter (@tomlarkworthy) I think is the best place to post but if you don’t have twitter then posting here is good too. Have a look at https://remix.run so see how they do testimonials if you want to understand the format better
So WEBCode is the compute layer for a better Cloud programming environment, that is 100% browser based and literate programming (due to Observable). However, we also need to store state, and it has to be frontend-first to work with Observable. So far I have been using Firebase well, but its not very extendible and your data sovereignty is taken out of your hands, so I have since started prototyping building a Firebase compatible database server in WEBCode.
This will make it trivial to host firebase data wherever you want, but also demonstrate what a high performance WEBCode program looks like. Because the source notebook will be forkable, you will be able to just use Javascript for the authorization rules instead of Firebase’s security rules language.
Anyway, I think WEBCode is a better way to do backend programming because you can interleave documentation with code. So building a distributed database like Firebase is actually non-trivial, and to do it well, you need distributed database concepts like “causal consistency”. So I am embracing the literate programming affordances to explain what causal consistency is, and how to architect for it, inline with the actual implementation. I will then publish the pieces of the database in chunks so it’s not too overwhelming.
The following notebook is actually part 3, but it is the most readable IMHO and covers building a causally consistent storage and messaging backend over REDS, with inline documentation and integration tests!
Hi so I am changing to a new role and thus will not try very much to commercialize this anymore. I will continue to leave the servers running and I have MIT licensed the runtime. Which is also on dockerhub but needs a little extra abstraction to enable a bring your own firestore for the control plane. Happy to help do that if that’s interesting to anyone.
My aim has always been to try and distribute and disseminate the specialist knowledge I pick up on my journey as much as possible. WEBCode is one manifestation of this – but so is working for an early stage startup in Berlin, which is why I am very happy accept a role at taktile.com which is at a relevant intersection of humans-in-the-loop data/machine learning and automated reasoning.
Thanks for all the work you’ve done on this project and for sharing all the cool ideas and features along the way! It’s been a blast chatting and playing around with the system and experimenting with my own variations. I learned a lot and look forward to your next wave of creations hitting the world. Good luck in the new role, hope to see you around from time to time!
