/api/dart2-package-name-completion-data

[jonasfj]

GET /api/dart2-package-name-completion-data
{
  "packages": [
    ..., "retry", ... // ordered by popularity * likes * pub points
  ],
}

We filter out packages that:

• only supports Dart 1.x
• is flagged discontinued,
• is flagged unlisted.

Results ordered by some combination of popularity, likes and pub points.
We do not formally promise what ordering the API has, nor promise that the ordering won't change.

Nor do we make the API paging, if there are more packages than we can list in some future, then we return the N most important packages ranked by popularity, likes and pub points; with N being a high number something like 10k or 100k.

Note:

• it's important that we cache this response. I propose caching the gzipped response such that we can serve a large number of these requests rather efficiently.
• We should ensure that we support gzip for this request, and either reject requests that do not have the header accept-encoding: gzip, or support serving without gzip too.
• We could store the value of this in GCS and redirect to a public bucket, this would indeed be a very reasonable thing to do.
• I'm open to better path suggestions than /api/dart2-package-name-completion-data, but I think it's worthwhile making sure that the API end-point is specific to:
  • Clients who want to do code-completion for package names,
  • Dart 2.x clients -- because Dart 1.x packages are irrelevant, and when one day Dart 3 becomes a thing we might want to use a new end-point for this (though I can be dissuaded from this argument).

[jonasfj]

I could also be convinced we should call this something like:

• /api/package-name-completion
• /api/package-names/completion-data
• /api/completion/package-names-dart2
• /api/package-name-completion

[sigurdm]

I don't think we need dart2 in the name.

We know nothing about how dart3 will be - let's plan for it when we know more.

If a new endpoint is really needed we can always call the new endpoint something with dart3.

/api/package-name-completion sounds good to me.

[isoos]

I don't think we need dart2 in the name.

+1

/api/package-name-completion

I'd expect such endpoint to complete a package name that I provide via a query parameter. Anything against /api/package-names/completion-data or /api/package-name-completion-data ?

[sigurdm]

Anything against /api/package-names/completion-data or /api/package-name-completion-data ?

Nope - good point!

[DanTup]

I saw a merged PR for this - is it already available somewhere I can test/dev against, or will it only be available once deployed live? Thanks!

[isoos]

@DanTup: It is not yet deployed, we'll update this issue once it was done. (possibly this week)

[DanTup]

Perfect, thanks!

[isoos]

This is now live.