0

I've noticed that you can launch a node in a Service Worker with js-ipfs. I'm curious to know what the difference between a service worker implementation and simply importing a bundled javascript library is.

Example of a service worker gateway.

I'm currently just using an imported js library to add and pin files, and it seems to work fine. Is a node truly running on the user's browser?

user339946
  • 5,961
  • 9
  • 52
  • 97

1 Answers1

1

When you run js-ipfs in your web app, it is a full IPFS node running in the browser. You can talk to it using programmatic interface (ipfs.add, ipfs.cat etc), just like you described, but it is unable to answer to regular HTTP requests because it can't open TCP port to start HTTP server. This usually is not a problem, but if you want to display an image downloaded from IPFS you need to fetch it via cat and inline it as Data URL.

What running js-ipfs in Service Worker gives you on top of regular programmantic interface, is the ability to provide responses for HTTP requests to /ipfs/{CID} paths, just like regular gateways would do.

lidel
  • 525
  • 3
  • 7
  • 1
    Is there any performance difference between the two? Seems like the service worker implementation is basically convenience from having to write your own handling of requests, is that correct? Thanks! – user339946 Jul 23 '19 at 16:26
  • 1
    Correct. In both cases you run the same JS code ([js-ipfs](https://github.com/ipfs/js-ipfs)), so there is no diff at implementation level. If you run a single page app, fetch and display a lot of static data, using Service Worker for returning data may bring you benefits of [HTTP Caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) support provided by browser, but that is about it. Workers bring the biggest benefit when you want to share the same js-ipfs instance and data repository across browser tabs or different Origins, but those are more advanced use cases and YMMV – lidel Jul 23 '19 at 19:47