L'environnement de développement NOFLO est une application Web côté client compatible hors ligne qui aide les utilisateurs à créer et à exécuter des programmes basés sur des flux construits avec des systèmes compatibles FBP tels que NOFLO, MSGFLO, IMGFLO et Microflo. L'environnement de développement NOFLO est disponible sous la licence du MIT.
Ce projet a été rendu possible par 1205 bailleurs de fonds Kickstarter. Vérifiez le projet Changelog pour les nouvelles fonctionnalités et autres modifications.
FlowHub est une version hébergée de l'environnement de développement NOFLO.
Si vous souhaitez simplement créer des applications, nous vous recommandons d'utiliser cette version au lieu de construire la vôtre à partir de la source.
Même si l'interface utilisateur lui-même est construit avec NOFLO, il ne parle pas directement avec NOFLO pour la course et la construction de graphiques. Au lieu de cela, il utilise le protocole de réseau FBP qui lui permet de parler à n'importe quel système FBP compatible. Actuellement, plus de 5 temps d'exécution sont connus pour fonctionner.
En mettant en œuvre le protocole dans votre exécution, vous pouvez le programmer avec NOFLO UI. Si vous utilisez WebSockets ou WebBrTC comme transport, vous n'avez pas besoin de changer quoi que ce soit sur NOFLO UI. Vous pouvez également ajouter de la prise en charge d'autres transports.
Le moyen le plus simple de transmettre l'utilisateur les informations de connexion de votre exécution est le mode en direct . Avec cela, les détails de la connexion sont transmis à l'application via des paramètres URL, comme ceci:
http://app.flowhub.io#runtime/endpoint?protocol%3Dwebsocket%26address%3Dws%3A%2F%2F127.0.0.1%3A3569
Les paramètres pris en charge pour le point de terminaison comprennent:
protocol : le transport du protocole FBP à utiliser pour la connexion. Les valeurs possibles incluent websocket , iframe et webrtcaddress : URL à utiliser pour la connexion. Peut être par exemple ws:// url pour les websockets, ou l'identifiant de l'URL et de la connexion signaleur pour webrtcsecret : secret à utiliser pour communiquer avec l'exécutionCes URL peuvent être affichées sur la sortie de la ligne de commande ou fournies à l'utilisateur via un autre mécanisme. Voir une démonstration vidéo de l'ouverture de l'application en mode live via une balise NFC.
On peut éventuellement ajouter des modèles de composants, une surbrillance de syntaxe et un lien «Démarrer» pour les nouveaux temps d'exécution.
./runtimeinfo/myruntime.yaml . ExempleUniquement nécessaire si vous voulez pirater sur noflo ui lui-même. Pas nécessaire pour créer des applications avec FBP.
Un dockerfile a été fourni qui peut être utilisé pour construire / exécuter facilement l'interface utilisateur Noflo. Vous pouvez également obtenir une image construite automatiquement à partir de Docker Hub.
docker build -t noflo-ui . docker run -d -p 9999:80 noflo-uiUne fois qu'il est construit et le serveur en cours d'exécution, vous pouvez accéder à l'interface utilisateur sur http: // localhost: 9999 / index.html
Pour pouvoir travailler sur l'interface utilisateur Noflo, vous avez besoin:
Allez dans le dossier de paiement et exécutez:
$ npm install
Cela vous fournira toutes les dépendances de développement nécessaires. Vous pouvez maintenant créer une nouvelle version en fonctionnant:
$ npm run build
Vous devez exécuter cette commande en tant qu'administrateur sur Windows.
Servez l'interface utilisateur à l'aide d'un serveur Web, puis ouvrez l'URL dans un navigateur Web. Exemple:
$ npm start
Si vous préférez, vous pouvez à la place démarrer un processus de serveur de développement WebPack qui fera une reconstruction chaque fois que l'un des fichiers change:
$ npm run dev
Une fois qu'il est construit et le serveur en cours d'exécution, vous pouvez accéder à l'interface utilisateur sur http://localhost:9999/index.html
En plus de ce projet, l'autre référentiel d'intérêt est le widget de l'éditeur de graphiques The-Graph utilisé pour l'édition de flux.
À haut niveau, l'architecture Noflo-UI suit les conventions Redux adaptées à Noflo. Voici à quoi ressemble le flux de données principal:
Store OUT -> IN Middleware # Store sends actions together with application state to middleware
Middleware NEW -> ACTION Store # Middleware can trigger new actions
Middleware PASS -> IN Reduce # Actions go from middleware to reducers
Reduce OUT -> STATE Store # Reducers produce a new state object that gets sent to store
Reduce OUT -> STATE View # State also goes to the view
View ACTION -> ACTION Store # View can trigger actions
Le flux réel est plus détaillé. Vous pouvez le visualiser et le modifier dans graphs/main.fbp .
Remarque: Les prix décrits ci-dessous sont l'architecture que nous visons. Nous refactorisons les parties du système pour s'adapter à cette architecture au fur et à mesure que nous les modifions. Toutes les nouvelles fonctionnalités doivent être implémentées en suivant cette architecture.
Le composant du magasin garde une trace du dernier état d'application. Lorsqu'il reçoit de nouvelles actions, il envoie le sort au middleware et à la chaîne de réducteur avec le dernier état d'application.
Le middleware Noflo-UI est des composants ou des graphiques qui peuvent interagir avec des actions particulières. Chaque action passe par la chaîne de Middlewares, et chaque middleware a deux options sur la gestion d'une action:
Le middleware est où les effets secondaires liés à l'état d'application sont gérés. Cela peut inclure la conversation avec les services Web externes, les communications d'exécution FBP et le chargement ou l'enregistrement de données vers le INDEXEDDB local. Le middleware reçoit l'état d'application actuel et ne peut en lire plus, mais ils ne manipulent que l'état que par la manière de créer de nouvelles actions.
Certains middleware peuvent également agir en tant que générateurs, créant de nouvelles actions basées sur une entrée externe.
L'approche du middleware est expliquée plus en détail dans cet article de blog.
Le travail des réducteurs est de recevoir des actions et d'apporter des modifications à l'état de demande. Les réducteurs doivent en fait être des fonctions pures, où le même état d'entrée et la même combinaison d'action produit toujours le même nouvel état.
La couche de vue de l'application est implémentée sous forme d'éléments polymères. La vue d'application reçoit l'objet d'état produit par les réducteurs.
Les interactions utilisateur dans la vue de l'application ne doivent pas apporter des modifications à l'état direct. Au lieu de cela, la vue d'application peut déclencher de nouvelles actions en tirant des événements en polymère. Ceux-ci sont ensuite traités par le middleware et les réducteurs, provoquant le changement de l'état.
NOFLO UI utilise GitHub pour l'authentification. Nous avons une application par défaut configurée pour travailler sur http://localhost:9999 . Si vous souhaitez servir votre interface utilisateur NOFLO à partir d'une URL différente, vous devez enregistrer votre propre application OAuth avec eux. Assurez-vous de faire correspondre la politique de redirection de GitHub.
Pour activer votre propre application OAuth, définissez les variables d'environnement suivantes et reconstruisez NOFLO UI:
$NOFLO_OAUTH_CLIENT_ID : ID client de votre application github oauth$NOFLO_OAUTH_CLIENT_REDIRECT : rediriger l'URL de votre application github oauthPour gérer la partie secrète du client OAuth du processus de connexion, il existe deux options:
Il s'agit de l'option facile pour le développement local de l'interface utilisateur NOFLO. Créez simplement le secret du client OAuth dans l'application NOFLO UI en le définissant via la variable d'environnement $NOFLO_OAUTH_CLIENT_SECRET .
Remarque: Cela signifie que quiconque ayant accès à cette version de l'interface utilisateur NOFLO pourra lire le secret de votre client. Ne faites jamais cela avec une URL accessible au monde. C'est bien pour les constructions de développement locales uniquement.
Vous pouvez déployer une instance de l'application Gatekeeper Node.js pour gérer l'échange de token OAuth pour vous. Configurez l'emplacement de Gatekeeper dans votre version de l'interface utilisateur Noflo avec $NOFLO_OAUTH_GATE d'environnement.
Il s'agit du mécanisme le plus sécurisé, car seul le serveur Gatekeeper doit connaître le secret du client.