zetapush / zetapush-next-open-specification

Open specification for Next ZetaPush version
0 stars 0 forks source link

Init de projet #39

Closed damienld22 closed 6 years ago

damienld22 commented 6 years ago

Faire un point sur le fonctionnement de l'init projet. Répliquer le fonctionnement dans le tutorie

damienld22 commented 6 years ago

Voici une première proposition pour l'init avec la CLI :

Pré-requis

Init sans compte au préalable

zeta init myApp

Init avec seulement le front

zeta init myApp --front-only

Init avec compte déjà existant

zeta init myApp --user user@gmail.com --password password

Fichiers créés

Création d'une application d'exemple (Simple Hello World) à la mode Angular. Cela permet de voir comment démarrer et voir la simplicité d'utilisation.

server/index.js

Exemple de Custom Cloud Service.

class HelloWorldCustomService {

    /**
     *  Cloud function to say `Hello` to a specific name
     *  This cloud function return promise to be asynchrone
     */
    function helloByName(name) {
        return new Promise((resolve, reject) => {
            resolve(`Hello ${name} !`);
        });
    }
}

front/index.html

Simple interface pour notre cas d'exemple

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>ZetaPush example</title>
</head>

<body>
    <h1>Hello World By ZetaPush</h1>

    <button id="btnHelloWorld" onclick="sayHelloWorld()">Say Hello world</button>

    <hr>

    <input id="inputName" placeholder="Name">
    <button id="btnHelloUser">Say Hello to a specific name</button>

    <div id="result"></div>

    <script src="./index.js"></script>
</body>

</html>

front/index.js

Javascript associé pour le code d'exemple

// How to import a custom service ??
const { HelloWorldCustomService } = ZetaPush
const helloWorldService = new HelloWorldCustomService();

const btnSayHelloWorld = document.getElementById("btnHelloWorld");
const btnSayHelloUser = document.getElementById("btnHelloUser");
const inputName = document.getElementById("inputName");
const divResultCommands = document.getElementById("result");

/**
 * Function to say Hello World
 */
function sayHelloWorld() {
    divResultCommands.innerHTML += "<p>Hello World !</p>"
}

/**
 * Function to say Hello to a specific name
 */
function sayHelloByName() {
    helloWorldService.helloByName(inputName.value)
        .then((result) => {
            divResultCommands.innerHTML += result;
        })
        .catch((error) => {
            divResultCommands.innerHTML += `Failed to call custom Service : ${error.message}`;
        });
}

.package.json

Dépendances nécessaires pour utiliser ZetaPush

.zeta-conf.json

.gitignore

Seulement présent pour qu'on évite de pousser par défaut le couple login/mot de passe sur GitHub

.zeta-conf.json

Notes

aurelien-baudet commented 6 years ago

Je ne suis pas trop pour le fichier de conf .zeta-conf.json. Trop de fichiers cachés à la racine est vraiment une super mauvaise pratique (et là c'est pas parce que tout le monde le fait qu'on doit faire pareil si on peut proposer mieux). Au bout d'un moment, on ne sait plus où chercher la configuration parmi tous ces fichiers.

Je propose d'éviter de créer ce fichier et d'utiliser le package.json comme on l'a écrit dans la partie bootstrap :

Le package.json contient la configuration permettant le mapping des dossiers :

...
"zeta": {
  "front": "app/www",
  "server": "zeta-app"
}
...

