Many people use Pub/sub it seems to be the default, every seminar I have been to for Meteor, every starter pack I have seen all uses Pub/sub.
In production, for static data such as a homepage, it’s really overkill as it’s slow and doesn’t work with SSR.
For that I have found WebApp to work much better, maybe I have missed something but I didn’t see anywhere yet where WebApp is a common practice. If anyone has anything to share on that I would love to hear
By using just webapp, you might as well just use pure node or express, no need to use Meteor at all. Meteor makes building web/mobile/desktop applications easy, and most I should think use Meteor for the benefits provided there. If you are making just a “standard” server-side rendered website, you are probably better off using other tools in those instances, it is not where Meteor shines, although it does work for that purpose as well.
I haven’t really tried combining the two usually, we have a separate application for our website based in Django, but maybe it could be a thing. Working with webapp directly is a pain though, as it is too low-level to be productive in I find.
Depends on what kind of application you are building. For example, if you were building a backend SAAS product, you could use Meteor login, methods, etc. for building a nice admin UI, and the webApp + express for the user-facing REST APIs. And if you are building a client SDK or static frontend app it can then interact with the APIs without needing to know about Meteor at all.
I use everything in meteor for that reason. I just can’t compete with load times of 3 seconds etc for pub/sub also there’s no way to cache a sub so I use ground, memcache and webapp. Express sucks and Meteor is far better. But out the box it’s really slow and doesn’t need to be, that’s why WebApp should really be the default in my opinion. The majority of database queries do not need to be real-time reactive subscriptions.
Really, you’ll never hit this in prototyping it’s when you go to production that it becomes apparent. Which is maybe why the starters don’t have it at all. Pub/sub is great when you need it. Although for loading static db data to for instance just populate a page SSR, it’s just overkill. So is oplog, memcache and webapp are underrated.
Yep I do use methods although it’s kinda slow to be honest, and of course it doesn’t work with the same performance as a simple json route from webapp, I think that’s part of the design really, webapp is surprisingly fast and bypasses my entire app to just the route from server/main.js. I launched a new embedded feature this week and it’s lightning fast via webapp. So I am migrating my other services from methods to use webapp instead.
The main issue for my development, is I need a static view of my data, and not a subscription. The client just needs to receive it once. And if that is sent with pub/sub it’s overkill and slow. I want to use meteor for my whole app, because meteor is good for work with npm and has a base package that’s mean you don’t start from scratch or have to spend weeks building your own stack. I can just get going and it kinda just works. The pub/sub is a great additional, although having an option to not use it, and just have a simple data retrieval protocol in place that can be client and server cached in the ram, is what production demands. After all PHP has done that since around a decade and a half. So no point taking steps forward if you also go backwards in other directions. If you get me.
I have, with great success and convenience. I use Meteor’s full pub/sub/method/optimistic-ui power for my web-app, but from the same app I use WebApp and onPageLoad (from the server-render package) to inject cached SSR landing pages for very fast first-paint times of my ‘static’ sales pages: Pre-rendered landing pages with Critical CSS
I’m using fast-render but didn’t try using with server-render, will check that out. Thanks man, I just want a instant load for my pages and not stuck on loading icon
One more tip; if you check the network for the static assets (fonts, images, sound, etc.) they are not cached in the client. This makes it easy to develop since you don’t need to worry about updating the assets. However, in the live environment, it is a network killer.
here is how I solved the issue (WARNING: when you need to update the assets, you need to change the name of them.)
const staticFolders = [
"/fonts",
"/images",
"/libs",
"/sound",
"/vr",
];
for (let i = 0; i < staticFolders.length; i++) {
const staticFolder = staticFolders[i];
WebApp.rawConnectHandlers.use(staticFolder, function (req, res, next) {
res.setHeader('cache-control', 'max-age=1209600');
next();
});
}
a better solution would be adding a hash to the files during the deployment and generating a map to access them in the client. But, the above example mostly does the job for static assets.
@captainn Is there documentation about adding SSR to an existing app for all UI routes? I am using react-router/react-router-dom with the following startup code:
That’s all good and you can run varnish reverse proxy also. For caching static assets afaik you should always serve them from a cookie-less sub domain to leverage browser caching effectively, as cookies obviously cannot be cached, and nowadays you can have a professional grade nameserver that supports geocaching, tier 1 asset routing, and webp, all of that is a flick of a button on cloudflare so you no longer need to do all the leg work. Previously I used to buy servers in East and west coast NA and one in EU etc, and setup varnish and do long hackathons messing around with imagemagick and all the headers with nginx and varnish etc and it was really good fun, but it isn’t 2008 anymore and all of this is available for $20 so I gotta be a boomer and just take the easy option, it’s also like 300ms to 1500ms faster routing, and I don’t need to call the NoC and ask for peering to be improved etc. So for this one I really recommend everyone use the pro service because it’s just better, and it’s not like you can save money by rolling your own on this, because this requires so much setup and you’ll never get the tier 1 routes they have because they are running all the big apps assets already, so it’s a good deal that’s incomparable. Give it a whirl I can assure that you really won’t be disappointed.
Yes, but I don’t remember where, and I don’t know if it’s all in one place. I have an old starter which may help though. You can see how to set up the client render here. Ignore the npdev:collections stuff. The main part for making data available data is to make sure you use FastRender.onPageLoad instead of Meteor.startup (This may have changed in the community version of FastRender to onDataReady). If you are using code splitting (dynamic imports) you’ll need to work out some chunk loading mechanism. npdev:react-loadable has a way to do that build in, but React.lazy does not.