Endpoint Services

Tom Larkworthy

Add additional features to the ObservableHQ platform, all implemented as ObservableHQ notebooks with public source code and MIT license. 
We hope to improve trust in digital services with always auditable serverside software and data processing.

"procecess" > "process"

"acheive" > "achieve"

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

Fabian Iwand

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 :)

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 ;)

Bryant Richardson

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.

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

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