Focus on impact on users, not just improving benchmarks (eg. improving
the fastest/easiest to improve methods)
this.unblock, especially useful with external services
Reduce number of ops – database op/api call
Consider delaying ops to batches
Optimise the code itself, using profiler
Publication response time
Slightly less detailed aggregation charts
Check # of simultaneous pubs
Publish fewer documents
Extract shared pubs
Meteor has multiplexor of pubs -> if multiple users subscribe to
same document using same query, Meteor will deduplicate the
observers and share only one observer
Use cult-of-coders:redis-oplog
same as with methods
API response times
REST API, public files (if not using CDN)
HTTP tab of Monti APM (Meteor APM is not so good yet)
Use non-Meteor APM
Apollo Studio (for GraphQL)
Datadog APM
Elastic APM
New Relic APM
Raygun APM
Ideally use the one used in by the rest of the company, to correlate
Log the performance
Extract metrics/charts from them
CRON jobs/Daemons
Generic APMs are not designed for these, but it's usually possible
with "custom" measurements.
TIP: Expose them via API and use generic APM. Auth properly!
Re-consider timing and batching.
Re-consider scope – smaller often, bigger rarely.
Offload to "worker nodes" – external micro-services
Sometimes a MongoDB aggregation is enough, maybe for analytical
database with 1h update time. To avoid scattering.
Database throughput
Use MongoDB Atlas - scary at first, learn to read in them.
Check your indexes – remove no longer used ones. Atlas detects it.
The problem – testing Meteor Methods and Publications is not
friendly. Here are some ways to do it.
Hardcode values – You have to deactivate middlewares for testing as
well.
DDP Tools – Install third-party programs
Meteor Shell
"Back-end developers should be able to test their endpoints without
having to use the front-end or writing scripts"
Meteorman
Call methods
Subscribe to publications and see updates in real time
Document your endpoints with Markdown
Future (basically what Postman does)
Cloud service - saving collections
Shared Workspaces with team
Load testing
TODO: Recorded demo should be posted
New React Hooks for Meteor
useMeteorState,
useSubscribe,
useFind,
useUserId
useUser
Maintainer of useTracker
Why? Tighter integration than just useTracker.
Collection queries for massive lists - if one changes, whole list
re-renders (or at least reconcile). References stay stable (useful for
animations)
useFind and useSubscribe
useFind – single cursor from factory method
Plays nice with React logic.
why is isLoading method? To setup reactivity only when needed loading
indicator.
Use cases: Chats, big tables.
Many small components - optimised for concurrent mode.
skipUpdate - compare results by yourself. Beware: fast-deep-equals can be actually slower than React
reconciliation. You are basically skipping React optimization.
Useful when your backend provide update timestamp.
just simple convenience wrappers
requires globally unique id, unlike useState
Q&A
Option to opt-out
findOne - use useTracker(), internally just .fetch()[0], so no special
hook necessary. Don't use useFind as it creates cursor.
Diff between useSubscribe and subscribing in useTracker
skipUpdate can be useful to filter out updates that come from properties
to which you haven't subscribed. It's a quirk of tracker that any
property update will cause a reaction, even if that property is filtered
out in the query itself!