If you were to stop using Meteor, what would you use instead?


#1

I have no plans to ditch Meteor, but I am curious (for you Meteor+React folks out there), if you were to stop using Meteor, what would you replace it with? What would that stack look like, if you kept React for your UI, but got rid of Meteor on the server side?


#2

Vue + Deepstream + Redis + RethinkDB + Auth Server + Apollo graphQL most of which running as docker containers behind an nginx proxy :slight_smile:

Seems a lot, but they play very well together with most of the things working out of the box thanks to deepstream connectors.


#3

Why would I restrict myself to React. :wink:

Never heard of it before but it looks impressive. And the whole stack sounds nice.


#4

I would like to know why they are leaving Meteor?


#5

I’m a big fan of React, and if I were to ever stop using Meteor, I would still absolutely keep that as my front-end.

Too true. :slight_smile: It’s really advantageous to have a single cohesive JS codebase for everything.


#6

All my new stuff is Elixir (Phoenix) on the server as a graphql API and then I use Apollo Client and React on the frontend. It’s been working well!


#7

I’ve actually been considering this just to learn more.

Build system - Webpack
View - React, React-Native, HOCs to share code between the 2
Data layer - Redux
Realtime - SocketCluster, DeepStream, FeathersJs
DB - RethinkDB (esp now its back and free)
Middleware - Redis for session cache and app cache
Auth - JWT

I’d have a completely stateless server (with session data in Redis cache) so it would be very easy to scale out, changefeeds from Rethink, and clients notified via Feathers/SocketCluster/Deepstream.

I didn’t add GraphQL here because I think its still too hard to write the actual server, and waiting for Apollo to expand more.


#8

One of the issues we are facing is too many pub/subs and problems when you have lots of data. Now this is not a Meteor problem but of architecting things in our code properly, but innn a framework where everything is reactive this is gonna happen.


#9

Vue + webpack + Golang + postgres


#10

maybe NEXT

Express

Depends. What are we building?


#11

do you do consulting? I got dozens of applicants but hardly anyone knows redux!


#12

Based on @ryanswapp 's recommendation, I’ve also been using Phoenix and Elixir for some projects. I’d recommend trying it if Javascript is your only language for exposure to something new. It’s really helped my Javascript!


#13

Because for most cases, Redux isn’t necessary. Why introduce new libraries or frameworks when you don’t have to?


#14

You might not need a lot of things, but there are reasons why you might need them too.

In my case former CTO (no longer with the company) made the decision to use Redux. He thought it added value but now I feel it slows us down. So I have a few options, like continuing development in Redux (which entails finding people with that skill set), converting it to Mobx, converting state managemt into to HOC, giving up and shutting down my company, etc.


#15

we faced the same issue, and fixed it by paginating the data published. If the user is going to see 10 or 20 records in a list, why would I publish 10k? if it’s a dropdown, autocomplete or a search input, send the text and only publish the first 10 records matching the text


#16

I’d use Next.js + Apollo


#17

I’ve already gone through this and for now I stay with MongoDB+ Express.js + Vue.js / Rakun.js (currently in development) for the frontend.


#18

I’d probably use morphine (to dull the pain).


#19

Could not realize just how much I love meteor until got a job offer from angular/express/gulpweb pack folks. I may have to change my stack for job, but as meteor finally ready to glance (grapher/redis/ssr/apollo/codesplitting/fast rebuild) once again, I see no reason to switch away.


#20

I probably wouldn’t use Node at all if Meteor didn’t exist. I’d try something based on C# or Go, or maybe Elixir.