Lucas, that’s amazing to hear! Now, I guess we can all be at peace, and resume building the apps of tomorrow.
1 Like
Great thread and a joy to read.
My business partner and I have two Meteor apps in production (the first is one-year old and the second is closing on three). I doubt either would have been feasible without Meteor in terms of overall speed to market Meteor brings. Specifically:
- Meteor’s built in Auth over the full stack makes it less challenging (I hesitate to say easy because it feels like I’m jinxing things) to develop secure applications
- Pub-sub is a joy in terms of development speed as well as the ‘AHA’ it brings clients when they see real-time in action
- The first-class integration with Mongo so you’re not faffing about with configuring the database
All that said, we are about to start a project and will spend 1-2 weeks experimenting with AWS-Amplify (using Appsync for the db stuff, Cognito for auth and Lambda for server side logic). Whether we ultimately go down that path or not will depend on our experience with it, but what we are hoping for in terms of upgrades to the Meteor experience:
- While the Meteor rebuild time when you make a save to your project has gotten better, it is still a far cry from Create-React-App or Gatsby. I didn’t quite appreciate it until working on Gatsby where the rebuild is done and your page refreshed before you can switch to Chrome. It’s quite fantastic (don’t know if that’s just me)
- The testing eco-system is miles ahead. And a question for @illustreets , @veered and anyone else - are you able to post a quick 2-3 line summary of your automated testing procedures on your production apps? I.e. - Tools you use, pros and cons/compromises you have made on this front
- The serverless benefits - no need to get into the details of these as I’m sure anyone near the industry has had multiple articles and hype shoved down their throats. We want to try it in practice and see for ourselves
Tl:Dr: No plans to ditch Meteor for our production apps, very happy with it overall, but continue to experiment with others.
3 Likes
This is a great choice of stack. Are you planning to use DynamoDB for the db? I have a experience with it, the API is an absolute disaster, compared to Mongo its 10x verbose, complicated and not flexible. But you don’t need to worry about servers etc.
Serverless is the way of the future IMO. And it will end up being cheaper for the vast majority of cases too.
1 Like
Heh that is the feeling I had the one time (a year or so back) when I looked at the DynamoDB documentation. Like with most AWS documentation, finding stuff is a nightmare, though that said, the Amplify documentation seems much, much better: https://aws-amplify.github.io/docs/js/api (amusing side note - they’re using Algolia to power their documentation search vs their own elastic search).
But yes, we are planning on experimenting with DynamoDB, in spite of its inferiority compared to Mongo. Reasoning:
- Using Appsync, most of the crud operations will be via graphQl rather than calling the Dynamo API’s directly
- First class integration with the Amplify stack means things like Auth can be automatically configured via a directive when defining the db schema
- They have a serverless pricing tier (not a huge deal for any b2b apps, but would be very useful for side projects where a few projects can quickly add up cost)
1 Like
We were very early adopters of Meteor (we had apps in production back on Meteor v0.6!) We still have a few apps running, but we are working to replace them with a new stack. We are doing all new development with Vue.Js, Vuetify, GraphQL and Prisma. And producing static sites with Gridsome (a Gatsby-like static site generator for Vue/GraphQL). Meteor was great a few years ago; wouldn’t recommend it today.
Vue shits on Handlebars.
2 Likes
Max, you’ve been around for a long time as a Meteor user. It would be nice to hear why you think Meteor isn’t great today anymore.
Perhaps I’m wrong, but I remember from one of your older post that at least one of your apps was pretty much static. Surely your current approach is much better, while Meteor would be overkill for something like that.
EmberJS took handlebars (GlimmerJS, the orange one) and made it faster than react and preact. Here is a chart showing Glimmer bundle size when compared to other frameworks:
And according Linkedin it’s also faster then preact when doing SSR, so it has a good fan base.
With regards to Prisma, I personally don’t recommend it yet until it passes the hype curve. I know many folks who got burned with hyped backends (RethinkDB, Parse, etc.) although they’re both not “dead” but they’re not doing well either.
But you’re early adopter and I guess a risk taker as well, so good luck with that transition! and hopefully you share some blog posts about it.
2 Likes
Then again this is a set of totally proprietary services resulting in a complete AWS lock-in. That may be totally acceptable for you, but it’s quite apples & oranges to compare it with Meteor.
2 Likes
I remember how impressed I (and the entire room) was at Meteor night when you presented it. It would benefit Meteor to have awesome use-cases like these being published in 2019. Glad to see it’s still going well for you guys!
1 Like
Thank you, @seba! You brought back some really nice memories. Our first time in SF, and obviously first time at the Meteor headquarters. Had a great time afterwards too.
Right now we are up to the neck into a major upgrade, after which I should come forward with something public, including blog posts. It’s gotta be.
5 Likes
What type of server backend are you using?
We have an app (online school for kids) with personal cabinet, realtime chat, video chat, schedule’s related features, reports, internal tasks tracker etc. It was developed by 2 devs in ~14 months. 8 of them in production.
100CCU on 2 x 10$ DO droplets with ~5% CPU load and 250-300mb RAM load each.
I wrote an article about our project on habr (in russian).
In short - its amazing tool for us 
. We have a high speed development, a short release cycle.
Sorry for my bad english 
6 Likes
That’s very true and definitely a point of consideration. The one thing that swings it, with AWS being the proprietor, is that we can rely on them not running into financial trouble and abandoning these tools (hopefully that’s not a misguided expectation on my part!)
1 Like
You must’ve done your calculations and accepted the risks, I’m sure. But I, for one, cannot understand a cloud based business that doesn’t choose to have the freedom to be on any platform it wants, whenever it wants.
Personally, I believe that the relatively small DevOps investment in making that happen is more than paid off by the freedom it offers. And the DevOps stuff needed for Node.js and / or Meteor is ridiculously simple.
Case in point. A large client wants an ‘on-premise’ type of installation, dues to internal data protection policies. So they are ready to pay you top dollar to deploy in their own private cloud. Which is on SoftLayer…
Another case. You have a chance at an early exit, because a larger player wants your stuff, and they’re happy to integrate it with their existing software. But said acquirer is on Azure. And that might limit your hand in the negotiation, because, well, they need to spend resources on converting your software.
These being said, good luck and let us know, at least briefly, how did the experience compare to that of developing your previous apps.
2 Likes
We’ve been using Meteor since v1 and have two production apps running for a couple of years now. Very solid and reliable. I was new to web dev when I started (coming from games) and I have to say that between Meteor itself being pretty sweet and the help and advice from all of you on this forum that it’s been a great experience. Obviously I’d change a few things if I started again but Meteor wouldn’t be one of them.
Here’s hoping that MDG find time to invest in it again, but failing that I feel pretty secure with the commitment from Lucas & Qualia. I couldn’t think of anyone better 
4 Likes
We use Meteor to create online social simulations which are technically real-time multiplayer (10-20) browser games. As the only programmer in a team, I can’t imagine our work without it. We will definitely use Meteor in the foreseeable future, no matter how “dead” or “alive” it will be, because in its current state it already fits our needs perfectly.
6 Likes
We make online simulations too! But we simulate student groups running companies in competition against each other. We have hundreds of students using the service daily without any issues, and developing with Meteor has never been better IMO.
5 Likes
Unfortunately it is designed and licenced for educational institutions and doesn’t have a single player option yet 
.
3 Likes
It is really interesting to see lots of educational / classroom software written in Meteor. I think Meteor has the perfect value proposition for the realtime requirements of classroom interactions.
Are you using it as part of your research? If so, are there already publications?