Le fichier package.json est là pour la description du projet donc autant l'utiliser. Le nom de l'application devrait être le nom indiqué dans le champ name (https://docs.npmjs.com/files/package.json#name) dans le fichier package.json. Lors de la génération, autant placer le nom choisi dans ce champ.

Pour ce qui concerne le compte, je propose qu'on utilise un fichier mis dans le dossier home de l'utilisateur (c'est son compte zetapush donc potentiellement, il pourra avoir plusieurs apps pour un même compte). Bien sûr, on peut ajouter dans les logs une information indiquant qu'un fichier a été créé dans le home de l'utilisateur. En plus, on parle d'un compte temporaire qui va expirer donc autant le sortir du projet tant que l'utilisateur n'a pas rendu son compte/application permanente.

Pour l'exemple de code serveur, c'est pas mieux de montrer direct l'utilisation des async/await ?

damienld22 commented 6 years ago

J'ai pris en considération tes remarques, notamment pour le fichier de configuration où je suis d'accord. Voici la nouvelle version de la proposition :

Voici une première proposition pour l'init avec la CLI :

Pré-requis

Init sans compte au préalable

zeta init myApp

Init avec seulement le front

zeta init myApp --front-only

Init avec compte déjà existant

zeta init myApp --user user@gmail.com --password password

Fichiers créés

Création d'une application d'exemple (Simple Hello World) à la mode Angular. Cela permet de voir comment démarrer et voir la simplicité d'utilisation.

server/index.js

Exemple de Custom Cloud Service.

class HelloWorldCustomService {

    /**
     *  Cloud function to say `Hello` to a specific name
     *  This cloud function return promise to be asynchrone
     */
    function helloByName(name) {
        return new Promise((resolve, reject) => {
            resolve(`Hello ${name} !`);
        });
    }
}

front/index.html

Simple interface pour notre cas d'exemple

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>ZetaPush example</title>
</head>

<body>
    <h1>Hello World By ZetaPush</h1>

    <button id="btnHelloWorld" onclick="sayHelloWorld()">Say Hello world</button>

    <hr>

    <input id="inputName" placeholder="Name">
    <button id="btnHelloUser">Say Hello to a specific name</button>

    <div id="result"></div>

    <script src="./index.js"></script>
</body>

</html>

front/index.js

Javascript associé pour le code d'exemple

// How to import a custom service ??
const { HelloWorldCustomService } = ZetaPush
const helloWorldService = new HelloWorldCustomService();

const btnSayHelloWorld = document.getElementById("btnHelloWorld");
const btnSayHelloUser = document.getElementById("btnHelloUser");
const inputName = document.getElementById("inputName");
const divResultCommands = document.getElementById("result");

/**
 * Function to say Hello World
 */
function sayHelloWorld() {
    divResultCommands.innerHTML += "<p>Hello World !</p>"
}

/**
 * Function to say Hello to a specific name
 */
function sayHelloByName() {
    helloWorldService.helloByName(inputName.value)
        .then((result) => {
            divResultCommands.innerHTML += result;
        })
        .catch((error) => {
            divResultCommands.innerHTML += `Failed to call custom Service : ${error.message}`;
        });
}

.package.json

Dépendances nécessaires pour utiliser ZetaPush

Notes

ghoullier commented 6 years ago

Je vois un inconvénient à utiliser un fichier dans le home pour stocker les credentials. Si l'on travail pour 2 clients par example toto et tutu on va avoir besoin de 2 comptes.

Ce qu'on peut proposer et qui est utilisé par plusieurs outils notamment npm

/user/toto/home
├── .zetarc
└── MyZetaProject 
    ├── ...
    └──.zetarc

L'ordre de priorité de chargement est d'abord le .zetarc du projet puis celui du home

Le contenu du fichier de config correspond à ce qui est attendu par les variables d'environnement du worker.

raphael22 commented 6 years ago

Je pense qu'il faudrait préciser le contexte technique dans le titre et éventuellement la CLI.

zeta init=javascript myApp ...

Quid du stockage des credentials sur une autre stack ? Du cas par cas ? L'usage d'un zeta-conf.json par défaut ne me choque pas.

damienld22 commented 6 years ago

@ghoullier +1

@raphael22 Je suis d'accord pour préciser le contexte technique lors de l'utilisation de zeta init. Je pense aussi qu'il faut juste que pour le moment, JavaScript soit la stack par défaut. Sinon en cas d'absence de précision pour la stack technique un prompt peut éventuellement permettre à l'utilisateur de faire son choix dans la liste des stacks disponibles.

Pour le stockage des crédentials, tout se passera dans le fichier .zetarc selon moi.