spacecloud-io / space-docs Goto Github PK

We should have guides for advanced usecases around space cloud in the docs as well. Few things that I can think of now are as:

• Rate limiting
• Auditing
• Batching/Debouncing logic for API requests

When space-cloud/pull/508 is merged, docs for the logging should be added.

The docs shows all the code sections of all tabs (active and inactive) on page reload for a moment before finally just showing the content of selected tab. This leads to the UI section jumping for a moment, which is a bad experience.

This might be due to Material Tabs getting initialised late

We should add a diagram for event triggers similar to what is there in remote services.

We should document the full capabilities of graphql joins (cross database, cross service and database-service)

GraphQL example of AND in filter query results should not have double quotes around caught on. GraphQL is throwing an error when there are double quotes around key.

Right now there's a single page for features. Allotting a separate section to features with pages in it for each module will allow users to easily navigate through it and find what they are looking for:)

The object returned by the subscription is model.FeedData. We are not explaining all the fields returned

Deploying space cloud behind a reverse proxy like caddy or nginx, usually requires to configure (the websocket routing are something which people usually struggle with) the reverse proxy.

We should have advanced deployment guides in the docs that uses reverse proxy.

This is how reverse proxy for Websockets is handled in nginx - https://www.google.co.in/amp/s/www.nginx.com/blog/websocket-nginx/amp/

Following new capabilities have been added in the schema module which needs to be documented:

• default directive
• indexes
• composite primary and unique keys

In essentials -> queries there are no examples for Java and Go.

Usually people feel that they need to store data of different users in different databases or schemas for a multi tenant app.

However, this can be easily done much easily by scoping each users' request to his data via the security rules in SC. Hence, we should include this use case somewhere in the docs. Perhaps in the security section.

Space Cloud auto generates constraints like foreign keys and unique keys from the SDL. These constraints need to have a name. For example:

ADD CONSTRAINT <CONSTRAINT_NAME> PRIMARY KEY (Field1);

It will be better if we can document how Space Cloud chooses this CONSTRAINT_NAME based on the table and columns.

The concept and types of security rules available for each module are same with only the available variables changing. Still, we explain all rules for each module making each page big and difficult to navigate.

Instead we can break security into action wise pages, similar to what we have done for database queries and mutations.

Similar to what is there as an empty state for File Storage Module in Mission Control UI.

We should explain properly what http request is being made for a remote service:

• body
• endpoint