Comment partager des packages d'assistance entre les fonctions Go Cloud sans publication publique ?

Sous-packages dans Go sur Google Cloud Functions

Question :

Comment pouvez-vous utiliser des packages d'assistance dans un Go Cloud Function tout en garantissant qu'elles sont accessibles à travers plusieurs fonctions au sein du même projet (sans les publier publiquement) ?

Réponse :

L'adoption des modules Go, le système avancé de gestion des dépendances de Go, offre une solution efficace pour travailler avec des sous-packages. Les modules vous permettent d'opérer en dehors de GOPATH et de gérer précisément les versions de vos dépendances.

Essentiellement, les modules permettent de définir des groupes de packages Go avec un préfixe de chemin d'importation cohérent. Au sein de votre fonction Cloud, vous pouvez exploiter cette fonctionnalité pour importer d'autres packages dans votre module.

Il est important de noter que votre fonction déployée doit résider à la racine de votre module. Considérez la structure de fichiers suivante à titre d'exemple :

.
├── cmd
│   └── main.go # For testing purposes, can import and configure your function.
├── function.go # Imports "example.com/foo/helperpackage"
├── function_test.go
├── go.mod # Module "example.com/foo"
└── helperpackage
    └── helper.go

Dans cette configuration, votre fonction réside dans function.go et est testée par function_test.go. Ces composants appartiennent au module "example.com/foo" et function.go peut importer "example.com/foo/helperpackage".

De plus, un répertoire cmd facilite les tests locaux. En important "example.com/foo", vous pouvez initialiser un serveur HTTP qui gère les requêtes à l'aide de votre gestionnaire de fonctions. L'exemple de code suivant illustre cette approche :

package main

import (
    "log"
    "net/http"

    "example.com/foo"
)

func main() {
    http.Handle("/HelloHTTP", foo.HelloHTTP)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Bien que l'utilisation d'un répertoire de fournisseurs puisse obtenir un résultat similaire, les sous-packages devraient être copiés individuellement dans le répertoire de fournisseurs (en utilisant leur chemin d'importation complet), ce qui rend entretien fastidieux. En tant que telle, cette approche n'est pas couramment utilisée pour les sous-packages.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!