Starter Kit with Meteor 1.8, Apollo 2, React 16, Multilingual support, PWA, SSR, Authentication & Styled-Components

For those interested, I’ve just released a starter kit which features a number of desirable features when creating a new Meteor project:

  • Apollo 2 GraphQL server running with Express bound to the Meteor (1.8) app
  • React 16
  • Multilingual support (using react-intl) with dynamic loading of required locale messages
  • Authentication: password & facebook (via meteor accounts)
  • SSR with support for an app-shell specific route
  • App-Shell based architecture with dynamic loading of required components
  • Styled components
  • Recompose
  • Jest & Enzyme for testing
  • Storybook
  • sanitize.css
  • basscss
  • basic admin functionality via alanning:roles
  • Code splitting on startup and router level
  • Progressive Web App features

The kit is based on the excellent work done by excellent work done by Federico Rodes, however it’s since been heavily modified to provide a more recent base as well as server-side rendering.

I’m happy to have other people propose changes and improvements to try to keep this starter kit up-to-date with updates to Apollo and Meteor.


I’ve just released a huge update in order to add Multilingual support. It’s best to think about internationalisation from the start of project, so it’s now included in the kit. I’ve updated this pose to reflect that.



Great work! Would also be great if one could submit an issue to that repo.

With regards to service worker and saving to homescreen, I’m looking to pull just that bit out of the repo for an existing app that doesn’t use SSR.

I see this in the code regarding the route:

  // /app-shell is a special route that does no server-side rendering
  // It's used by the service worker for all navigation routes, so after the first visit
  // the initial server response is very quick to display the app shell, and the client
  // adds in the data.

  // In the case of a first visit or a robot, we render everything on the server.

  if (sink.request.url.path === '/app-shell') {

How should this be handled for non-SSR apps?


I’ve enabled issues.

The ssr.js (and the corresponding import) can just be removed if you don’t need SSR. You should also remove these lines from the service worker:

// Cache the App Shell route. We try to get latest from the network, fall back to cache for offline.
workbox.routing.registerRoute(APP_SHELL, new workbox.strategies.StaleWhileRevalidate());

// Our App Shell, used by all navigation routes.

This looks great :100:. I look forward to trying it out!

1 Like

Sorry, I won’t use it. Already out of date. Need to update to Meteor 1.8…

(just kidding!! nice work!)


Damn, that looks very good.

I’ve come to dislike redux + meteor for state and data management. It works fine, but lots of overhead. Apollo seemed good in that regard.
Styled component was the last library I tried for CSS, and I love it.
App-Shell based architecture fits perfectly my use case, I was intending to add the dynamic loading soon.
PWA, SSR, all good stuff.

How easy would it be to remove some of the features/packages, like alanning:roles and authentication ? I’ll check for myself in a few days - I might use your starter kit for my project - but I know these 2 will have to go.

It’s always dead easy to remove stuff.

The idea is to take the starter kit, remove what you don’t like and go from there. It just gives you a working basepoint.

1 Like

This is absolutely incredible. Learning a lot of new tricks and techniques simply by looking through it. Thank you for your efforts!

The kit is now updated to Meteor 1.8 :slight_smile:


I’ve cloned the app, followed the instructions and started the meteor app. It opens and I can login, but the “new version” alert shows up every time until I click “cancel”. If I refresh, it shows up again.


This sounds like a problem between the service worker and Meteor’s auto-refresh. If you can track it down that’d be great. If not, try removing the service worker registration for the time being, by removing this line:

import('/app/ui/register-sw').then(() => {});


I’ve just released a huge update in order to add Multilingual support. It’s best to think about internationalisation from the start of project, so it’s now included in the kit.



This starter kit looks great!

Though could you add Data sources, Subscriptions and Reactstrap?


Those are not things that every app will need, so they don’t really have a place in a starter kit IMO. It should be easy to use the starter kit as the base of your app, then add what you need.

1 Like

I’ve fixed (I hope) the infinite reload issue.

1 Like

For a starter kit Reactstrap would’ve been simpler than styled components. Would you disagree?

It’s great that important features like multi-language and SSR have been implemented, But the code generally appears quite a bit more complex and convoluted than what may be expected from a starter kit, making it more difficult to reason and work with. So I’m wondering whether the complexity is necessary, best-practice, or worth having. There are already over 140 files even though it’s meant to be a skeleton with almost no functionality.

I’d be interested to know others’ experiences of using this starter kit.


I think it’s reasonable to say that it’s not a starter kit aimed at beginners; there are already loads of those available.

The term starter kit might be a misnomer. It’s really the result of frustration when I was trying to find an up-to-date base for a full scale project. It’s a kit for relatively experienced develop to start a project from when you need the technologies that I’ve put into it. I couldnt find anything with all this stuff put together; putting all these technologies together takes time, the kit speeds up that process for you.

I’m curious to know what you find convoluted? If there’re are structural issues then I’ll be happy to address them. I’ve tried to keep the code as clean as possible but they’re is undoubtedly room for improvement.

As for styled components, they should be trivial for you to remove. There are only a few demo pages that you aren’t expected to keep. Create your own home page using React strap and remove the other pages. All that’s left to remove are a couple of related lines in ssr.js.

1 Like

At first I wondered why there was a need for so many index.js files, which adds extra steps in following code trails.

Then I tried to add a ReactStrap navigation bar component and found that I had to make modifications in many different files to do it. It wasn’t as straightforward as creating a new file with the component code and importing it to use it.

The index.js files are there so that you can import a folder. For example…

import { withSEO } from '/app/ui/hocs';

…will automatically import the file ‘/app/ui/hocs/index.js’. This is standard practise with ES6 imports.

I’ve no idea which files you had to modify for the navigation bar, but really the complexity or otherwise of the UI has little relationship to the starter kit. Adding new React component will be no more complicated than in any other project. The only real difference will be that I’ve demonstrated an AppShell design with a few top level components that get displayed quickly - you don’t need to keep any of it.


@tarmes looks like a really solid starter. Question: I am looking for starter for a react+meteor+mongo pub/sub project.

Would it be hard and make sense to use your starter and strip the “apollo“ side?