Start FAQ (#1386)

* Start FAQ

* Update FAQ.md

docs/start/FAQ.md

@@ -1 +1,13 @@
-# Frequently Asked Quetions
+# FAQ
+
+The list will be updated/expanded as questions come up, dealing with some common issues that API users find.
+
+## I connected to a node and I am getting a "Unknown types found, no types for ..." error
+
+There are 2 caused for this, both related to the version of the API that you are using and the support of types. As explained in the elsewhere, types on Polkadot/Substrate are continuously evolving - the latest version of the API always tries to support types for the latest Polkadot networks, such as [Kusama](https://kusama.network/). So for Polkadot public chains, ensure that you are using the latest released API version.
+
+If however you are running against a master branch of either Polkadot or Substrate, you may well be better suited running [a beta version, tracking master](install.md#betas). If you are connected to a customized chain, you would rather want to [register the types](types.extend.md) either on your own, ot via packages that the chain vendor provides.
+
+## I connected to a node an I am getting a "Metadata:: failed on MagicNumber" error
+
+Update your version of the API to the [latest version](install.md). Like types, the [metadata interfaces](basics.md) are continuously evolving. For instance with the Polkadot Alexander network, only metadata v3 is available. By the time Kusama launched, this has been bumped to v7. As these versions are added to the Polkadot/Substrate codebase, they are added to the API.

docs/start/README.md

@@ -12,4 +12,4 @@ If you spot gaps in the information provided, or are uncertain about any specifi
 
 ## Ready? Steady? Go!
 
-With all that said, let's get started... [What should be installed, and how should we do it?](install.md)
+If you already have a good grasp on the API and are just looking for a specific answer, you may want to take a look at the [Frequently Asked Questions](FAQ.md). With all that said, let's get started... [What should be installed, and how should we do it?](install.md)

docs/start/api.query.md

@@ -1,4 +1,4 @@
-# Chain state
+# State queries
 
 In previous sections, we initialized the API and retrieved runtime constants. This section will walk through the concepts behind making queries to the chain to retrieve current state. The `api.query.<module>.<method>` interfaces, as already described earlier, is populated from the metadata. The API uses the metadata information provided to construct queries based on the location and parameters provided to generate state keys, and then queries these via RPC.
 

docs/start/api.query.subs.md

@@ -1,4 +1,4 @@
-# Streaming queries
+# Query subscriptions
 
 Previously we explained the concepts between `api.query`. In this section we will expand on that knowledge to introduce subscriptions (akin to what we found in `api.rpc`) to stream results from the state, as it changes between blocks.
 

docs/start/api.rpc.md

@@ -1,4 +1,4 @@
-# Making RPC queries
+# RPC queries
 
 The RPC calls provide the backbone for the transmission of data to and from the node. This means that all API endpoints such as `api.query`, `api.tx` or `api.derive` just wrap RPC calls, providing information in the encoded format as expected by the node.
 

docs/start/api.tx.subs.md

@@ -1,4 +1,4 @@
-# Transactions and subscriptions
+# Transaction subscriptions
 
 Previously we sent simple transactions using the `api.tx` endpoints, in this section we will extend that to monitor the actual transactions for inclusion and also extend the monitoring for transaction events.
 

docs/start/types.basics.md

@@ -1,4 +1,4 @@
-# Introduction to types
+# Type basics
 
 We've touched upon types in most previous sections, i.e. that these are driven by metadata and that they are created and converted to/from automatically by the API. Since they appear in all results, we will divert a bit from the regularly scheduled program in explaining the API interfaces to giving some info on the base types.
 

docs/start/types.extend.md

@@ -1,4 +1,4 @@
-# Adding additional types
+# Extending types
 
 Circling back to metadata, by default the metadata information (at this point in time), only returns the type names as they apply to any section, be it a call, event or query. As an example, this means that transfers are defined as `balances.transfer(AccountId, Balance)` with no details as to the mapping of the `Balance` type to a `u128`. (The underlying Substrate/Polkadot default)