hasura/graphql-engine
1
0
Fork 0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-12-15 17:31:56 +03:00
Code Issues Projects Releases Wiki Activity
7393c152e3
graphql-engine/server/documentation/glossary.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

103 lines
1.8 KiB
Markdown
Raw Normal View History

Add documentation scaffolding for first sync-up. ## Description This PR adds a basic README file to `server/documentation`, in order to get something somewhat decent when we run the first automatic sync. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3468 GitOrigin-RevId: 10c3afc1ea02ee3eb914009e3b9ad22065c1db50
2022-01-25 16:17:26 +03:00
# Glossary
Structural updates to the server's engineering documentation ### Description This PR does several things: - it cleans up some structural issues with the engineering documentation: - it harmonizes the table of contents structure across different files - adds a link to the bigquery documentation - moves some files to a new `deep-dives` subfolder - puts a title at the top of each page to avoid github assuming their title is "table of contents" - it pre-fills the glossary with a long list of words that could use an entry (all empty for now) - it adds the only remaining relevant server file from [hasura-internal's wiki](https://github.com/hasura/graphql-engine-internal/wiki): the old "multiple backends architecture" file ### Discussion A few things worth discussing in the scope of this PR: - is it worth migrating old documentation such as the multiple backends architecture, that document a decision process rather instead of being up-to-date reflections of the code? are we planning to delete hasura-internal? - should we focus instead on _new_ documentation, aimed to be kept up to date? - are there other old documents we want to move in here, or is that it? - is this glossary structure ok, or would a purely alphabetical structure make sense? - does it make sense to have the glossary only in the engineering section? more generally, _what's our broader plan for documentation_? PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4537 GitOrigin-RevId: c2b674657b19af7a75f66a2a304c80c30f5b0afb
2022-05-30 12:45:06 +03:00
<!--
Please make sure you update the table of contents when modifying this file. If
you're using emacs, you can generate a default version of it with `M-x
markdown-toc-refresh-toc` (provided by the package markdown-toc), and then edit
it for readability.
-->
Add documentation scaffolding for first sync-up. ## Description This PR adds a basic README file to `server/documentation`, in order to get something somewhat decent when we run the first automatic sync. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3468 GitOrigin-RevId: 10c3afc1ea02ee3eb914009e3b9ad22065c1db50
2022-01-25 16:17:26 +03:00
Structural updates to the server's engineering documentation ### Description This PR does several things: - it cleans up some structural issues with the engineering documentation: - it harmonizes the table of contents structure across different files - adds a link to the bigquery documentation - moves some files to a new `deep-dives` subfolder - puts a title at the top of each page to avoid github assuming their title is "table of contents" - it pre-fills the glossary with a long list of words that could use an entry (all empty for now) - it adds the only remaining relevant server file from [hasura-internal's wiki](https://github.com/hasura/graphql-engine-internal/wiki): the old "multiple backends architecture" file ### Discussion A few things worth discussing in the scope of this PR: - is it worth migrating old documentation such as the multiple backends architecture, that document a decision process rather instead of being up-to-date reflections of the code? are we planning to delete hasura-internal? - should we focus instead on _new_ documentation, aimed to be kept up to date? - are there other old documents we want to move in here, or is that it? - is this glossary structure ok, or would a purely alphabetical structure make sense? - does it make sense to have the glossary only in the engineering section? more generally, _what's our broader plan for documentation_? PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4537 GitOrigin-RevId: c2b674657b19af7a75f66a2a304c80c30f5b0afb
2022-05-30 12:45:06 +03:00
<!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-refresh-toc -->
- [Product](#product)
- [Actions](#actions)
- [Data connectors](#data-connectors)
- [Event triggers](#event-triggers)
- [GDW](#gdw)
- [GraphQL Data Wrappers](#graphql-data-wrappers)
- [Metadata](#metadata)
- [Relationships](#relationships)
- [Relay](#relay)
- [Remote relationships](#remote-relationships)
- [Source](#source)
- [Schema cache](#schema-cache)
- [GraphQL](#graphql)
- [Introspection](#introspection)
- [Mutations](#mutations)
- [Queries](#queries)
- [Query root](#query-root)
- [Schema](#schema)
- [Subscriptions](#subscriptions)
- [Livequeries](#livequeries)
- [Haskell](#haskell)
- [Existential types](#existential-types)
- [Implementation](#implementation)
- [Field](#field)
- [IR](#ir)
- [Parser](#parser)
- [RQL](#rql)
<!-- markdown-toc end -->
## Product
### Actions
### Data connectors
### Event triggers
### GDW
See [GraphQL Data Wrappers](#graphql-data-wrappers).
### GraphQL Data Wrappers
Original name of [Data connectors](#data-connectors).
### Metadata
### Relationships
### Relay
### Remote relationships
### Source
Add documentation scaffolding for first sync-up. ## Description This PR adds a basic README file to `server/documentation`, in order to get something somewhat decent when we run the first automatic sync. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3468 GitOrigin-RevId: 10c3afc1ea02ee3eb914009e3b9ad22065c1db50
2022-01-25 16:17:26 +03:00
Structural updates to the server's engineering documentation ### Description This PR does several things: - it cleans up some structural issues with the engineering documentation: - it harmonizes the table of contents structure across different files - adds a link to the bigquery documentation - moves some files to a new `deep-dives` subfolder - puts a title at the top of each page to avoid github assuming their title is "table of contents" - it pre-fills the glossary with a long list of words that could use an entry (all empty for now) - it adds the only remaining relevant server file from [hasura-internal's wiki](https://github.com/hasura/graphql-engine-internal/wiki): the old "multiple backends architecture" file ### Discussion A few things worth discussing in the scope of this PR: - is it worth migrating old documentation such as the multiple backends architecture, that document a decision process rather instead of being up-to-date reflections of the code? are we planning to delete hasura-internal? - should we focus instead on _new_ documentation, aimed to be kept up to date? - are there other old documents we want to move in here, or is that it? - is this glossary structure ok, or would a purely alphabetical structure make sense? - does it make sense to have the glossary only in the engineering section? more generally, _what's our broader plan for documentation_? PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4537 GitOrigin-RevId: c2b674657b19af7a75f66a2a304c80c30f5b0afb
2022-05-30 12:45:06 +03:00
### Schema cache
## GraphQL
See the [spec](http://spec.graphql.org/June2018).
### Introspection
### Mutations
### Queries
### Query root
### Schema
### Subscriptions
Add documentation scaffolding for first sync-up. ## Description This PR adds a basic README file to `server/documentation`, in order to get something somewhat decent when we run the first automatic sync. PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3468 GitOrigin-RevId: 10c3afc1ea02ee3eb914009e3b9ad22065c1db50
2022-01-25 16:17:26 +03:00
### Livequeries
See [Subscriptions](#subscriptions).
Structural updates to the server's engineering documentation ### Description This PR does several things: - it cleans up some structural issues with the engineering documentation: - it harmonizes the table of contents structure across different files - adds a link to the bigquery documentation - moves some files to a new `deep-dives` subfolder - puts a title at the top of each page to avoid github assuming their title is "table of contents" - it pre-fills the glossary with a long list of words that could use an entry (all empty for now) - it adds the only remaining relevant server file from [hasura-internal's wiki](https://github.com/hasura/graphql-engine-internal/wiki): the old "multiple backends architecture" file ### Discussion A few things worth discussing in the scope of this PR: - is it worth migrating old documentation such as the multiple backends architecture, that document a decision process rather instead of being up-to-date reflections of the code? are we planning to delete hasura-internal? - should we focus instead on _new_ documentation, aimed to be kept up to date? - are there other old documents we want to move in here, or is that it? - is this glossary structure ok, or would a purely alphabetical structure make sense? - does it make sense to have the glossary only in the engineering section? more generally, _what's our broader plan for documentation_? PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4537 GitOrigin-RevId: c2b674657b19af7a75f66a2a304c80c30f5b0afb
2022-05-30 12:45:06 +03:00
## Haskell
### Existential types
## Implementation
### Field
### IR
### Parser
### RQL
Reference in New Issue Copy Permalink