Apply recommended practices

This guide covers practical patterns you should follow when developing Pear applications.

Use one Corestore instance per application

Corestores are meant to manage many Hypercores and their sessions efficiently. Having multiple Corestore instances can cause issues such as file locking errors when using the same storage and duplicate core storage if the same core is used by two Corestores with different storages.

A single Corestore instance:

• Reduces open file handles.
• Reduces storage space by deduping Hypercore storage.
• Requires only one replication stream per peer.

If named cores collide across app components, use namespaces (store.namespace('a')) to create a namespaced Corestore. Retrieving cores by key is unaffected by namespacing. For a worked example, see Work with many Hypercores using Corestore.

Use one Hyperswarm instance per application

Hyperswarm supports joining multiple topics on the same instance and will dedup peer connections shared between them. Having only one swarm instance will speed up connections by reducing records in the HyperDHT for the topic and simplify managing the max number of connections an app makes.

Never load JavaScript over HTTP(S)

Loading code from an external source is dangerous. If that source is compromised or malicious, your app can be exploited. Pear blocks HTTP and HTTPS code loading by default to prevent that supply-chain risk. This matters even more for apps with native API access. See Dependencies and network for the broader rationale behind shipping dependencies with the app instead of fetching them at runtime.

See also

• Work with many Hypercores using Corestore — applies the one-Corestore-per-app pattern.
• Connect to many peers by topic with Hyperswarm — applies the one-Hyperswarm-per-app pattern.
• Troubleshoot common issues — symptoms when these patterns aren't followed.
• Dependencies and network — why dependencies ship with the app, not from HTTPS.