Added more docs for Banana Cake Pop and Barista (#6172)

website/src/docs/bananacakepop/v2/apis.md

@@ -0,0 +1,18 @@
+--- 
+title: Apis
+---
+
+![Image](images/apis-0.png)
+An API within the context of Banana Cake Pop, refers to an representation of your GraphQL Servers. 
+This representation is more than a mere conceptual framework — it serves as a practical tool that allows you to group your documents and share common settings like connection and authorization parameters among them.
+
+An API also serves as the basis for your client and schema registry setup. You can find more information about this feature in the [Schema & Client Registry](/docs/bananacakepop/v2/schema-client-registry) guide.
+
+
+# Creating an API
+![Image](images/apis-1.png)
+
+Creating an API in Banana Cake Pop is a straightforward task. Here's are two ways to do it:
+
+1. The first way is to click on the `Create Api` button located at the top of the document explorer toolbar.
+2. The second way is to right-click within the document explorer and select `New Api` from the context menu. This will create a new api within the currently selected folder. Apis can be in folders but cannot be nested within each other. 

website/src/docs/bananacakepop/v2/bcp-services.md

@@ -0,0 +1,42 @@
+--- 
+title: Connect you API
+---
+
+BananaCake Pop can be smoothly integrated into your HotChocolate server, enabling utilization of the Persisted Query Storage found within the client registry. Your server will establish a connection with BananaCake Pop, retrieving persisted queries based on their unique hashes. Additional information on the client registry can be found [here](/docs/bananacakepop/v2/schema-client-registry).
+
+## Getting Started
+To get started, follow these steps:
+
+1. Set up a client registry as instructed [here](/docs/bananacakepop/v2/schema-client-registry).
+
+2. Install the BananaCakePop package from NuGet using the following command:
+```bash
+dotnet add package BananaCakePop.Services
+```
+
+3. Configure your services as shown in the following code snippet:
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+
+builder.Services
+    .AddGraphQLServer()
+    .AddQueryType<Query>()
+    .AddBananaCakePopServices(x =>
+    {
+        x.ApiId = "VGhpcyBpcyBub3QgYSByZWFsIGFwaSBpZA==";
+        x.ApiKey = "Tm9wZSwgdGhpcyBpcyBhbHNvIG5vIHJlYWwga2V5IDspIA==";
+        x.StageName = "dev";
+    })
+    .UseOnlyPersistedQueriesAllowed() // optional
+    .UsePersistedQueryPipeline();
+
+var app = builder.Build();
+
+app.MapGraphQL();
+
+app.Run();
+```
+
+4. Retrieve the API id and API key from Barista using the `barista api list` and `barista api-key create` commands respectively. Instructions for these commands can be found [here](/docs/bananacakepop/v2/barista).
+
+Congratulations! You have successfully integrated BananaCake Pop into your HotChocolate server. You can now publish new versions of your clients and your server will automatically retrieve the latest persisted queries.

website/src/docs/bananacakepop/v2/documents/authentication.md

@@ -0,0 +1,131 @@
+---
+title: Authentication
+---
+
+Banana Cake pop offers support for various authentication flows. The following guide details how to use these authentication flows to retrieve a token from an identity server and send the Authorization header to the server. 
+
+![BCP Authentication Flow](images/auth-0.png)
+
+Accessing the authentication settings is straightforward:
+
+1. Locate the cog icon in the navigation bar on the left side of the screen.
+2. Click on the icon to open the authentication settings.
+
+BCP supports three types of authentication flows:
+
+- [Basic Authentication](/docs/bananacakepop/v2/documents/authentication#basic-authentication)
+- [Bearer Token](/docs/bananacakepop/v2/documents/authentication#bearer-token)
+- [OAuth 2.0](/docs/bananacakepop/v2/documents/authentication#oauth-20)
+
+# Basic Authentication
+
+Basic Authentication is a built-in authentication scheme of the HTTP protocol. It works by sending HTTP requests with an Authorization header. This header includes the word 'Basic' followed by a space and a base64-encoded string of the format 'username:password'. 
+
+![Basic Authentication Fields](images/auth-1.png)
+
+When setting up Basic Authentication, you will need to provide the following information:
+
+- **Username**: The username required for authentication.
+- **Password**: The corresponding password for the provided username.
+- **Authorization Header**: This is a preview of the header that will be used for authentication. This field is auto-generated based on the inputted username and password.
+
+Learn more about Basic Authentication [here](https://en.wikipedia.org/wiki/Basic_access_authentication).
+
+# Bearer Token
+
+This method involves a client sending a token within the Authorization header. The token is typically generated by the server when a login request is processed. Subsequent requests to protected resources must include this token in the Authorization header.
+
+![Bearer Token Fields](images/auth-2.png)
+
+You will need to provide at least the token. The following fields are available:
+
+- **Token**: The token that will be used for authentication.
+- **Prefix**: The prefix for the token. By default, this is set as 'Bearer'.
+- **Authorization Header**: A preview of the header that will be used for authentication. This field is auto-generated based on the provided token and prefix.
+
+Learn more about Bearer Token Authentication [here](https://swagger.io/docs/specification/authentication/bearer-authentication/).
+# OAuth 2.0 
+
+OAuth 2.0 authentication flow is a industry-standard authorization framework. It allows third-party applications to gain limited access to a web service through a server that supports the OAuth 2.0 protocol. Most major identity providers support OAuth 2.0, including Auth0, Okta, AWS Cognito, Azure AD, and more. 
+
+In .NET, OAuth 2.0 is implemented by [Duende IdentityServer](https://duendesoftware.com/products/identityserver) and [OpenIddict](https://documentation.openiddict.com/).
+
+BCP supports several OAuth 2.0 flows, including:
+
+- [Authorization Code](https://auth0.com/docs/flows/authorization-code-flow)
+- [Client Credentials](https://auth0.com/docs/flows/client-credentials-flow)
+- [Resource Owner Password Credentials](https://auth0.com/docs/flows/resource-owner-password-flow)
+- [Implicit](https://auth0.com/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
+
+Depending on the selected OAuth 2.0 flow, the fields you need to fill in will vary.
+
+![OAuth 2.0 Fields](images/auth-3.png)
+
+The following fields are available required:
+
+- **[Grant Type](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3)**: This is the method an application uses to obtain an access token. Common values include 'authorization_code', 'client_credentials', 'password', and 'refresh_token'. Each type serves a different use case, such as a web application, machine-to-machine, mobile apps, etc.
+
+- **Authorization URL**: This is the URL to which your application directs the user in the initial step of the authorization process. It usually looks something like 'https://auth.example.com/authorize'.
+
+- **Access Token URL**: This is the URL your application uses to obtain the access token from the authorization server. It's typically of the form 'https://auth.example.com/token'. 
+
+- **[Client ID](https://datatracker.ietf.org/doc/html/rfc6749#section-2.2)**: This is a public identifier for your application, issued by the authorization server when you register your application. It's used to identify your application to the user during authorization.
+
+- **[Client Secret](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1)**: This is a confidential key held by the client application, used to authenticate to the authorization server when using 'client_credentials' or 'authorization_code' grant types. It should be kept confidential and never exposed publicly.
+
+- **[Use PKCE](https://datatracker.ietf.org/doc/html/rfc7636)**: PKCE (Proof Key for Code Exchange) is a mechanism designed to secure public clients that don't use a client secret. It's highly recommended for mobile and single-page apps. When enabled, it adds an extra step in the authorization process to prevent certain types of attacks.
+
+- **[Scope](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3)**: These are permissions that the application requests. The value is a list of space-delimited strings, such as 'read:messages write:messages'. 'offline_access' can be requested to get a refresh token.
+
+- **[Redirect URL](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2)**: This is the URL to which the authorization server will redirect the user's browser after authorization has been granted. It must match one of the redirect URIs registered with the authorization server.
+
+- **[Code Challenge Method](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2)**: This field is relevant if PKCE is used. It defines how the code verifier is transformed. 'PLAIN' or 'S256' (SHA256) are common options, with 'S256' being more secure.
+
+- **[State](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1)**: This is an opaque value that is used to maintain state between the request and the callback, mitigating CSRF attacks. It's a good practice to use a unique value for each authorization request.
+
+- **[Credentials](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3)**: Defines how client credentials are sent to the server. They can be sent as a Basic Auth Header or in the Request Body. 
+
+- **Header Prefix**: This is the prefix that appears before the token in the Authorization header. The default is 'Bearer', as described in [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750), but it could also be 'Token' or other custom strings.
+
+- **Audience**: This is the intended audience of the token, typically the identifier of the resource server that should accept the token.
+
+- **Resource**: The target resource that the application wants to access. 
+
+- **Origin**: This is used in browser-based applications to indicate the origin of the request and mitigate CSRF attacks.
+
+- **Username**: Required for the 'password' grant type. This is the resource owner's username.
+
+- **Password**: Also required for the 'password' grant type. This is the resource owner's password.
+
+- **[Response Type](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.1)**: Indicates what should be returned from the initial request. For 'authorization_code' grant type, this should be 'code'. For the implicit grant type, this would typically be 'token'.
+
+This comprehensive set of options allows for fine-tuned control of OAuth 2.0 authentication flows in your application.
+
+Learn more about OAuth 2.0 [here](https://oauth.net/2/).
+
+## Request a token
+
+In BCP, you can fetch the authentication token using two different methods:
+
+1. **Fetch Button in Authentication Settings**: 
+
+   Located at the bottom of the authentication settings is a button labeled `Fetch`. Clicking this will retrieve the authentication token. Once the token is fetched, you also have options to `Clear` it or `Refresh` it (if a refresh token was requested).
+
+   In the desktop application, there's an additional feature to `Reset the session on identity server`. This is particularly useful because your authentication session on your identity server is persisted in the browser, meaning you don't need to sign in repeatedly. If you wish to log in as a different user, you can reset your session by clicking this button.
+
+   ![Fetch Button](images/auth-5.png)
+
+2. **Key Icon in Operations Pane**:
+
+   At the top right of the operations pane, you'll notice a key icon. Clicking this icon initiates the authentication flow.
+
+   ![Key Icon](images/auth-4.png)
+
+These two methods allow you to conveniently manage and initiate your authentication flows, providing you with flexibility to cater to different use-case scenarios.
+
+## Redirect URL 
+
+In the context of BCP (Banana Cake Pop), the Redirect URL plays a crucial role, particularly when you're using BCP within a web browser rather than the desktop application. 
+
+The Redirect URL is where your browser is directed to after the authentication process. It must be configured to point back to the URL where BCP is hosted. This is essential because BCP needs to retrieve the authorization code from this URL to exchange it for a token.
+

website/src/docs/bananacakepop/v2/documents/connection-settings.md

@@ -0,0 +1,32 @@
+---
+title: Connection Settings
+---
+
+The Connection Settings in Banana Cake Pop allow you to configure various options related to connecting and communicating with your GraphQL server. This section describes the different settings available and their functionalities.
+
+![Connection-Settings](./images/connection-settings-0.png)
+
+# Schema Endpoint
+The Schema Endpoint refers to the URL of your GraphQL server. It is the endpoint used to send queries and mutations. Configure this setting with the appropriate URL to establish a connection with your GraphQL server.
+
+# Subscription Endpoint
+The Subscription Endpoint represents the URL used to send subscriptions to the GraphQL server. By default, it is inferred from the Schema Endpoint. Specify the subscription URL if it differs from the Schema Endpoint.
+
+# SSE Subscription Endpoint
+If you utilize SSE (Server-Sent Events) subscriptions, the SSE Subscription Endpoint should be provided. This URL specifies the endpoint for SSE subscriptions. By default, it is inferred from the Schema Endpoint.
+
+# Subscription Protocol
+The Subscription Protocol setting allows you to choose the protocol for handling subscriptions. Banana Cake Pop supports the following options:
+
+- **Auto**: Banana Cake Pop negotiates the protocol with the server automatically based on server capabilities.
+- **GraphQL Websocket**: Banana Cake Pop uses the [graphql-ws](https://github.com/enisdenjo/graphql-ws) protocol for handling subscriptions.
+- **GraphQL SSE**: Banana Cake Pop uses the [graphql-sse](https://github.com/enisdenjo/graphql-sse) protocol for handling subscriptions.
+- **Apollo Websocket**: Banana Cake Pop uses the deprecated [subscriptions-transport-ws](https://github.com/apollographql/subscriptions-transport-ws) protocol from Apollo.
+
+# Use HTTP GET
+By enabling the Use HTTP GET option, Banana Cake Pop will use HTTP GET instead of HTTP POST for executing queries and mutations. This can be useful in certain scenarios or for compatibility with specific GraphQL servers.
+
+# Include Cookies (cross-origin)
+Enabling the Include Cookies (cross-origin) option ensures that cookies are included when sending queries and mutations to the GraphQL server. This is particularly relevant in cross-origin situations where cookies are required for authentication or session management.
+
+The Connection Settings provide you with the flexibility to customize the connection parameters and communication behavior with your GraphQL server. Configure these settings according to your server's requirements and the desired functionality of your application.

website/src/docs/bananacakepop/v2/documents/index.md

@@ -0,0 +1,34 @@
+---
+title: Documents
+---
+
+The Document View is a feature that allows users to work with documents and API documents within the application. It provides functionality for executing queries, mutations, and subscriptions. This section describes the various components and functionalities available in the Document View.
+
+![Image](images/document-0.png)
+
+# 1. Operations
+The Operations section is where you can write and execute your queries, mutations, and subscriptions. It provides a convenient interface for interacting with the GraphQL API.
+
+# 2. Schema Reference
+The Schema Reference section allows you to explore the schema in a tree view or the explorer view. It provides detailed information about the available schema and its components. For more information on using the Schema Reference, refer to the [Schema Reference](/docs/bananacakepop/v2/documents/schema-reference) guide.
+
+# 3. Schema Definition
+The Schema Definition section displays the schema definition in SDL (Schema Definition Language) format. It allows you to inspect the schema structure and understand its various types and fields. Refer to the [Schema Definition](/docs/bananacakepop/v2/documents/schema-definition) guide for further details.
+
+# 4. Document Status Indicator
+The Document Status Indicator visually represents whether the current document is saved or not. A white dot indicates that the document is not saved, while a different icon may indicate a saved or modified state.
+
+# 5. Query Editor
+The Query Editor provides a dedicated space for writing your queries, mutations, and subscriptions. It offers features such as syntax highlighting, auto-completion, and error checking to assist in query composition. Learn more about using the query editor in the [Query Editor](/docs/bananacakepop/v2/documents/query-editor) guide.
+
+# 6. Response Pane
+The Response Pane displays the response of your queries, mutations, and subscriptions. It shows the data returned by the API and provides a structured view for easier analysis. Refer to the [Response Pane](/docs/bananacakepop/v2/documents/response-pane) guide for additional information.
+
+# 7. Schema Indicator
+The Schema Indicator is a visual cue that indicates the connection status with the GraphQL server and the successful retrieval of the schema. A green circle represents a connected state.
+
+# 8. Connected Schema Endpoint
+This section displays the currently connected schema endpoint, providing information about the GraphQL server being accessed.
+
+# 9. Settings
+The Document Settings section allows you to configure various settings specific to the document. Refer to the [Connection Settings](/docs/bananacakepop/v2/documents/connection-settings) guide for detailed information about it. You can also configure the authentication settings for the document. Refer to the [Authentication Settings](/docs/bananacakepop/v2/documents/authentication) guide for more details.