Pull based model and content negotiation?

Aperta
  • Qualcosa non va?
#59 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
aws
Ambito
backend-api-design, cloud

Direzione di ricerca

Start by mapping the three existing package URLs and how the catalog currently publishes HTML to S3. Read the proposed AWS CloudFront, Accept, Content-Type, and Cache-Control approach, then determine the required API and deployment design. Done means one package URL can serve both HTML and s-expression data while preserving editable operations and useful caching.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Right now, for the package agile (chosen arbitrarily), the following URLs are used to access information about the package:

  • http://pkgs.racket-lang.org/package/agile - S3-backed view-only HTML of agile package info
  • http://pkgd.racket-lang.org/pkgn/package/agile - Editable HTML of agile package not served by S3
  • http://pkgo.racket-lang.org/pkg/agile http://pkgs.racket-lang.org/pkg/agile - Raw Racket data of agile package not served by S3 and used by raco pkg tools

Additionally, every so often (not sure 100% on the exact timing) the package server publishes the HTML of pkgd in S3 so it is served by pkgs. This is a push based model — S3 acts as an independent copy of the catalog that the Racket server is responsible for updating as needed. I think it would be simpler and easier for all systems involved if the catalog used a pull based model with AWS CloudFront, content negotiation, and appropriate use of caching headers.

In this proposed setup, there would be one URL per package that served both HTML and s-exp data using the Accept and Content-Type headers, and CloudFront would act as a reverse proxy serving cached copies of package data based on the origin server's Cache-Control headers. This would remove the need for three different URLs for the same server, as CloudFront could serve cached GET requests while forwarding POST, PUT, and DELETE requests. CloudFront can serve GETs even if the origin server is down, so we'd still be able to offer a read-only view of the catalog during an outage.

This would also allow tools other than browser to cache package data and interact with the HTML view of packages. A raco pkg user could open an installed package's catalog entry without needing to know anything other than the URL the package was installed from. Scribble could do the same (this came up in discussion of racket/racket#1797) to link package mentions in docs to their catalog entries. Additionally, raco pkg would be able to reuse the same caching headers exposed to AWS to locally cache package data.

Lingua principale
Racket
Stelle
13
Fork
18
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di racket/racket-pkg-website

Tutte le issue di racket/racket-pkg-website

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.