Help me out on non-Meteor architecture

This ain’t no ‘bye bye Meteor’ post, but I’m looking for ideas regarding a non-Meteor stack.

TL;DR How would you build a super SEO friendly, mega scalable blazing fast site combining lots of both static and dynamic content, with the necessary hooks into the Meteor apps, such as login state?

I’m overwhelmed by different possibilities right now.

I have a fairly complex app, split into three different parts. Two of them are Meteor apps, which basically have their own user “types” with entirely different features, available for registered users only.

The Meteor apps are quite loosely connected, mostly by sharing the database and the same Messaging-component, so the users can send in-app messages back and forth to each other. Nothing interesting in these apps, developing in Meteor-land is nice and easy :slight_smile:

The third part (which I’m asking help with) is more like a traditional website, if you will, where I’ll mostly have lots of static content, such as a front page, blog posts, articles, intros, tutorials etc… but it will also have a way of listing and viewing different types of content created in the Meteor apps.

Meteor was the perfect solution for the other two apps, but this part of the site is public (everybody can browse&use) and very important to be indexed by bots properly, so I’m going to skip Meteor on this one (also because of Meteor’s initial loadtime and heavy bundle size).

Basically this is the first time in over a year that I’m seriously studying my alternatives besides Meteor, Blaze and ViewModel, so suddenly I’m drowning in different possibilities.

My current master plan revolves around this type of thinking

  • Use a static site generator, since lot of the content will be blog posts, articles etc, maybe Hexo?
  • Make some pages dynamic, since I need to list items, search items, show detailed views of items, show login status for users who are logged in to the Meteor apps. Vue seems nice!
  • …but since it’s SEO critical, I need SSR!
  • Vue has that. Nice!
  • …what if I exchange Hexo to Metalsmith and connect my database to the build process, so all the listings and item views could be pre-rendered to static HTML pages, maybe nightly? It doesn’t necessarily have to be “instant”.
  • …I still would need Vue though
  • This is getting complicated :confused:
  • Vue does have caching of SSR components. Maybe that could work easy.
  • I really like the idea of Svelte. I wonder… Ok I’m getting lured by the new fancy thing, beware!
  • Control yourself! but…Apollo???
  • …endless monolog…
  • So, if I started now, I would build my static site with articles, blogs and whatnot with Metalsmith or Hexo, then I would have my (mostly) server-side rendered Vue app that relies heavily on caching, and they would be combined to a seamless experience in a not-yet-decided fashion.

So the stack would be: Vue+Express+SSR (cached) and Metalsmith for pure static pages.

This is where my flow of thought stops, trying to figure out the best way to attach these two together in the most sensible possible way. I’m also troubled that I can’t figure out any alternative solutions.


How would you build this? What would your stack of choice look like?

Thanks for reading this far :slight_smile: I chose not to post this under the Vue-topic, since I’m interested in hearing other ideas too.

sounds similar to some project needs I have. We have a Meteor app (actually two which share a database) and need to build a product gallery with data coming from Meteor database.

What I’m planning to do is to use contentful. Meteor will push data into contentful, then we can use contentful’s free, web-based admin tools to edit things. Saves will trigger a static site build process (probably costed on Netlify). We are looking at Metalsmith–you create a pipeline of chained JavaScript functions (like get data from contentful, add meta data, create header, etc.) there’s already a plugin for contentful. Bolt on elastic search for a richer user experience…

Is sounds like we are on the same page, but you’re missing Netlify. You don’t need SSR, let Netlify do the build and caching for you. It’s an ultra performant platform for static sites, featuring:

  • Global CDN
  • Ultra Fast DNS
  • High Availability
  • Atomic Deploys
  • Instant Cache Invalidation
  • Security
  • Scalability
  • Automation
    Oh did I mention free one-click SSL, form submission hooks and GitHub integration? more features here

Thanks for an interesting reply!

I’m trying to replay your idea with my own words, so, in a nutshell:

  1. Specific changes made in the Meteor app cause inserts or updates to data stored in Contenful (which might be a somewhat synchronized subset of data in your MongoDB?)
  2. Contentful has event hooks, which trigger a rebuild on Netlify every time data changes (or maybe when you manually choose to trigger it from admin tools?)
  3. Netlify then begins a build process, maybe using Metalsmith or something similar, that will pull the data from Contentful and render your static pages and deploy them automatically.
  4. Repeat the process when a new change emerges from the Meteor app

Am I right?

Some questions:

  1. How many pages are you going to be rendering?
  2. Are the pages completely static HTML, or will you be fetching data via AJAX?
  3. What is the benefit of Contentful (besides a trigger hook), doesn’t it just duplicate your data and cause sync issues? Or just that it already has a plugin for Metalsmith?

