Stack Evolution

Our meteor application history (in a nutshell)

• Bundlin (NodeJS REST Angular)
• Part-up (Meteor DDP Blaze)
• "Intranet" (Meteor DDP React)
• "School" (Meteor GraphQL React)
• "Course Planning" (NodeJS GraphQL React)

Bundlin

(NodeJS REST Angular)

a.k.a.

"First time javascript only"

Bundlin

(NodeJS REST Angular)

👍

• Javascript in front- and backend
• Large focus on frontend application
• Heavily cached API endpoints

🚀

• Too many package decisions
• Large initial setup for deployment

Part-up

(Meteor DDP Blaze)

a.k.a.

"Cutting edge realtime data"

Part-up

(Meteor DDP Blaze)

👍

• superior development experience
• "opinionated" framework
• notifications and realtime chat were a breeze
• launched app on existing DDP API's

🚀

• heavy subscriptions (loads of data)
• harder to scale, maxing CPU's

Intranet

(Meteor DDP React)

a.k.a.

"Reactive everything in React"

Intranet

(Meteor DDP React)

👍

• ES6 from get go: imports & npm
• React simplified ui state handling
• again: great platform for notifications chat
• running elasticsearch and mongo in docker

🚀

• deployment with fusion passenger

School

(Meteor GraphQL React)

a.k.a.

"API design on steroids"

codename: School

(Meteor GraphQL React)

👍

• GraphQL/Apollo -> request efficiency++
• GraphiQL automatic API documentation
• API definitions by frontend team
• Dataloader caching

🚀

• Heavy meteor builds -> 2gb box required
• No built in realtime data

codename: Course planning

(Node GraphQL React)

a.k.a.

"roll your own 2.0"

codename: Course planning

(Node GraphQL React)

👍

• Control over build / compile time
• Still using apolloclient
• Closest to nodejs release cycle
• Dataloader caching

🚀

• diy accounts / hotreload / dev env
• docker images for node and mongo

Considerations going "vanilla" Node

• Team maturity
• Necessity for "opinionlessness"
• ...insert to be discovered missings here...
• Apollo the way for Meteor and NodeJS to reunite