mirror of
https://github.com/aljazceru/pear-docs.git
synced 2025-12-17 06:24:24 +01:00
b11bb658c7
* Add aside about using only one corestore instance per application A single corestore instance covers all needs and avoids pitfalls (such as file locks and named hypercores not being the same key) that come from multiple corestore instances. * Add note for best practice to create one hyperswarm instance per app * Create a best practices guide for Pear Application development * Add "Best Practices" article to SUMMARY.md & README.md * Include points added to the guides on using single swarm & store * Fix capitalization in Best Practices article
25 lines
1.7 KiB
Markdown
25 lines
1.7 KiB
Markdown
# Best Practices
|
|
|
|
This article covers useful patterns that one should follow in most cases when
|
|
developing Pear applications.
|
|
|
|
## Use One Corestore Instance Per Application
|
|
|
|
Corestores are meant to manage many cores 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 will:
|
|
|
|
- Reduces open file handles.
|
|
- Reduces storage space by deduping hypercore storage.
|
|
- Requires only one replication stream per peer.
|
|
|
|
If using `name`d cores that collide across different components of an app is an issue, use namespaces (`store.namepace('a')`) to create a namespaced version of a Corestore. Note that retrieving cores by `key` are unaffected by namespacing.
|
|
|
|
## 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 DHT for the topic and simplify managing the max number of connections an app makes.
|
|
|
|
## Never Load Javascript Over HTTP(S)
|
|
|
|
Just like in web development, running code from an external source is dangerous. Running external code opens an application up to being exploited if the external source is nefarious or compromised. This is why http and https traffic is blocked by default in Pear applications, preventing unintentional loading of code that would make your application vulnerable to supply chain attacks. This is especially dangerous for applications, like Pear applications, that have access to native functionality (eg. the file system).
|