Done:

[x] /zoekt-indexserver/configuration - Serves zoekt-indexserver configuration: https://github.com/sourcegraph/sourcegraph/pull/47710
[x] /zoekt-indexserver/repos - Lists repos: https://github.com/sourcegraph/sourcegraph/pull/47710
[x] /zoekt-indexserver/repo-rank - Ranks repos: https://github.com/sourcegraph/sourcegraph/pull/47710
[x] /zoekt-indexserver/document-ranks - Ranks documents: https://github.com/sourcegraph/sourcegraph/pull/47710
[x] /zoekt-indexserver/update-index-status - Handles index status updates: https://github.com/sourcegraph/sourcegraph/pull/47710

Status Unknown

telemetry

[ ] /telemetry - Serves telemetry data
- Is this being used anywhere?
  - I don't see a lot of relevant search results.
  - The frontend internal client method for this is referred to in one other function, but that function is never called: https://sourcegraph.com/github.com/sourcegraph/sourcegraph@9239bdd421622026aaa772fc7a9f470ceecf230b/-/blob/internal/eventlogger/event_logger.go?L49:6-49:14#tab=references
  - The telemetry code in our frontend appears to be using graphQL, and not this route: https://sourcegraph.com/github.com/sourcegraph/sourcegraph@9239bdd/-/blob/client/browser/src/shared/tracking/eventLogger.tsx?L134:9-134:17

Code intel stuff

[ ] /lsif-upload - Handles LSIF upload requests
[ ] /scip-upload - Handles SCIP upload requests
[ ] /scip-upload-exists - Handles SCIP upload exists requests

Are these APIs exposed externally (or have mirror implementations for an externally exposed one)? If so, there might not be a lot of value in converting these over.

Won't do:

git operations

/git/info/refs & /git/upload-pack: These routes are invoked by the git binary itself, so it doesn't make sense to convert these to gRPC since git can't speak it.

graphql

/graphql - Serves internal graphQL API that is [used in a few places](context:global repo:^github.com/sourcegraph/sourcegraph$ "internal/graphql").

This doesn't make sense to convert over to use gRPC since it uses the same transport mechanisms (JSON over HTTP) that our public-facing graphQL API uses.

compute stream

.internal/compute/stream: Handles compute stream requests

This is a mirror image of the existing public facing compute-stream handler: https://github.com/sourcegraph/sourcegraph/blob/7503ac810ce42c7280fd39c2d6b07923c93a3d45/enterprise/cmd/frontend/internal/compute/streaming/stream.go#L29

So, it doesn't make sense to convert only the internal one to use gRPC.

ping

/ping - Handles ping requests

This doesn't appear to be used anymore. I didn't see any calls to /ping when I inspected 1 minute's worth of traffic on sourcegraph.com (https://sourcegraph.slack.com/archives/C04HCK4K3DL/p1676495299928659) .

Cody and code search didn't reveal any references to this route.

This isn't used for health checks either, as sourcegraph-frontend's liveness / readiness endpoints use the logic from the debugserver package: https://github.com/sourcegraph/sourcegraph/blob/9b3d612bd257089cc73f3981990836241311066c/internal/debugserver/debug.go#L119-L120

streaming search

/.internal/search/stream

The internal stream search endpoint /.internal/search/stream is used by batch changes https://github.com/sourcegraph/sourcegraph/blob/43ebbb4021b803eb71e16ef3391797caf6d6d55c/enterprise/internal/batches/service/workspace_resolver.go#L405-L442

It's also a mirror image of the public facing one that uses HTTP:

Since we're not changing any public facing APIs to use gRPC as part of the scope of this project, I don't think it makes sense to use a gRPC implementation that is only used for the internal version of this API.

camdencheek commented 1 year ago

Removed LogEvent, ExternalURL, SendEmail, and ExternalServices. Migrated conf

eseliger commented 8 months ago

@ggilmore do you think we can close this tracking issue out, or create separate tickets for what still needs to be done here?

sourcegraph / sourcegraph-public-snapshot

gRPC: migrate internal frontend APIs #46525