mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 18:51:59 +00:00
Code AI platform with Code Search & Cody
031bb871fb
This PR refactors almost all of the prototypes GraphQL queries to take advantage of GraphQLs compossibility via fragments. The goal is to provide a more structured approach to authoring and executing GraphQL queries, with the following advantages:
- Data dependency co-location makes it easier to maintain/extend individual components.
- Data fetching happens in specific, predictable places (layout and page loaders).
On a high level it works like this:
- Components declare their data dependencies in `<Component>.gql` files next to them. Thanks to GraphQL code generation they can import the corresponding TypeScript types via `import type { SomeFragment} from './<Component>.gql'`.
- Higher level components compose the fragments of their children.
- At the page/layout level `page.gql`/`layout.gql` files define the queries, composed from the data dependencies of the page/layout.
- The page/layout data loaders can import queries directly from the corresponding `.gql` file.
Authoring the `.gql` files should be relatively easily if the graphql language server is setup. The changes in the `.graphlrc` file make all fragments globally available which means that every fragment needs to be unique and we don't need to use unofficial `#import` directives inside `.gql` files.
There are a couple of things to consider though:
- Caching: If different pages/layouts fetch the same data with different queries, we won't leverage caching without additional setup. That's something I still need to look into. That also means that sometimes we might want to use a shared queries instead of composition/co-location, if caching is more important.
- Shared layout data: Some data fetched in layouts is accessed by sub-layouts/sub-pages, but the layout doesn't know which sub-layout/sub-page is loaded, making query composition more difficult. So it far it seems that data shared this way is rather limited/constrained. So my current approach is to have components/pages define fragments following a specific naming convention, and have the loaders that provide this data compose them. Examples for this is `SearchInput_AuthorizedUser` and `RepoPage_ResolvedRevision`.
This is not ideal because it has to be remembered to embed this fragment in the right place, but it's not worse than the current situation (where we often don't know where the query providing some data is defined).
- On demand data fetching: Not all data is necessary for rendering a page, some data is only fetched when in response to some user interaction. The layout/page loader should still be the place that executes the query, but instead of doing it on page load it passes a function to the page to fetch the data on demand. This way we can maintain data co-location and fetching in loaders. For an example see the `fetchCommitHistory` function.
NOTE: I expect there to be changes to this approach as we uncover more data loading requirements.
|
||
|---|---|---|
| .aspect | ||
| .buildkite | ||
| .github | ||
| .vscode | ||
| client | ||
| cmd | ||
| dev | ||
| doc | ||
| docker-images | ||
| internal | ||
| lib | ||
| migrations | ||
| monitoring | ||
| schema | ||
| testing | ||
| third_party | ||
| third-party-licenses | ||
| tools/release | ||
| ui/assets | ||
| wolfi-images | ||
| wolfi-packages | ||
| .bazel_fix_commands.json | ||
| .bazelignore | ||
| .bazeliskrc | ||
| .bazelrc | ||
| .bazelversion | ||
| .dockerignore | ||
| .editorconfig | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .graphqlrc.yml | ||
| .hadolint.yaml | ||
| .mailmap | ||
| .mocharc.js | ||
| .npmrc | ||
| .percy.yml | ||
| .pre-commit-config.yaml | ||
| .prettierignore | ||
| .stylelintignore | ||
| .stylelintrc.json | ||
| .swcrc | ||
| .tool-versions | ||
| .trivyignore | ||
| BUILD.bazel | ||
| CHANGELOG.md | ||
| CODENOTIFY | ||
| CONTRIBUTING.md | ||
| deps.bzl | ||
| doc.go | ||
| docsite_run.sh | ||
| eslint-relative-formatter.js | ||
| flake.lock | ||
| flake.nix | ||
| gen.go | ||
| go.mod | ||
| go.sum | ||
| graphql-schema-linter.config.js | ||
| LICENSE | ||
| LICENSE.enterprise | ||
| linter_deps.bzl | ||
| mockgen.temp.yaml | ||
| mockgen.test.yaml | ||
| mockgen.yaml | ||
| nogo_config.json | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| postcss.config.js | ||
| prettier.config.js | ||
| README.md | ||
| renovate.json | ||
| SECURITY.md | ||
| service-catalog.yaml | ||
| sg.config.yaml | ||
| sg.doctor.yaml | ||
| shell.nix | ||
| sonar-project.properties | ||
| stamp_tags.bzl | ||
| tsconfig.base.json | ||
| tsconfig.json | ||
| vitest.shared.ts | ||
| vitest.workspace.ts | ||
| WORKSPACE | ||
Docs •
Contributing •
Twitter •
Discord
Sourcegraph makes it easy to read, write, and fix code—even in big, complex codebases.
- Code search: Search all of your repositories across all branches and all code hosts.
- Code intelligence: Navigate code, find references, see code owners, trace history, and more.
- Fix and refactor: Roll out large-scale changes to many repositories at once and track big migrations.
Getting started
Development
Refer to the Developing Sourcegraph guide to get started.
Documentation
The doc directory has additional documentation for developing and understanding Sourcegraph:
- Project FAQ
- Architecture: high-level architecture
- Database setup: database best practices
- Go style guide
- Documentation style guide
- GraphQL API: useful tips when modifying the GraphQL API
- Contributing
License
This repository contains primarily non-OSS-licensed files. See LICENSE.