Reputation: 417
in my app I placed the methods in a shared location between client and server. this way as suggested in meteor docs the method mechanism takes care of optimistic UI.
but I just read in the David Weldon blog about two-tier implementation and it makes lot of sense to me.
question is how can I achieve optimistic UI with two-tier implementation.
Move Methods to server, update the clientDB in template events for optimistic UI and deny all the updated from client side to DB.
is there any way that methods be available in client side, but only be callable from another method?
any suggested approach will be appreciated.
Upvotes: 1
Views: 329
Reputation: 457
I think the important thing is to deny client-side inserts/updates. Once that is done, then you can run the second tier code from the client, and it won't actually do anything, because it will be denied.
Here are a few paragraphs from https://www.discovermeteor.com/blog/meteor-pattern-two-tiered-methods/ which support that view:
Client & Server
Although I stated that the postSubmit function primarily expected to run on the server, it will run on the client in two situations.
First, when called from the postSubmit method as part of that method’s client-side simulation. In that case, Meteor will perform the simulation, insert the post in the client-side database, and then finally trigger the server-side postSubmit method call.
The other use case is when someone calls the postSubmit function from the browser console directly. If that happens, the Posts.insert() call will fail because we aren’t allowing client-side inserts, and nothing will happen.
Note that allow/deny doesn’t affect code executed from within a Meteor method, which is why simulations don’t fail even if you didn’t declare an allow/deny policy.
So in other words, answer #1: keep the methods in a common location and remove the insecure package (meteor remove insecure)
Answer to #2: It doesn't matter if they are called outside of the method because they will be denied.
Upvotes: 1