@sungwoncho I’m just curious, what have you used for your backend part? Standard Express or something else? And yeah, It looks like such apps like yours and even Telescope app are not for Meteor. This is just my opinion. For example Crater.io is still very slow for me, despite all awesome performance improvements done by @joshowens
Honestly, there is where my head has been a lot lately. DDP is interesting and real-time seems like a cool feature, but I am not sure how often we need true real-time support, or if we are more after having a reactive front-end for some notion of slower than real-time updates.
3 Likes
To me, this is a bit worrying. Does this mean that Meteor isn’t fit for doing more traditional web applications at all? For example, how can you design your Meteor app to handle >500 concurrent visits?
@joshowens wow, much much better 
and yeah, you’re right… I tought about Meteor as a whole old stack, so Blaze, realtime everywhere etc., also as you’d said, we don’t need realtime everywhere, actually in such apps we need it in only few situations or even we don’t need it at all. The best would be to use React which is really simple to controll (reactive changes etc.) and also enable realtime only when we really need it in some of the app’s parts. So we could ask the question - why we need Meteor for that? 
1 Like
This also worries me. What is Meteor good for, again? It’s true that node and express have a steeper learning curve, but coupled with Mantra and React (maybe even Webpack) do they make a better stack than Meteor and React?
I totally agree with this. Meteor, most of the time, is overkill. On the other hand, it’s very easy to learn as a backend for beginners that are learning React, for example.
1 Like
@joshowens How about a podcast talking about best practices for scaling Meteor apps on Digital Ocean, Modulus and Galaxy?
I think Meteor knew the days of those questions coming up were around the corner. I suppose that is why they are working on Apollo, right?
1 Like
I’ve given a talk on youtube and done some blog posts. Are you looking for something more specific?
You can find the article here.
Here is the video:
@joshowens I’ve never built an app that needs to scale before-- the apps I’ve built for customers have all been for internal use within their organizations, and have never required a large enough number of concurrent users to require any thought about scaling.
The app I’m developing now would need to scale, and I need to start learning about how to do it on leading PaaS providers.
Meteor / Blaze / Meteor Packages I think made it the VB of the Web world. Where its quick for people to make websites, you don’t need a lot of experience to get going and can do quite productive things. However, more and more, Meteor is almost making itself redundant by making the whole thing pluggable to leverage the larger node eco system and diversifying the meteor community so people aren’t really building on a common stack anymore, so there’s going to be less and less overlap between what people are doing.
For me, I’m mostly using React / Redux for the bulk of clientside, It works well with a lot of backends, though a bit mismatched with Meteor ( still works fine ). Apollo looks promising, but at the moment, I’m really liking Elixir / Phoenixframework. The Scaling and Data backend story is just so much better. Not to mention how nice Elixir is.
Meteor I think has fundamentally changed, it’s now not an opinionated stack focused on building a community around that common stack. it still has some of the legacy of an opinionated stack, but is slowly moving o being a build system for the Node ecosystem + a guide to building apps.
Not sure how that’s going to work out.
6 Likes
@juliancwirko For the backend, I wrote a simple REST API with express.
I also wrote an API with golang but discarded it because I felt I wouldn’t be able to iterate/change things as fast as I can with JavaScript.
I’d have been tempted to take a look at the Apollo stack if I were in your shoes, however I appreciate that you needed a quick fix.
Are you sending and fetching non needed data from the DB?
For scaling purposes, Meteor does grab all synced data.
You can turn it off and tell it how to grab it though.
Yes it does take more time, but performance issues will be less.
How do accounts/authorization work in Elixir? Does it provide you a userID for the logged-in user?
Elixir is the language, Phoenix Framework is a web framework, no accounts/auth built in, you need to choose
Haven’t seen these types of issues using a proper setup w/oplog tailing (and not publishing a ton of data to the frontend) any app needs to be built to scale.
Just deployed a new version with React + Redux frontend with REST API with Express.
Pros:
- Easy server side rendering
- Faster deploy
- Full control over stack
Cons:
- I miss
Meteor.user()andMeteor.loginWith[...].
3 Likes
Sorry to hijack the thread a little bit.
I’m being asked to rewrite a website which already has 100+ concurrent visitors. I know it’s not a lot, but is more than zero and close to OP’s case.
I really want to use Meteor since it is so easy and simple, without all the typical build/deploy/etc. hassle of other ecosystems, besides i’ve never used React or Angular before.
If i’d completely left aside all the ‘real time’ stuff (using it perhaps for very specific things, like notifications on the control panel), could i get nearly the same performance as a typical Node/Express website? Could i regret having used Meteor for some reason?
I’d like to use Galaxy for hosting and completely forget about server maintenance, etc.
What things should i consider to put in the positive and negative sides of the equation? Thanks!
Edit: also the website’s owners have a really close eye on the SEO stuff, so could this be a major drawback?
1 Like