Do we see Meteor moving to adding PWA support with manifest and web workers,
maybe where it can switch from DDP for live data to polling with Web workers.
Adding the Manifest.json shouldn’t be to hard, but added all these features for a standard project, could be the boost meteor needs to start getting ahead of the competition and securing a place.
I see this as a new driving force for Web apps and Meteor in particular, to really bring value as the app stores are driving out apps, this is the return of the web and web development a new boom to close out difficult native apps to instant and always available web apps.
I’ve built PWAs on Meteor before, mostly using statically generated manifests and service workers, and offline packages like appcache (which needs updating) and ground:db. It works pretty well.
I have a custom data flow, where I feed my views directly out of Ground:DB instance on the client, and directly out of server mongo sources on the server in SSR. Data is delivered over methods (except when there is hydration data), with a custom (and relatively stupid) syncing algorithm (it just grabs new pages of data on component mount, and throws away anything no longer on the server). I don’t bother with pub/sub for performance and scale concerns, and because of that I don’t do any of the fancy syncing with Ground:DB. In order to deliver separate mongo sources in different contexts (server/client) I put all that in a package.
The only caveat I found with it is that there is a slight delay from when the app starts and Ground:DB is really ready to go (but only sometimes). You also have to be aware of the limitations of mini-mongo - such as there is no text index client side, but that’s normal for isomorphic queries, and not specific to Ground:DB. Everything else about it works normally.
I also do a kind of pattern - I call it a connector pattern. Basically, any kind of data container is a connector - withTracker, withState, etc. I set those all up in a folder called “connector” and reuse those all over. They can even be set up to use a Provider for efficiency, though I usually skip this step. (I suppose this is just the “container” pattern renamed, but now it also contains hooks built on useTracker, so I’ll keep using the label.). These are all functions which are used to wrap a component (or used by a component in the case of hooks). I try to make these fairly generic, so they can simply be reused where ever I need them. The data package I described above has a utility function, which let’s me pass a set of functions like a query, a collection, a tracked function, etc, and then it does all the glue to make SSR, data over methods, data hydration, offline first, etc. all work with very little effort at the connector level. I’m going to release that package fairly soon.
I’ve been doing CRA frontends that connect to a meteor/apollo backend (everything over graphql no DPP or meteor code in the frontend). This has worked out really well.
Although people should also consider firebase auth + mongodb for data + node/apollo-server. With mongoose promises, it’s similar syntax to meteor and its fibers.
With accountJS, is there a way to get the userId of the currently logged-in user on the client and on the server? I also wonder if there’s a way to get the userId into the context param in Apollo resolvers – although that may be a question for its own thread.
I’m working on a medium article for setting up graphql/create-react-app/apollo-server and accountsJS. I’ll try to speed up the release of that… the docs are lacking a little.
