What do you expect from your Meteor PWA (Draft here: https://github.com/activitree/Meteor-PWA-Explained)

pwa
1

Hi,

Later Edit: a documented example was provided here: GitHub - activitree/Meteor-PWA-Explained: Demonstrate the use of PWA and service workers in Meteor 1.8+ Project

recently there were various discussions including the PWA subject.

We (or I) know so far that some people just want to pass the Google audit while others desire complex features that are otherwise found in mobile apps where having a local DB and a sync management is feasible). Among these complex features, I’d mentions offline methods, over cacheing of assets or data.

I have recently worked out a decent PWA config with offline experience and Push notifications (where supported) and I was curious to know what other developers need in a PWA and whether they were able to work out a proper configuration that works for them.

Would really appreciate if you could take a minute to answer these:

  1. Do you want to implement PWA but couldn’t find a right way?
  2. Are you fully satisfy with your PWA? What features do you use successfully?
  3. What did you want to implement in your PWA but didn’t manage to do it?

Your answers would help me to start writing a manual/tutorial on this subject.

12 Likes
2

First, I really encourage this initiative and I’m willing to help in getting the PWA section in the Meteor guide as I believe it will be a dominant force in mobile app development in the coming years and it is really a good fit with the Meteor ecosystem.

For those who don’t know, PWA is what mobile apps were supposed to be when iPhone was introduced by Steve Job, here is a video of him introducing PWA back in 2007 and it is exciting that is finally catching up.

I’ll share a few thoughts on top of my head regarding my experience with PWAs.

  1. Don’t use responsive design frameworks when creating PWA apps, instead split the web desktop from the mobile. We tried bootstrap, it was very limited, and the best framework to get the job done was MUI, we used React MUI and the users can’t tell it is a web app, other options are ionic framework and Framework7.

  2. The add-to-home screen is the first thing that users want to do when you give them the link. Android handles that by default for iOS, we have used this NPM library to guide the users.

  3. The icons can be generated using the following NPM library. With Meteor SSR, we were able to make the icons customizable from admin panel, we generate the manifest file dynamically.

  4. When we wanted to scale (i.e public-facing pages), we used a static site deployed on a CDN (surge.sh) with SimpleDDP to connect to the backend. We’ve built our own version check using DDP that auto-update the app (push update and refresh the app). We’ve also create React components to manage the real-time connection and handle disconnects. Our experience with SimpleDDP has been very smooth.

  5. We had some issues with iOS image capture with PWA which was recently resolved by Apple.

  6. We had issues with large lists on slow mobile devices, and it was resolved by using React Virtualized list. The combination of Meteor sockets and react virtualized created an infinite scroll that is faster than any native app I’ve used. It is just beautiful to see, you can scroll thousands of rows without a drop in performance with a very low-end mobile device.

Overall, I’m convinced that PWA is the future of mobile apps development and potentially also desktop development (since you can add them to desktop as well). However we’re currently missing two things:

  1. Notifications (I know it is possible on Android but not iOS (i.e the new IE).
  2. Offline support (we are exploring this once we indemnity the critical use cases in our apps).

I hope that helps!

13 Likes
3

We would like to have as little as vendor lock-in as possible and try to focus on what’s possible with the open standards. Besides that we also have a separate view for the mobile which we realized using dynamic imports.

The offline and syncing is on the todo list but is not an essential use case for now.

I personally prefer a flexible solution that is long term viable before an easy solution.

Regarding the lighthouse testing: I focus on lighthouse as the minimal requirements test. Beyond that there is of course a lot more to achieve for a pwa.

2 Likes
4

I’ve recently just learned a bit more about the progress & potential of PWAs, I know Google has done the most to advance them, and it sounds like Microsoft too. Maybe I didn’t notice this trend because I’m an Apple (MacOS & iOS) user, and it seems Apple has been the slowest on adoption as it might impact their future App Store the most, but I think there are a lot of advantages to having apps that are not controlled by the rules of App Store, it gives users more freedom. And I didn’t realize even Apple is allowing the apps to run more like a native app than a browser app added to the homescreen.

Anyway, now that I recently get that PWAs allow for desktop apps in addition to mobile apps, in my mind it puts them ahead of Cordova & Electron, and even React Native because that is two integrations that I have to work out.

I’m not sure if I’ve just been coding in a hole :hole: but for some reason acronyms never make me excited about things, haha, so PWA when I looked at it just looked like a “standard” before, and I dismissed it as something I didn’t care about for now. My user just use the our web app on desktop & mobile, and it is kind of an amazing experience just in the browser. I assumed I would get around to Cordova, and then Electron because those had so much history of being the primary routes.

The way “users” will describe apps is just a “Desktop App” or a “Mobile App” or a “Web App”, so I guess it might be cool to call things “Meteor Desktop PWA” or “Meteor Mobile PWA” or “Meteor Desktop & Mobile PWA”. I’m usually pretty quick on noticing trends and I missed this one, maybe because Apple seems pretty quiet about it and doesn’t even call this a PWA in their docs yet?

For me, the ideal PWA implementation would make both desktop & mobile versions of PWA implementation a breeze. This is the Meteor style.

I also use Vue + Meteor, so a solution should probably accomodate any of the most popular front-ends. Vue’s CLI actually has a PWA option to choose form when users create new apps, which does make it super easy. For Meteor, it would be ideal as an atmosphere package and would probably work over DDP (for most) and HTTP (for some users who use Apollo & GraphQL over HTTP).

My core features I care about with a PWA would be the desktop & mobile app installs and notifications as a 2nd priority. The basics to add to a Meteor app to support a PWA seem pretty simple.

I’ll be doing more research on all this, so thanks to everyone working on making this better! And raising the awareness about it :rocket:

3 Likes
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:

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:
https://www.netguru.com/codestories/few-tips-that-will-make-your-pwa-on-ios-feel-like-native

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

2 Likes
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