The introduction of the Service Worker API into major browsers provided an opportunity for communication through web platforms directly to visitors - even after they had left the website. JW Web identified an opportunity to make the API and the service easily available to website owners.
The platform would allow the website to ask visitors if they would like push notifications. After that, if permission is granted the website visitors unique push reference can be used to send either specific, or generic messages that don’t rely on the custom opening an email, as it’ll show on their device’s home screen along with other native notifications.
Advance in technology sought
Most communication between websites and their visitors is achieved through email. Whilst useful, this lacks the immediacy that some communication requires. Major browsers, Chrome and Firefox introduced the Service Worker API to allow push notifications which work more like push notifications on native mobile and desktop applications.
Whilst the API for Service Workers is widely published accessing for all but the most technical of users presents a significant problem. Our intention is to develop a platform which allows all website owners to take advantage of the latest web technologies without advance technical knowledge.
The platform will provide plugins for the popular E-Commerce platform, Opencart as well as an accessible API for more technical development purposes.
We faced multiple uncertainties before starting the project, which included, but were not limited to:
- Direct communication with web-push subscribers. Thousands of subscription notifications had to be recorded and stored
- Installation and updating of service workers within individual browsers
- Effective and easy installation for end-users
- Recording stats on that communication
- Linking real website accounts with subscribers on the web-push platform
- Writing code that is compatible with multiple browser APIs
- Create a PHP API that allows access through a hosted UI client installable tools
- UI for client interaction with push messages, including subscriber counts, instant mass messaging and scheduled messaging.
- Create a system that defers sending the messages to a worker, drastically speeding up web requests for the client.
Work Done to resolve Uncertainties
Push messaging requires HTTPS for the installation of the service worker. JW Web developed a solution which involved the use of a Pushconnect hosted subdomain, so that the subscription page could be hosted away from the client’s site, which eliminated this restriction. However, this created an unacceptable user experience, as the user would be redirected to a different site and subsequent messages would show the subdomain URL instead of the client’s URL.
The solution to this was to change the push notifications to VAPID encrypted push notifications, which use the client domain to fully host the service worker and the subscription process. The switch to VAPID also provided additional technical benefits:
- Without VAPID a custom payload is not possible and all the service worker knows is that the server is trying to communicate.
- Increase security by restricting subscriptions to a specific application server.
- Messages can only be decrypted by the subscriber, preventing push service providers from accessing the unencrypted message.
Push messages are sent through the service provider of each supporting browser. Each sent message requires a single call to the providers endpoint with the push message data. At first this was acceptable but as a client’s subscribers list grew the number of calls increased. This placed an unacceptable load and delay on the server.
We developed a solution using the Laravel queuing system to access a beanstalk backend. Through this it was made possible for the requests to be deferred, the clients response web response time became instant and burden on the server was greatly reduced. The beanstalk backend provides a way of multithreading the send process and messages are processed in multiple batches.
As the service worker specification is in flux browsers implemented the use of the Push API differently. A trial and error approach was used with each browser to obtain a stable result.
Linking accounts to endpoints
We first first developed an API to allow client sites to assign attributes to an endpoint, this was then used in further API calls to retrieve endpoints attached to certain attributes. This created large database tables on the Pushconnect server, which were identified as a potential problem.
This was changed to a client based database with the data stored locally, allowing the client to retrieve a list of endpoints and then using the Pushconnect API to contact the given endpoints.
Create PHP API
Used Laravel to allow access through UI session based authentication or API key authentication.