5 ms·

No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really

No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.

mattacular 9y ago
Websockets is also probably overkill for most applications unless it really needs to update in near real-time (such as for a multiplayer game) and requires specialized server architecture. HTTP/2 with server-sent events is an interesting modern solution for applications that would have previously used long-polling.
- brlewis 9y ago
  I had steered clear of websockets a lot until recently. Turns out it's not a big deal. The API is easy in node. It's easy on the browser side too, and now widely supported. You only have to give up IE9 and Opera Mini.
tiri 9y ago
Thank you! Which backend framework should I use? I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?
- albertgoeswoof 9y ago
  http://megaboilerplate.com http://megaboilerplate.com will get you set up fastest, with auth already in there. It sounds like you have no specific requirements for the backend, so don’t waste time thinking about it, just pick something and go.
vazamb 9y ago
You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.
anonytrary 9y ago
You can turn it off with about 10-15 lines of code. It has been a while, but IIRC they just cache way too much data. Wrap their caching functions to forget the data when you know you don't need it. Still, I wouldn't use Meteor for anything requiring scale. Besides, it's way too easy to introduce state on the server, but there shouldn't be state on the server. I think polling is ultimately a better model because it allows each component to throttle itself at whatever pace is necessary. I can see meteor being useful for applications that required a shared state on the server (or in Redis or something) like in online games, chat, or any other online multiuser application. But then Meteor became a tool for common websites that didn't actually need reactivity, and people started abusing server state, reactivity, etc. I think at some point, the community was begging for options to turn reactivity off in cert
anonytrary 9y ago
You can turn it off with about 10-15 lines of code. It has been a while, but IIRC they just cache and diff way too much data for the reason that it saves bandwidth. Wrap their caching functions to forget the data when you know you don't need it, and Meteor can become much more performant. Still, I wouldn't use Meteor for any kind of traditional website. It's way too easy to introduce state on the server, but there shouldn't be state on the server, and it's way too easy to abuse reactivity and end up with a toy that tanks with trivial traffic. I think polling is ultimately a better model because it allows each component to throttle itself at whatever pace is necessary. I can see Meteor being useful for applications that require a shared state on the server (or in Redis or something) like in online games, chat, or any other online multi-user real-time application. But then Meteor became a tool for common websites that didn't actually need reactivity, and people started abusing server state, reactivity, etc. I think at some point, the community was begging for options to turn reactivity off by default or in certain cases. Meteor apps consume less data but take up a ton of server resources. Overall, the problems introduced by polling were just traded for DDP's own problems. The problem of "sending data to the client in real time" might not even be an important problem. If the client looks at a page every 20 seconds, then there's no reason for the page to be updating for an empty audience. I think Meteor is building something called Apollo now which uses some sort of intermediary caching server to keep track of data versions, which the client then polls for updates to the data it depends on. At a first glance, it looks like they just took the problem with DDP and moved it into an independent system. I could be wrong, maybe their polling solution would end up fixing the issues.
- petrbela 9y ago
  > I think Meteor is building something called Apollo Apollo is a library for GraphQL, primarily client side but there's also a server component (sort of like ExpressJS for GraphQL). While GraphQL also includes real-time web-socket based subscriptions, they are an extension rather than the core, and, in practice, most clients/servers (including Apollo) use polling to fetch updates because it requires a much simpler server architecture.

mattacular 9y ago

Websockets is also probably overkill for most applications unless it really needs to update in near real-time (such as for a multiplayer game) and requires specialized server architecture. HTTP/2 with server-sent events is an interesting modern solution for applications that would have previously used long-polling.

brlewis 9y ago
I had steered clear of websockets a lot until recently. Turns out it's not a big deal. The API is easy in node. It's easy on the browser side too, and now widely supported. You only have to give up IE9 and Opera Mini.

tiri 9y ago

Thank you! Which backend framework should I use? I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?

albertgoeswoof 9y ago
http://megaboilerplate.com http://megaboilerplate.com will get you set up fastest, with auth already in there. It sounds like you have no specific requirements for the backend, so don’t waste time thinking about it, just pick something and go.

vazamb 9y ago

You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.

anonytrary 9y ago

You can turn it off with about 10-15 lines of code. It has been a while, but IIRC they just cache way too much data. Wrap their caching functions to forget the data when you know you don't need it. Still, I wouldn't use Meteor for anything requiring scale. Besides, it's way too easy to introduce state on the server, but there shouldn't be state on the server. I think polling is ultimately a better model because it allows each component to throttle itself at whatever pace is necessary. I can see meteor being useful for applications that required a shared state on the server (or in Redis or something) like in online games, chat, or any other online multiuser application. But then Meteor became a tool for common websites that didn't actually need reactivity, and people started abusing server state, reactivity, etc. I think at some point, the community was begging for options to turn reactivity off in cert

anonytrary 9y ago

You can turn it off with about 10-15 lines of code. It has been a while, but IIRC they just cache and diff way too much data for the reason that it saves bandwidth. Wrap their caching functions to forget the data when you know you don't need it, and Meteor can become much more performant. Still, I wouldn't use Meteor for any kind of traditional website. It's way too easy to introduce state on the server, but there shouldn't be state on the server, and it's way too easy to abuse reactivity and end up with a toy that tanks with trivial traffic. I think polling is ultimately a better model because it allows each component to throttle itself at whatever pace is necessary. I can see Meteor being useful for applications that require a shared state on the server (or in Redis or something) like in online games, chat, or any other online multi-user real-time application. But then Meteor became a tool for common websites that didn't actually need reactivity, and people started abusing server state, reactivity, etc. I think at some point, the community was begging for options to turn reactivity off by default or in certain cases. Meteor apps consume less data but take up a ton of server resources. Overall, the problems introduced by polling were just traded for DDP's own problems. The problem of "sending data to the client in real time" might not even be an important problem. If the client looks at a page every 20 seconds, then there's no reason for the page to be updating for an empty audience. I think Meteor is building something called Apollo now which uses some sort of intermediary caching server to keep track of data versions, which the client then polls for updates to the data it depends on. At a first glance, it looks like they just took the problem with DDP and moved it into an independent system. I could be wrong, maybe their polling solution would end up fixing the issues.

petrbela 9y ago
> I think Meteor is building something called Apollo Apollo is a library for GraphQL, primarily client side but there's also a server component (sort of like ExpressJS for GraphQL). While GraphQL also includes real-time web-socket based subscriptions, they are an extension rather than the core, and, in practice, most clients/servers (including Apollo) use polling to fetch updates because it requires a much simpler server architecture.