Add Best practices article (#186)

* 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

README.md

@@ -37,6 +37,7 @@ Guides on using the Pear Runtime to build and share P2P applications.
 * [Releasing a Pear Application](./guide/releasing-a-pear-app.md)
 * [Making a Bare Mobile Application](./guide/making-a-bare-mobile-app.md)
 * [Creating a Pear Init Template](./guide/creating-a-pear-init-template.md)
+* [Best Practices](./guide/best-practices.md)
 
 ### How-tos
 

SUMMARY.md

@@ -29,6 +29,7 @@
 * [Making a Bare Mobile Application](./guide/making-a-bare-mobile-app.md)
 * [Debugging a Pear Terminal Application](./guide/debugging-a-pear-terminal-app.md)
 * [Creating a Pear Init Template](./guide/creating-a-pear-init-template.md)
+* [Best Practices](./guide/best-practices.md)
 
 ### Building blocks
 

guide/best-practices.md

@@ -0,0 +1,24 @@
+# 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).

howto/connect-to-many-peers-by-topic-with-hyperswarm.md

@@ -66,3 +66,5 @@ pear run --dev .
 This will display the topic. Copy/paste that topic into as many additional terminals as desired with `pear run --dev . <SUPPLY TOPIC HERE>` (assuming that the current working directory of each terminal is the `peer-app` folder). Each peer will log information about the other connected peers.
 
 Start typing into any terminal, and it will be broadcast to all connected peers.
+
+> It is best practice to only have one Hyperswarm instance per application. This will speed up connections by reducing number of entries per topic and connections.

howto/work-with-many-hypercores-using-corestore.md

@@ -6,6 +6,11 @@ An append-only log is powerful on its own, but it's most useful as a building bl
 
 In [How to replicate and persist with Hypercore](./replicate-and-persist-with-hypercore.md), only single Hypercore instance was replicated. But in this how-to, we will replicate a single Corestore instance, which will internally manage the replication of a collection of Hypercores. We will achieve this with two Pear Terminal Applications: `multicore-writer-app` and `multicore-reader-app`.
 
+> Only one Corestore per application is needed. This is the recommended best practices to make managing Hypercores efficient and to avoid pitfalls from having multiple Corestores. A single Corestore will:
+> - Manage multiple sessions for the same Hypercore.
+> - Requires only one replication stream per peer connection.
+> - Simplifies referring to Hypercores by a name.
+
 Create the `multicore-writer-app` project with these commands:
 
 ```