How service worker registration, broadcast channel, and config are implemented

[2color]

While diving into the codebase I had the following questions (see inlined comments):

Service worker registration

Why do we try to update right after registering the service worker?
https://github.com/ipfs-shipyard/helia-service-worker-gateway/blob/c7feb8884bac63beb0fb492bf4f16039c51c82f8/src/context/service-worker-context.tsx#L20-L30

Upon SW registration, why are we holidng off resolving this async function with another promise that resolves if an update has been found?

https://github.com/ipfs-shipyard/helia-service-worker-gateway/blob/c7feb8884bac63beb0fb492bf4f16039c51c82f8/src/service-worker-utils.ts#L4-L6

---

HeliaServiceWorkerCommsChannel

What's the use-case for EMITTER_ONLY? I couldn't find
https://github.com/ipfs-shipyard/helia-service-worker-gateway/blob/c7feb8884bac63beb0fb492bf4f16039c51c82f8/src/lib/channel.ts#L7

(not sure if it's me, but I found the HeliaServiceWorkerCommsChannel to be rather hard to understand due to all of the abstractions there, maybe I'm missing something but I couldn't figure it out from reading the code)

---

Configuration

How was the config for this designed? (I failed to deduce the intricacies here by reading the code.)

• Why does the redirect page component use an iframe to show the config page, if it's only loaded at the point when the origin is the final one (the subdomain resolution url), can't you just render the config component without needed an iframe?
• I see that we have two source of truth for config, i.e.indexedDB used in some places and localStorage in others. I figured this is because localStorage isn't available in the SW. We could simplify this by only using indexedDB, but I wanted to ask in case there was a reason.

For example, the config component calls both getConfig (indexedDB) and loadConfigFromLocalStorage:
https://github.com/ipfs-shipyard/helia-service-worker-gateway/blob/c7feb8884bac63beb0fb492bf4f16039c51c82f8/src/components/config.tsx#L49

https://github.com/ipfs-shipyard/helia-service-worker-gateway/blob/c7feb8884bac63beb0fb492bf4f16039c51c82f8/src/components/config.tsx#L68

[SgtPooki]

@2color lots here, but I will try to address 1:1

Service worker registration

Why do we try to update right after registering the service worker?

IIRC, this is mostly to help with hot-reloading during development, making sure that changes are fully brought into the ServiceWorker. Also, this is a naive way to make sure we don't run into problems where folks are running the old version of the service worker across deployments. We may not need this, but during dev and initial build up, was easier to add and keep than remove and risk issues. This shouldn't have any visible impact in prod, but it could probably use some optimizations and ensuring we're following service worker best practices here.

https://stackoverflow.com/questions/57916788/how-to-update-service-workers has some info about troubles with getting SW updates in comments

Upon SW registration, why are we [holding] off resolving this async function with another promise that resolves if an update has been found?

this could definitely be improved, no reason for this, but I didn't target optimizations here because it should be an easy thing to target at any time.

HeliaServiceWorkerCommsChannel

What's the use-case for EMITTER_ONLY?

This used to be used in the first iteration of helia-service-worker-gateway when we were logging work done in the service worker to the UI. The idea was to explicitly set up a comm for emitting events to others, so when reading the code you would know that channel shouldn't be used for listening. likely not needed any more.

[...] not sure if it's me, but I found the HeliaServiceWorkerCommsChannel to be rather hard to understand due to all of the abstractions there, maybe I'm missing something but I couldn't figure it out from reading the code [...]

HeliaServiceWorkerCommsChannel was intended to encapsulate all the logic required for communicating between service worker and main thread. It's a lot more than needed for basic message passing but I wanted type safety to prevent devs from getting hung up on which messages were supported, and overengineered it a bit.

Ideally, HeliaServiceWorkerCommsChannel would also contain the logic for doing iframe message passing (that was added for the config page) too, and it would abstract that logic.

It would be good to reduce this down to a more targeted impl now that most of the message passing logic we need (famous last words) is implemented.

Configuration

How was the config for this designed? (I failed to deduce the intricacies here by reading the code.)

The design was mostly documented at #22, but it's not a fully fleshed out design by any means. More below:

Why does the redirect page component use an iframe to show the config page, if it's only loaded at the point when the origin is the final one (the subdomain resolution url), can't you just render the config component without needed an iframe?

We have to load the config in an iframe in order to have subdomains be able to read the config from the root domain. I don't know of any other way to pass logic between them without cookies or a backend. We don't want cookies for reasons discussed in #22 and no backend because many reasons :).

I see that we have two source of truth for config, i.e.indexedDB used in some places and localStorage in others. I figured this is because localStorage isn't available in the SW. We could simplify this by only using indexedDB, but I wanted to ask in case there was a reason.

Mostly because writing inputs in forms to localStorage was what I was originally using. We could migrate the input components to write directly to the indexedDB. I would be open to that change if the UX doesn't decline and the code is simpler to maintain!

For example, the config component calls both getConfig (indexedDB) and loadConfigFromLocalStorage:

I think i missed removing the "loadConfigFromLocalStorage" in a spot :). Ideally, I was thinking the flow should work like this:

1. User updates inputs
   1. write to localStorage
2. User saves config
   1. read localStorage into indexedDB
3. User loads config page from subdomain (done automatically when registering service worker for first time)
   1. sw root(iframe) reads from indexedDB
   2. post message to subdomain(parent frame)
   3. subdomain(parent frame) writes to indexedDB
   4. subdomain(parent frame) uses comms channel to send reload msg to service-worker registered on subdomain(parent frame)

I believe 3.4 may no longer be needed because config = await getConfig() is called inside heliaFetch on every call now.

I hope that helps!

Thanks for taking a peek and asking such clear questions