What do you expect from your Meteor PWA

packages
#5

Here is a nice tutorial on Vue CLI’s PWA integration, paired with Firebase, it would be nice to achieve this or better with Meteor.

And for anyone else doing research on PWAs, this is a really nice summary article:

I don’t think end users care much about what powers their apps, but for building a Web App, deploying a Desktop app, and then a Mobile App, I can’t imagine something better than this. My existing Meteor app just needs a couple tiny add-ons as I’ve already put a lot of effort into making the apps design serve mobile & desktop formats.

Here is to hoping Apple will catch up to Google on the support, and Apple will probably be “naming” these something new. I guess Apple does say PWAs are a Google term, haha. This might save 1 full year of dev effort off my future life :grinning:

#6

Asa former PWA developer advocate at Google (here’s my top PWA write-up back in 2018), I’m really happy to see this initiative!

Google has some advice on delaying a bit the PWA installation:

To answer the question from the OP, in my current project the #1 reason for building a PWA (beyond the install-ability itself) is push notifications.

As for the technical implementation in Meteor, I wish it used service workers instead of appcache.

4 Likes
#7

I’m having fun researching this and playing with my Vue + Meteor app so far, I’ve found that a single meta tag in my main.html file is all I need to have my iOS Safari browser create the PWA version of my app when I select “Add to Homescreen”

<meta name="apple-mobile-web-app-capable" content="yes">

More details here:
https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html

My users are probably 95% iOS & MacOS users, so far, so the Apple side of things is really core my user’s experience.

In exploring how the iOS (Apple) world is handling PWAs, this was a helpful response on StackOverflow:

image
image1632×1490 322 KB

I guess this helps me feel better about why I was not 100% aware of the PWA concept, in the Apple world it is not a very specific thing.

My app is a PWA by concept, but just not by Google specifics yet, maybe in a couple days I’ll have it “Google” compliant. It would be cool if the PWA concept was really a standard, but it does seem like everyone is moving in the right direction. Maybe in a couple of months or especially a year things will become a bit more standardized.

Just for fun I sometimes have to check Google Trends to see what the world is searching:

image
image2362×2038 332 KB

#8

I also found this to have some helpful tips for iOS PWA apps:

After reviewing all this, it does seem like Google & Apple handle their configurations almost 100% differently, so both Google & Apple configurations should be used.

I appreciate everyone bringing this topic up, because it really is a relevant one. Maybe I’ll write some guides as I work my way through this. :sunglasses:

3 Likes
#9

Two other things I would like to add about PWAs:

  1. There are several public stores for PWA apps being created, here is an example, which is great since I’m not a fan of the centralized Android/iOS stores and I’d rather see a decentralized stores (we pay premium for those phones but I don’t like the fact that they’re controlled by two major cooperations, it’s not in the spirit of the web and decentralization).

  2. With that said, you can publish PWA apps directly to Android and Windows stores if you want to reach those audience.

Apple is the new (IE) when it comes to PWA, they’ve been really slow to adopt the trend, they derive a lot of profit from the Apple store and native apps.

2 Likes
#10

I have thoughts on this! But it’ll take me a minute to compile everything, so here’s just a couple of off the cuff random comments:

PWA is very doable now, given all existing tech. PixStori is a PWA (with one caveat below). The only real thing missing is a service-worker. There is one - I have a version in my starters. This service workers really only solves a sub-set of what you might want to solve with a service worker- mainly it captures the main js and css bundles. In order to get everything else cached for offline use, you might need to enable appcache, which aside from enabling the legacy and deprecated appcache browser feature, also prefetches and caches all dynamic modules.

The truth is, most of what you might need a Service Worker for is taken care of in other ways in Meteor, so we probably don’t need a super complex one. It’s also the kind of thing that developers might want to take the care to write and understand themselves, rather than using something generic.

Some things that are missing off the top of my head (but which are probably achievable without a TON of effort)

  • a way to capture a app shell when SSR is enabled, instead of capturing an SSR html page, which may contain outdated data, and other problems.
  • Push notifications - it’s own whole thing.

PWA manifests and the like can all be created by external tools. Meteor could have a thing built in to do that (similar to Cordova), but I actually prefer it this way. Your mileage may vary.

One problem I do have, is that I have a memory leak with my SSR code but only in production (which I think is related to mix of Fibers/Futures and React hooks/fibers - different fibers), which has been difficult to trouble shoot on Galaxy. What I probably need to do is learn enough devops to get a production build up and running in a Docker container (I got this far), and then run some tools on that to figure it out (working on this). But there’s a reason I use Galaxy. Hopefully the ability to hook up a debugger to Galaxy instances is coming. Currently SSR is disabled on PixStori because of this, which also disabled necessary features like open graph, etc.

(I’m probably mixing up some offline-first stuff with PWA here)

