Best pattern for updating text from input event

Using Meteor 1.8, Blaze, Semantic UI

A critical feature of my application is real-time collaboration. As in, when an item is re-positioned or a value in a text box is changed it will reflect on the screens on other people with the same view open. No problem, I am using Meteor.

To help this along I have been using invisible input boxes and picking up the Input event in template events.

I have been experimenting with client side updates with allow/deny and server side updates, sending the whole new string back to the server to be updates. As you probably guess the server side updating isn’t very fluid due to latency.

This is an example video running on a Galaxy server:

I hear that client side updating with allow/deny is widely discouraged now. So what are my options to get the same experience, but calling a Meteor Method from the server? or should I use client side for this and ensure it is checking user rights and limiting which fields can be updated?

You’ve got a few questions here, I’ll try to answer in turn:

  1. allow/deny rules are discouraged because it is hard to ensure security with them in some cases. However, if you have simple rules, and you define them all in a single deny function, they are simple and secure. The problem is that combining allow and deny (or multiple rules in either) can allow undesirable calls to succeed, where they should fail.

  2. Whether you call MyCollection.update or Meteor.call("someMethod") you can still use Meteor’s pub/sub for data reactivity. It is the publication + database modification that allows this behaviour, the way you modify the database is (mostly) irrelevant. Mostly because if you’re using Redis, then modifications made externally to Meteor won’t be tracked.

  3. Your video doesn’t seem to show that latency is the problem, the fact that the field doesn’t start updating until after you blur, suggests that you are using the wrong event handler. The fact that it doesn’t directly replicate the input of the text box suggests that your logic isn’t right somewhere. It’s possible that latency is the cause here, and that it just happened to start showing changes when you blurred the text field.

  4. If latency is indeed a problem, you’ve got a few options. In general, make sure your DB servers are located as closely as possible to your app servers. For this reason, I don’t use either Galaxy or Atlas (or similar), I host my apps directly in AWS where I can ensure locality. Similarly, you should ensure that your app servers are as closely located to your users as possible.

  5. Another option for improving latency is to push changes to use a local collection on the server to track changes. This will remove the latency of server -> DB -> server. You write to the DB and to the local collection simultaneously, the client subscribes to the DB collection to get the real document, then subscribes to the local collection to receive the low-latency updates.

Thank you for your feedback. Looking into the problem I found that I had wrapped all my Metoer.method definitions in a if (Meteor.isServer) block so it Meteor wasn’t simulating the change client side.

For update methods that require this level of realtime text input I will define them out of that isServer block so that there is a stub (learning new words) for them.

Is this the Meteor way?

1 Like

Yes, if you do the update on the client side as well as the server side (sometimes referred to as optimistic UI) then the client on which you make the change, will immediately see the result.

1 Like