Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Meta-issue: Deployment

Offen
  • Stimmt etwas nicht?
#359 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
sql
Bereich
backend, cloud, security

Rechercherichtung

Es sind keine Implementierungsdateien oder Tests identifiziert. Beginne damit, die Fragen zur Bereitstellung für Connect aus Positron und Workbench zu prüfen, einschließlich Quarto-Berichten, Shiny-Anwendungen, Versionierung, Verbindungsmodi für das Backend und Anmeldedatenmodi. Als abgeschlossen gilt die Aufgabe, wenn das Projekt über ein abgestimmtes Bereitstellungsdesign und einen abgegrenzten Implementierungsplan verfügt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

integration

This issue exist to track discussions around deployment. For the initial phase we will focus on Connect deployment from Positron and Workbench as this is the stack we control - others may think about deployment in other context if they wish to do so in the mean time.

Key questions:

What does ggsql deployment look like?

Right now deployment would be in the form of a quarto report or some sort. However, the R bindings also support deploying shiny applications with ggsql code inside.

I do envision a mode where you deploy a single .ggsql file and you get an embeddable visualisation. Depending on how ggsql's own multiplot support evolves this may end up being a viable dashboard solution, though I'm not sure SQL provides the best syntax for layout work. If not, do we need a new format for dashboard-y deployments or does quarto serve that need?

For deployment, we also need to think about ggsql versioning. We are in a blissful state of just having to declare a single version and not black pit of 100s of dependencies, but declare it we must somehow. Is this a Connect responsibility or should ggsql itself do something about this?

What kind of backend connection is kept - with what kind of credentials?

Our happy path is that an analyst sits on their computer, developing an analysis using ggsql either in Positron or Workbench. They have their credentials set up so they can connect to e.g. Snowflake and visualise that data directly. They arrive at an end product and hit deploy. The deployment target is send to Connect, along with the credentials and everything just magically works. We must strive for this to be the case!

However, I can see multiple modes of connection with a backend depending on the needs, and also multiple modes of credentials:

Connection modes:

  • Keep a connection to the original backend, updates to the database is reflected in the visualisation whenever it is presented
  • Cache the main data sources in a local DuckDB instance and query against that in the backend - this may be updated periodically but not real-time
  • Embed the data in a "static" deployment (i.e. connection is severed)

Credential mode:

  • Use the authors credentials/credentials provided specifically for this deployment. All visits will use the same credentials and it is up to the analyst to not expose confidential information in the visualization
  • Visitor brings their own credentials and these are used when querying the database and creating the plot. The visitor only sees data for which they have been granted access. This mode explicitly requires the first connection mode described above
Vorherrschende Sprache
Rust
Sterne
565
Forks
31
Ø Merge
2 T. 12 Std.
Gemergte PRs (30 T.)
16

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus posit-dev/ggsql

Alle Issues in posit-dev/ggsql

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.