Latency compensation is a really nice feature of Meteor that truly improves the UX of your apps, but we have entirely removed it from our code not too long ago, as it was hard to maintain client and server shared code, without everything feeling messed up. We’re starting to feel the slow-down from a pure server-side approach though, and we’d love to have some of that sweet compensation-juice improve our user experience.
I’m following up on this very old thread: Best practices for pub/sub, latency compensation and methods in real-life scenarios? which includes @waldgeist
We face some of the same issues raised there:
- Difficulty of maintaining a shared code base between client and server, without spreading isServer/isSimulation
- Bundle size management, as all this code will take up space
- How could you code-split this properly, to avoid loading all of your meteor methods code on initial load?
- Hiding of server-side business logic for certain methods
- How do you organize your codebase properly such that you have server-only, and client+server code, without rewriting a lot of things everywhere? Again, on the server you don’t care about code-splitting, but on the client, it’s a must-have!
A few pointers:
- Perfect separation of security and business logic
- Maintain a very small set of frequently used CRUD methods that exist on both client and server, and keep the rest on the server
- Create a shared Class of business logic code on client+server, that you subclass on the server to share functionality
I’d love to see a really elegant wrapper around meteor methods that handles this in a scaleable way.