clojurice
1.0.0
Une application de démarrage d'opinion pour les applications Web complètes à Clojure
Vous aurez besoin de démarrage installé, ainsi que Java 1.8+ et PostgreSQL 9.6+. Docker est également recommandé pour le développement local.
La meilleure façon de démarrer un nouveau projet est de simplement cliquer sur le bouton "Utiliser ce modèle" en haut de la page GitHub. Alternativement, si vous ne souhaitez pas utiliser GitHub pour votre projet, vous pouvez télécharger le maître .zip, l'extraire localement et git init à partir de là.
Pour démarrer l'environnement de développement, faites:
docker-compose up &
boot dev
Cela commencera à la fois la compilation backend et frontend, avec le site hébergé sur localhost: 7000. La documentation de l'API peut également être trouvée sur http: // localhost: 7000 / api-docs
Pour construire le projet sur un Uberjar, faites:
boot build <target-dir>
Un Uberjar appelé "app- (version) -standalone.jar" se trouve dans le répertoire cible. Le numéro de version du projet peut être défini dans build.boot .
La configuration est gérée via des fichiers EDN dans le cadre du répertoire resources/config . base.edn fournit la configuration de base qui s'applique à tous les environnements, tandis que les deux profils, dev.edn et prod.edn sont chargés dans leurs environnements respectifs et ont priorité sur base.edn . De plus, sur le temps de chargement, les fichiers de configuration sont vérifiés par rapport au schéma Config situé dans domain.cljc .
La configuration du frontend est fournie via l'API à GET /api/config , et fournit un sous-ensemble de la configuration tel que défini dans le schéma FrontendConfig dans domain.cljc .
L'API principale principale se trouve dans api.clj et est écrite dans Compojure-API. Il existe également un tutoriel sur la travail avec la syntaxe Compojure-API.
L'injection de dépendance et la manipulation des composants du système sont gérées via le système et le modèle Raamwerk. C'est ce qui permet le rechargement en direct du backend, mais orchestre également tous les composants de l'application (serveurs statiques et API, config, db, etc.). Les principaux constructeurs de ceux-ci se trouvent dans app.systems . Il existe une fonction de base build-system qui prend un nom de profil de configuration et produit la carte du système de base pour ce profil, puis les fonctions qui produisent les systèmes Prod et Dev.
La note la plus importante est le :site-endpoint , qui est le composant qui gère les itinéraires statiques comme l'index principal et pointe vers app.routes/site , et :api-endpoint , qui est le composant de l'API REST, et pointe vers app.api/api-routes . Chacune de ces fonctions prend un seul argument (appelé sys par convention), qui est un sous-ensemble de la carte du système, contenant les clés répertoriées comme des dépendances dans le vecteur transmis au component/using . Ainsi, pour qu'un composant soit disponible pour le point final, sa clé doit être ajoutée à ce vecteur.
Les migrations de la base de données sont gérées avec un composant Ragtime, configuré pour s'exécuter automatiquement sur le démarrage du serveur ou le rechargement. Les migrations sont situées dans resources/db/migrations , qui contient des fichiers .up.sql et .down.sql pour les migrations, nommés selon le schéma décrit dans la documentation Ragtime. La carte de configuration de Ragtime est disponible à partir de la MAP System As :migrations et peut donc être accessible à partir du REPL ou à partir de tout composant qui l'hérite de la dépendance. Cette carte peut être transmise aux fonctions de ragtime.repl pour courir ou faire reculer les migrations manuellement.
Pour l'abstraction SQL, Honeysql est utilisé au-dessus de Clojure.java.jdbc. HoneySQL fournit un moyen d'écrire des requêtes SQL comme cartes, qui peuvent ainsi être construites et composées comme toute autre carte Clojure, puis formatée en SQL pour appeler avec le pilote JDBC. Fonction d'assistance, app.query/make-query est fourni dans query.sql pour emballer l'appel au pilote JDBC, il suffit donc de fournir la carte système et la carte de requête SQL pour obtenir un résultat.
Le frontend est construit avec un réactif, en utilisant une combinaison de répartition multiméthode pour rendre chaque vue et le routage côté client avec bide. En tant que tel, l'ajout d'une nouvelle sous-vue nécessite quelques étapes qui sont importantes à retenir:
app.views , c'est-à-dire. app.views.foo dans cljs/app/views/foo.cljsapp.views.dispatch/dispatch-view et créez votre propre multiméthode pour expédier à partir d'une clé appropriée, c'est-à-dire. :app.foo . La méthode doit prendre deux arguments, le premier est la clé elle-même, la seconde est tous les paramètres de l'URI.index.cljs .router.cljs . L'état d'application principal est conservé dans un réactif partagé atome sur app.state/app-state . Un espace de noms app.api est également fourni pour les appels API communs.
Une note importante concernant le routage: lors du lien vers un autre composant de l'application, il est préférable d'utiliser la fonction app.router/app-link car cela s'accroche au système de routage. HREFS normal fonctionnera, mais forcera un rechargement de page, qui sera plus lent et réinitialisera également l'application.
En plus du frontend et du backend, il existe également des espaces de noms communs via des fichiers .cljc dans src/cljc/app , qui permettent de partager les données et les fonctions clés par avant et arrière. Le plus important d'entre eux est app.domain dans src/cljc/app/domain.cljc . Cela fournit les schémas de données communs pour l'application, y compris le schéma des fichiers de configuration.
Un docker-compose.yml a été fourni pour démarrer une configuration postgres de base avec des paramètres par défaut décrits ci-dessus avec un simple docker-compose up .
La configuration par défaut ouvrira les connexions NRepl à la fois à Frontend au port 6809 et au backend au port 6502.
Il existe également un élément de réactif-dev-outils supplémentaire ajouté à la page en mode Dev qui fournit une réflexion à l'état de l'application actuel.
Une tâche boot cljfmt est fournie qui exécutera CLJFMT sur tous les fichiers du répertoire SRC. Les tâches check et fix de Boot-Cljfmt sont également disponibles directement et peuvent être utilisées pour s'exécuter contre des fichiers ou des répertoires individuels selon les besoins.
Le code Frontend et Backend ont été configurés pour recharger automatiquement les modifications du fichier. Il y a même un signal audio utile pour vous informer une fois qu'une reconstruction est terminée.
Notez que le système complet du serveur backend ne sera redémarré que lorsque certains fichiers changent. Ceci est configuré via la tâche de développement build.boot avec le paramètre :files à l'étape system .
Certains tests d'intégration de base ont été fournis. Vous pouvez les exécuter avec boot test , ou avec boot test-watch , qui démarrera un observateur et exécutera tous les tests sur la modification du fichier.
Les tests incluent les tests de navigateur via Etaoin, et vous devrez également installer le geckowebdriver à base de Firefox. Des informations et des liens sur la façon de procéder peuvent être trouvés ici. Sur Mac, il peut être installé avec brew install geckodriver , sur Ubuntu avec firefox-geckowebdriver , ou sur Windows avec scoop install geckodriver . Vous aurez bien sûr besoin de Chrome.
Cette application est basée à l'origine sur le système système avec quelques indications supplémentaires de Tenzing.
Développé par Annaia Danvers (@jarcane). Développement rendu possible par Futurice.
Copyright (C) 2018 Annaia Danvers. Le code est distribué sous la licence publique Eclipse v2.0 ou toute version ultérieure. Pour plus d'informations, voir LICENSE dans le répertoire racine.
