What’s the best way to handle landing pages for Meteor apps? Do you host it on a separate server, with the Meteor app under a subdomain? Or is the landing page a part of the app itself? What are the costs and benefits for either method?
For example I’ve noticed that Kadira hosts their app separate from their landing page.
If your landing page is just static content, I would recommend hosting it separately. No need to overload your whole app just because someone linked to your landing page on Hacker News.
What do you mean by you dont need to overload your whole app if someone linked to your landing page on Hacker news?
Every additional connection to a Meteor app adds some load to the server. If 99% of visitors are only looking to read your about page to find out what you do, you can just serve them static HTML on a separate domain, it doesn’t make sense to point them to your actual Meteor app.
Thanks @sacha. Yep that’s pretty much the main concern. For apps that serve individual pages, it’s no bother for the landing page to be part of the same server because only the portion that matters for the landing page is processed and served to the client.
But for a meteor app, the entire client-side portion of the app is served with every landing page request, even if 90% of it will not be used. And so if you’re experiencing a large influx of traffic from, say, hackernews or reddit, most of the traffic will just be people viewing the homepage and leaving (and by most, I mean > 90%). Should the rest of the app users suffer from that influx of home-page traffic?
And aren’t there stacks better built to serve static content than Meteor anyways (clearly I’m playing devil’s advocate here)? It would be great if more people chimed in on how they’re addressing this, especially for higher-traffic apps.
the initial startup time for a meteor app is a big problem right now because of the issues you mention where the whole app is transferred before anything shows up. arunoda’s fast render package is designed to mitigate that, but i haven’t found it much help.
a simple static site or SSG page is a much better option.
I think percolate guys rebuilt their landing pages in react so they can serve it up as a static page using SSR. this will also be better for SEO (if you have a bunch of landing pages, eg for different SEM campaigns)
Anything new here in the past few months? Is Percolate’s way pretty much the way to go?
Still it makes sense to just host it separately. I don’t think that will change pretty soon. It allows you to separate risk and performance in a very simple way. Next to that your web designers don’t need access to your app codebase which might be an advantage. And you keep your app as small as possible which is also an advantage.
Also you can even show if the app is down on your website when you have issues.
I don’t see a direct disadvantage of hosting it separately except when you would want a login form which is reactive inside the landing page. But that would make most of the advantages disappear anyway.
The biggest problem is having to deal with subdomains. When the site is advertised as coolapp.com, it’s confusing to tell them to go to app.coolapp.com or something like that to use the actual app.
In general that works quite well actually, a lot of systems work that way. You could even try to detect some kind of cookie and redirect to app.coolapp.com in case somebody seems to be logged in.
Also it’s nice because you otherwise need some way to switch between website and app. Since you want the website on / you get something as:
coolapp.com/ = website
coolapp.com/app/ = app
Then you almost got to subdomains already.
Which also goes into for security: Basic security with the subdomain can be simple: if(!loggedIn) redirect to login. With a mix of website you need to filter out the public website pages.
You could have Nginx serve your static assets (index.html) out of your Meteor /public directory rather then have Meteor open the socket for the app.
Also an interesting one! That keeps you with one repository.
For a landing page (just to present info and land conversions), just host a static site on an AWS S3 bucket, and slap CloudFlare caching on it. Done. Your app itself is at app.mysite.com, which people can get to from the landing page, or just bookmark it. I don’t think having the subdomain is confusing at all, personally.
Question: the sub domain approach seems reasonable, but what about Google analytics and such - can it track across, from the landing page to what the logged in user will be doing? this since usually you tell GA what domain you will be tracking . thanks everyone in the thread. Very helpful.
You can use multiple domains in GA. That is a supported use case. http://www.ericmobley.net/guide-to-tracking-multiple-subdomains-in-google-analytics/ see first point which mentions your question.
You can just put static HTML in your public folder and Meteor will serve it up. The only issue is you can’t name a file index.html 
I personally feel sub-domains provide a slightly dis-jointed experience if a user were to notice the difference but can see a case made for it.
I have instead implemented a sub-directory and the user is redirected based on path by Nginx.
I published the specific details for anyone interested:
How can I add login form in the landing page static html so that it makes post request to the meteor app?
I have to agree. We often assume that we ourselves are the end-users, but the reality is that the average user isn’t as tech-oriented as us. Little things like use of subdomains can make a big difference as far as usability. Subdomains are complicated for the average user to have to type in, for the same reason as a TLD that isn’t .COM makes your website more complicated for the average person who isn’t tech-oriented. Yeah you can do it, but there is a cost involved since it’s not what the average person expects to have to type into the browser. But if your user-base isn’t the average user (for example if your app is for programmers) then by all means tell them to visit app.coolapp.io instead of coolapp.com
This is something you can improve/worry about when your app is actually making money and you have 20 developers working for you. Until then, ffxsam is right… you have bigger fish to fry.
Of course if you plan to have 30k concurrent visitors that are just checking out your homepage from launch day onward, maybe it is worth thinking about now. Otherwise JUST SHIP THAT B%T$#!