2 Likes
#11

PWA’s are a very interesting thing. We have been using it with Meteor for around 2 years, creating dinamically a PWA for each one of our clients. We dont have SSR but we use server-render package to send the open-graph and other metatags to the client without issues. In our case the service worker does almost nothing, just get the bundle and for push notifications in Chrome.

I dont remember what else we had to do to get PWA working, but it was a couple of hours of work. I was tempted to create a package for this, but not having the app working offline hold me on that.

1 Like
#12

Hi,

thank you for your inputs and will be looking forward to enjoy your contributions on the “official” documentation. I don’t expect V1 to be clean and free of mistakes, misspells and confusions but as more users try to read and implement it, things will get explained better and better.

As far as I know there are three different Push packages for Meteor: RAIX, Rocket.Chat and Activitreee:Push. I think Activitree:Push is the only one that fully relies on Firebase Admin SDK for Notifications instead of using 2 different services (one for IOS and another one for Android).

I will write the Push Notification for PWA in direct entanglement with Activitree:Push while I will maintain compatibility with the other Push packages (if they support WebPush).

“I’ll be back” in 2-3 days with a first draft.

Thank you

1 Like
#13

So there is no way for push notifications that completely works without vendor lock-in?

#14

@jkuester What is a vendor lock-in in this case? I mean, where do you perceive a locking?

#15

Ideally, the package is a minimum structure that checks the minimum requirements for a PWA.

On top of my head, this will include the basics of handling the basic events like install, fetch, and activate.

Then maybe the rest are through extensions or plugins. This part should include things like:

  • handling custom install prompt
  • handling push
  • handling data caching outside of Meteor assets
  • etc.

So this can give enough options to the developers on how to go about these parts which most likely is different for each application

#16

“these parts which most likely is different for each application” - perhaps this is why a documentation/tutorial is required and not a package.

#17

This was a helpful read for the install prompt process:

#18

Because I’m personally focusing on a Vue + Meteor app, that is how I’ll be implementing some more PWA features ideally to get the very desirable “install” option in Chrome. This is a really nice tutorial that is helpful to read when exploring this implementation. No need for Auth0 with Meteor’s accounts packages obviously, but the rest of this tutorial is pretty relevant. It recommends a webpack plugin which would even be possible with Meteor, as many people have successfully added webpack to Meteor, although there are other ways of achieving this.

If anyone is building their own PWA implementations on Meteor, this would give you some things to think about.

If anyone working with Meteor & PWAs has time to look at this, it would be cool to get your thoughts on what parts you might consider keeping and what parts you would ignore.

#19

I keep finding more great stuff on PWAs and the packages that are powering most of the PWA apps out there. I had been drilling down a little on the Service Worker (SW) options and found another Node.js SW solution, which does seem like it would be an ideal way to build a service worker for Meteor.

Google made a package on npm called workbox-build and it seems to do most of the heavy lifting, and is of course the most popular way to accomplish these tests at the moment from what I can tell, with over 2 mil npm download per week.

@jkuester would you mind taking a look at this package since you’ve got a good handle on how Service Workers might need to work with Meteor from the tutorial your wrote?

I’ll be trying this out soon on my project, but it would be great to see what everyone thinks of this approach.

Tag anyone here on the forums that is the most familiar with the Meteor build process to comment on how this workbox-build npm package might work? It has Babel dependencies, so to me it looks like it would be nicely compatible :+1:

3 Likes
#20

We looked at the Workbox in the past and I believe it was @jkuester who suggested we should do it clean without further dependencies on other technologies.

1 Like
#21

I think it is an in-between case. Some parts of Meteor bound to certain techologies (for example WebApp uses the connect api) and this should of course be reduced to a minimum.

I have not gathered an audit on the workbox packages to say how heavy this would couple us. However, I know from google, that they tend to let projects fall from one to day to another, making long term maintenance pure horror then.

On the other hand I see great potential in what workbox is offering and I think it should be discussed with Tiny (cc @filipenevola) which path this whole out-of-the-box PWA integration should go.

1 Like
#22

Hi,

the first draft for implementing Meteor PWA with Push Notifications and Offline pages is here: https://github.com/activitree/Meteor-PWA-Explained.

I tried to detail as much as possible on every aspect. Looking forward to your corrections, feedback, suggestions etc.

5 Likes
#23

Nice work @paulishca. I still need to wrap my head around the caching of the bundle but I am learning a lot

Some questions/feedback:

  1. Why are you calling self.clients.claim() for every fetch? It should be enough to call this on activate

  2. Better to handle PUT and POST event methods on fetch as only GET methods are being cached

  3. Why handle the fetch for robots.txt, sitemap.xml, etc. which is fetched by 3rd party systems from the server and not the service worker?

#24
  1. What will happen to sockjs requests?