I’m very interested to hear more.

My initial idea was to do the builds “almost” manually, maybe nightly, and just pull the data from my Meteor database into Metalsmith.

Then I read about everything nice in Vue, such as SSR rendered component caching and client side hydration and got all excited.

Netlify seems like a robust solution for static sites, not too expensive either. It also seems to have pre-rendering for indexing, which could work wonders with Vue, not having to dance the SSR-caching-hydration dance :slight_smile:

my comments in-line bold:

Specific changes made in the Meteor app cause inserts or updates to data stored in Contenful (which might be a somewhat synchronized subset of data in your MongoDB?)
yes, basically. We run a proxy buying service. Requests for new products come into Meteor, and we’ll push them over to contentful (product link, name, price, etc.)

Contentful has event hooks, which trigger a rebuild on Netlify every time data changes (or maybe when you manually choose to trigger it from admin tools?)
that’s right. For a more simply static like (like our home page) we commit to master branch in git which triggers Netlify to rebuild–I can fix a typo on the site using the CodeHub app on my iPhone, save the page and BOOM! a new version is deployed. You could also have a field like status: [draft, publish] which Metalsmith could use to filter i.e. don’t publish draft posts. We might want the new product to sit in a queue until an editor approves it, i.e. so we can filter out adult products for example.

Netlify then begins a build process, maybe using Metalsmith or something similar, that will pull the data from Contentful and render your static pages and deploy them automatically.
yup. marvellous isn’t it? Here is how we run the build process for a simple Semantic-UI site

How many pages are you going to be rendering?
hundreds per month, so a few thousand per year

Are the pages completely static HTML, or will you be fetching data via AJAX?
we plan to use Elastic Search. I haven’t used it before, but I know a guy who used it for a static site for car parts whom I’ll consult. Will probably also have Disqus comments, but otherwise not a lot needs to move around. Here is a cute library client side javascript widgets you can drop into a static site :wink:

What is the benefit of Contentful (besides a trigger hook), doesn’t it just duplicate your data and cause sync issues? Or just that it already has a plugin for Metalsmith?
OK the best question last. By pushing the data over to contentful we don’t need to build a whole damn content management system. You get a pre-installed admin control panel which supports multiple users and roles (like author, editor, publisher), and it supports image loading, and it will dynamically change to adapt to changes in your data model. It would be a lot of work to write all that. So Contentful is a more flexible content staging ground. You can push the data into it, then have an editor review and augment it (add category tags, upload images, then publish. But I don’t fully know your whole model, maybe your data is much more volatile? Or maybe you already created the Admin tools?

Here is a peek at how sophisticated your Contentful model can be:

a closer look at editing components:

roles and permissions? check.

I haven’t built my site yet, I’m still in planning stage, so please do your own due diligence, but maybe we can learn together and share tips!>

What’s holding me back is that I want to use Semantic-UI-React components for the UI because it’s friggin awesome. Gatsby is a static site gen which utilizes React and supports no-refresh page transitions which is interesting to me, but I feel like Metalsmith is superior is other ways. Perhaps I’ll just go with Metalsmith and later try and figure out how to implement some kind of gatsby style router.

Thanks for clearing those questions for me!

I’ll let these ideas sink for a while and get back to it, since our requirements really are quite similar.

In our app, some users will have a “storefront” they can edit with images, texts, articles etc. that can be browsed and viewed. There can be thousands of these profiles, which can also be listed and searched. I’m trying to fiddle the static site idea into the picture somehow, but I’m not sure if it’s possible since they can make lots of miniscule edits on their profiles, and there can be thousands of profiles :slight_smile:

Regarding Semantic UI, I did try it and initially like it. Having used it extensively, I am now trying to get rid of it.

Reasons:

  • The creator of SUI is really taking some liberties in how he wants to define layouts, which doesn’t always end up nicely, when everybody else plays by the rules
  • It’s not really properly designed for mobile UX
  • Some components just don’t work properly or tend to break everything, like the sidebar
  • Customizing it can be a pain, as well as overriding stuff
  • Quite heavy
  • Too often I would spend lots of time trying to bend a Semantic UI component to my specific need, when writing a similar component from scratch took me 10 minutes.

SUI was however very useful and fast for creating a nice admin tool for us, where we didn’t care for the looks that much (no customizing), our needs were quite standard (we basically built a dashboard) and we didn’t care for mobile UX.

I agree to a point about some of the Semantic-UI gripes. I encouraged Jack to make mobile components, but he shot down the idea feeling it wasn’t appropriate for the framework. As far as customization, you can do anything, but it does have a moderate learning curve. To demonstrate it’s power, here’s a github clone (UI only) created in SUI:
http://semantic-org.github.io/example-github/

Good luck with your project! sounds like a big job!