fogoplayer/space-bridge

space-bridge

SpaceBridge is a research project by Zarin Loosli; a library that serves as a load balancer for code that can be executed client-side or server-side. Each execution environment has its own advantages and disadvantages.

Server-side execution:

• is not affected by the specs of the users' device
• improves loading times
• has guaranteed access to other backend services like databases
• can use more performant languages
• can access low-level APIs to work with highly specific protocols and formats

Client-side execution:

• can continue functioning with a slow, spotty, or nonexistent network
• reduces server load
• has zero latency

Even when code is technically capable of running in both environments, most services tend to only implement one or the other based on which benefits best fit their business model. SpaceBridge asks, ¿Por que nos dos? Why not both?

Imagine:

• A browser-based 3d modeling program can use server-side processing when running on a low-end Chromebook while utilizing the local power users' engineering workstations.
• An AI image generator's models take several minutes to load when running client-side. The site is immediately responsive via the API, then seamlessly transition users to a local copy of the model whenever it is downloaded.
• Photo and video editors can use remote render farms when a user hits "export" with a solid internet connection, but when they are offline it will fall back to a local version.

Read More:

• Client-side API
• Server-side API
• Unresolved Design Questions - feedback is welcome!
• Internal Details
• Examples

Security, Privacy, and Other Concerns

There are a number of non-technical reasons why an organization may choose to run code exclusively on the client or server. Perhaps the latency of remote execution is unacceptable. Perhaps you don't want to ship a proprietary, trade-secret algorithm to clients where it can be decompiled, inspected, and reverse-engineered. There may be security issues with bringing certain code from the server onto the client, or privacy concerns with bringing client-side operations onto the server.

These problems are worth addressing, and solutions may be included in future versions of SpaceBridge if they are found and implemented. Already, SpaceBridge supports having different implementations of a function for each context.

However, the research motivating SpaceBridge's creaction is currently focused on the technical challenges of bridging execution across environments. Until the scope of that research broadens, it is left up to the user to determine where such a solution would be beneficial.

Note: thanks to Aral Balkan (@aral on Mastodon) for suggesting this section's inclusion!

space-bridge's Issues

Create tests

Make isServer an export

As nice as transparency is, AdversarialDemo has made it clear that sometimes you need to know where you're at. Export the value of isServer so users can rely on it

Third lazy

We have networkfirst, that immediately starts downloading. We have lazy, which waits for the user to call a trigger function. But we also need a true lazy load where the download starts after the first call. And probably to rename lazy to something more explanatory, too.

Catch errors in race

In normal execution we fall back to the other environment if there is an error. In the event of a race, I don't think that works.

Dynamic options

Pretty much any options value should let you pass in a function (async or not) that resolves to that value. Ex. the user might update weights based on application state.

Hash function names in dict

Polyfill APIs

This would be a massive project, but create a module that if you import * from "space-bridge/polyfills.mjs" will populate all browser global variables on nodeJS so you can use HTML element APIs and such

Support options

Right now we store user options but don't actually use them anywhere

Use a Symbol for unset rather than a String

Right now the value of unset is a string that we're just hoping doesn't have a conflict. Export a symbol instead--guaranteed to be unique

Fix return type of Lazy

Expand define to support modules

This includes being able to pull in members as well as methods

See progress of networkFirst, Lazy

Create stats endpoints

Allow inspection of registered functions on server/client side

Make unset a custom class

Make unset a custom class, allowing for runtime type-checking

Make define a decorator

Decorators provide better ergonomics (more concise, don't need to name it twice, etc.)

Update runtime /every/ time we run a function

Even when we're not in a race, update runtime stats for the one that ran

Allow passing objects with methods as function parameters

Implement queue

Add biases for powered/battery and data/wifi

Add performance metrics to server-side execution so we can distinguish between runtime and latency

Eliminate peer dependency on bodyParser

Pure Functions?

We should probably specify that bridged functions should be pure functions, since they might get raced against each other. So like, don't bridge writing something to your DB (that's what queue is for). Just use it for calculations

Use define in networkFirst

Use getter for lazy

While we should still support the schema attribute of lazy for runtime/non-TS type checking, it's a bit clunky if you're using TS. Rather than generating the names from the array, just have a universal getter.