"procecess" > "process" "acheive" > "achieve" "Its" > "It's" (because I might as well proof-read while going through the docs) :)

Thanks its appreciate a ton!

Does the deployed cell still fall under CORS restrictions, or could it be used as a CORS proxy?

Nvm, just saw https://observablehq.com/@tomlarkworthy/fetchp :)

As an aside, I've found it helpful to link changelog entries to their pinned (published) notebook versions, especially for BC breaking changes.

I think I aim for no backwards incompatible changes. If you need to do that then you should fork (and write a link to the new version in the documentation).

Well, there's also the educational value of being able to see what changed by comparing the versions :)

Grrr, I keep resolving these by accident. Yeah versions are good to include for history browsing. I will try it out.

No worries, and no pressure! If it can wait a bit, I'll try to add a changelog generation example to https://observablehq.com/@mootari/api-bridge-getting-started

FYI, it is 2021 now ;)

oops! Thanks. I might add streaming to this soon.

I assume this includes link-shared notebooks? Misspelled: "rember"

yes. I clarified, thanks for the all the spell fixes. I am desperately trying to figure out a lightweight way to spell check. For big posts I send them to grammarly but these little blocks are more awkward.

Would a spellcheck button suffice, that, when clicked, checks the entire DOM for misspelled words?

Simple proof of concept: https://observablehq.com/@mootari/typo Not very practical yet, but I found "propogation" and "storeing".

I'd love to hear more about the backend setup. Are you using a full puppeteer instance to run the notebook with a headless browser, or can the observable runtime execute directly in a node process without that? How do you handle re-importing modules that have changed, do you have to bounce the node process? How often are you fetching updates from the public notebook, surely not for every call right? What's the situation with user-callbacks using browser features, or does their included runtime handle polly-filling all that? Haha I've been tinkering around looking at doing a similar setup.

I think using puppeteer is going to be best, so your code works the same in frontend and backend. Just need to figure out how to wire-up the call to page.evaluate in puppeteer so code in the serverside cell can "send" the response back out which has to be serialized. I guess that's why you aren't supporting pipes eh?

yes, Puppeteer, I think pipe support is possible (convert to an analogy to a generator polyfill) but it's not easy so thats why I pass for now. For readers this conversation has moved to https://talk.observablehq.com/t/serverless-cells/4491/11

I noticed that if you call any imported code from another notebook that contains calls to deployment, it will deploy that function into your notebook. I'm not sure of the implications of this, as I noticed thinking I could have wrap the deploy call with one that returns an API client for the backend code that was deployed.

It's a feature for me, I want people to be able to author serverside code and share it with others, with those others paying for their infra of their own usage. You absolutely can distribute the client API in one go, thats how the https://observablehq.com/@endpointservices/zapier notebook works

One extension I was thinking to add was to have the deploy function return an API client for the deployed code. By default, it just calls a function that calls the API url you've defined. Maybe there could be some more options to set like methods to attach to this API client. And then there could be some way to turn-on a "debug mode" for the function that would have this API client instead look at "window.deployments" of the current notebook and call the handler directly to see the effects of changes made in your notebook without having to publish (effectively emulating the backend calls). You'd have to pass-in a mock context, using secrets from your observablehq account. So perhaps you enable it by importing { emulate } from serverless-cells and calling it with your mock object. It would return an html control to shows what functions are deployed locally and whether to toggle them for debug mode, or toggle all. One issue using locally-running implementation is that origin headers on outgoing requests would be different, like in an oauth exchange, so you'd have to add your own worker URL to the allowed domains of a target service. I was mainly thinking to use it as a way to test changes made locally without having to republish the notebook and wait for backend to refresh, but I guess I can fork the "live" version and then suggest it back to my myself as "pr". Or maybe the deploy function can return an html control with UI widgets and oauth stuff to do PUSH deployments to the server to support private notebooks and such, but that maybe goes against the vibe you've got going here of open and transparent services ;)

I used to have a local mock, but it was never easy to switch between the modes and thus was basically never used. Added to the fact it might behave slightly differently and it seemed more of a hinderance. e.g. locally CORS and secret access are different, and they are basically the main interesting use cases.