ServiceWorkerWare

[delapuente]

ServiceWorkerWare is a library to write service workers in a pseudo-declarative way following Express like syntax. It is plugable allowing easy composition of middlewares. Some of its functionality was added to sw-toolbox from Google.

It's aimed to simplify how to write service workers, by implementing repetitive patterns such as auto claim and routing. It is a tool to increase productiveness and that is way it could impact on the developer audience.

[delapuente]

+1

While writing some of the more than offline recipes (virtual server and request sync), It turns out how useful is the library to write custom workers with very few lines. It's used in some recipes and it's already in production in the NGA Music App of Firefox OS. Furthermore, SWW was born with the intention of bringing Express capabilities to the client side (compare these client and remote versions of the same API).

Even though, it's aimed to eventually support foreign-fetch unleashing the potential of actual distributed networks between clients.

Trying to not fall into the "mee too" trend that @mykmelez explained and I personally support, I would want raise the hand for SWW as I see it more mature than sw-toolbox as it has unit tests for the Service Workers and performance measures and it is richer in features (pipelining, parameters, middleware composition, push in the master version).

We have a problem of visibility here as nobody beyond the Firefox OS team (and some chosen ones) care about this library but we can change this by contributing here (at the same time we help the NGA team) and advocating for it to partners & interested 3rd parties.

What do you think folks @digitarald @wfwalker @marco-c @mykmelez ?

[marco-c]

I do like the idea, I wish it had been made a standalone library earlier!

[digitarald]

+1, this is important for the ecosystem to have more tools that can be hooked together vs one big library to solve it all

[mykmelez]

We have a problem of visibility here as nobody beyond the Firefox OS team (and some chosen ones) care about this library but we can change this by contributing here (at the same time we help the NGA team) and advocating for it to partners & interested 3rd parties.

Hmm, it isn't clear exactly what the project idea is here. What contributions do you imagine us making to ServiceWorkerWare? Is this a "visibility" project, where the goal is to popularize the library; or a development project, where the goal is to implement a set of additional features?

It'd also be useful to compare ServiceWorkerWare to sw-toolbox and other alternatives, to get a better sense of how they are similar/different, and why it would make sense to contribute to ServiceWorkerWare instead of sw-toolbox (or another alternative).

[mykmelez]

+1, this is important for the ecosystem to have more tools that can be hooked together vs one big library to solve it all

Are you comparing ServiceWorkerWare to sw-toolbox in this statement, and if so, can you elaborate on the ways in which the two libraries differ in this regard?

[digitarald]

Are you comparing ServiceWorkerWare to sw-toolbox in this statement, and if so, can you elaborate on the ways in which the two libraries differ in this regard?

As far as I understand how they are positioned, ServiceWorkerWare aims to be just the core for handling middleware, similar to express (v4 extracted a lot of overhead as additional modules). sw-toolbox is less modular in its current design (but could be).

Modularity is the key to only ship the code you need and to have a small network footprint.

[arcturus]

[Disclaimer: I might fall into the 'me too' trend since I've been heavily involved in the development of ServiceWorkerWare]

I think that @digitarald made a great explanation on what are the differences, and could be the similitudes between both libraries.

When we had to design SWW, we took 3 principles in mind:

• We need to create something that is quite lean, as we don't want to impact (that much) the performance on startup time, specially in mobile.
• We have so many use cases in the different apps that we needed to design something that allows us to opt in for just what we need.
• We didn't want to reinvent the wheel so we took a model that we knew that works, it's flexible and give you some goodies (express 4 model was a no-brainer and what is more important, was familiar to developers).

SWW doesn't solve a unique problem (offline), it aims to create versatility and hopefully (that was our dream :)) a community of people that write different middlewares to solve specific problems that you may deal with in SW. Same that you have passportjs to deal with express sessions, you could have a middleware to do user management in SW, or to have a basic caching for your files. It leaves to the developer to decide how and what she needs.

Another important point that @delapuente comments is the fact that when we were designing it, from the very beginning we knew that we will need to apply some QA principles:

• We included unit test working in the SW. So you actually try the code working on its proper context. A pretty nice job, that I'm sure people will need to face soon as they plan to put their SW in production. But ok, tbh, we still need to work in that direction, some of the tests are not updated with current spec :P
• Again performance, with this work we introduced in gecko the Performance Timing API (inside workers), to be sure that we were not getting crazy and we could measure how much time we were spending processing the request, not just the round trip, but being able to setup marks and check how different parts of your code perform inside a worker.

@digitarald wrote before:

Modularity is the key to only ship the code you need and to have a small network footprint.

I cannot agree more. IMHO, we should look at SW as a technology that is way beyond of just providing caching capabilities. Right now we have as well push notifications, but in a near future we are going to have more things:

• Background sync: Wouldn't be great if someone write a middleware that refresh some urls and caches them, and developers just need to drop a tiny piece of code on it?
• Foreign fetch: allow us to create services! Exactly, same than android services, pages without frontend just an api rest to help other apps.

And some futuribles, ideas:

• Firefox OS to move propietary APIs to SW: There are some discussions to get ride of the proprietary System Message and do them via SW.
• Project Ballista from google: Web intents using SW, pretty much the same than removing System Messages from FxOS. (Seems now is the moment to get this right :))

We have exciting times ahead. I don't like to believe in library A or B, I think it should be use A when it's better for you and use B when the case suits better. I think is the key to innovation, same thing for competition, you have people from G looking at what we do with SWW and the other way around, we looking all the goodies they are doing, is not that what browsers are doing? Getting better with a sane competition?

Cheers!

[delapuente]

Hmm, it isn't clear exactly what the project idea is here. What contributions do you imagine us making to ServiceWorkerWare? Is this a "visibility" project, where the goal is to popularize the library; or a development project, where the goal is to implement a set of additional features?

It's more about initiating the community. As @digitarald and @arcturus pointed before, SWW is all about modularity and community. From my point of view, collaboration should be done in two ways:

1. Adding some missing features, most of them related with composability.
2. Developing useful middle-wares.