clojurice
1.0.0
Una aplicación de inicio obstinada para aplicaciones web de pila completa en Clojure
Necesitará el arranque instalado, así como Java 1.8+, y PostgreSQL 9.6+. Docker también se recomienda para el desarrollo local.
La mejor manera de iniciar un nuevo proyecto es simplemente hacer clic en el botón "Use esta plantilla" en la parte superior de la página GitHub. Alternativamente, si no desea usar GitHub para su proyecto, puede descargar el maestro .zip, extraerlo localmente y git init desde allí.
Para iniciar el entorno de desarrollo, haga:
docker-compose up &
boot dev
Esto iniciará la compilación de backend y frontend, con el sitio alojado en Localhost: 7000. La documentación de API también se puede encontrar en http: // localhost: 7000/api-docs
Para construir el proyecto a un Uberjar Do:
boot build <target-dir>
En el directorio de destino se encontrará un Uberjar llamado "App- (Versión) -Standalone.JAR". El número de versión del proyecto se puede configurar en build.boot .
La configuración se maneja a través de archivos EDN en el directorio resources/config . base.edn proporciona la configuración base que se aplica a todos los entornos, mientras que los dos perfiles, dev.edn y prod.edn están cargados en sus respectivos entornos y tienen prioridad sobre base.edn . Además, en el tiempo de carga, los archivos de configuración se verifican con el esquema Config ubicado en domain.cljc .
La configuración frontend se proporciona a través de la API en GET /api/config , y proporciona un subconjunto de la configuración como se define en el esquema FrontendConfig en domain.cljc .
La API de backend principal se puede encontrar en api.clj y está escrita en CompoJure-API. También hay un tutorial sobre cómo trabajar con la sintaxis de CompoJure-API.
La inyección de dependencia y el manejo del componente del sistema se manejan a través del sistema y el modelo Raamwerk. Esto es lo que permite la recarga en vivo del backend, pero también orquesta todos los componentes de la aplicación (servidores estáticos y API, config, db, etc.). Los principales constructores para estos se encuentran en app.systems . Existe una función base build-system que toma un nombre de perfil de configuración y produce el mapa del sistema base para ese perfil, y luego funciona que produce los sistemas PROD y DEV.
De la nota más importante es :site-endpoint , que es el componente que maneja las rutas estáticas como el índice principal y apunta a app.routes/site , y :api-endpoint , que es el componente para la API REST, y apunta a app.api/api-routes . Cada una de estas funciones toma un solo argumento (llamado sys por convención), que es un subconjunto del mapa del sistema, que contiene las teclas enumeradas como dependencias en el vector pasado al component/using . Entonces, para que un componente esté disponible para el punto final, su clave debe agregarse a este vector.
Las migraciones de bases de datos se manejan con un componente Ragtime, configurado para ejecutarse automáticamente en Start Star o Recargar del servidor. Las migraciones se encuentran en resources/db/migrations , que contienen archivos .up.sql y .down.sql para migraciones, nombrados de acuerdo con el esquema descrito en la documentación de Ragtime. El mapa de configuración de Ragtime está disponible en el mapa del sistema como :migrations y, por lo tanto, se puede acceder desde el replicador o desde cualquier componente que lo hereda como una dependencia. Este mapa se puede pasar a las funciones en ragtime.repl para ejecutar o hacer retroceder migraciones manualmente.
Para la abstracción SQL, Honeysql se usa en la parte superior de Clojure.java.jdbc. Honeysql proporciona una forma de escribir consultas SQL como mapas, que por lo tanto se pueden construir y componer como cualquier otro mapa de Clojure, y luego formateado en SQL para llamar con el controlador JDBC. Se proporciona una función auxiliar, app.query/make-query en query.sql para envolver la llamada al controlador JDBC, por lo que uno solo necesita proporcionar el mapa del sistema y el mapa de consulta SQL para obtener un resultado.
El frontend está construido con reactivo, utilizando una combinación de envío de metro de metro para representar cada vista y enrutamiento del lado del cliente con Bide. Como tal, agregar una nueva subvisión requiere algunos pasos que son importantes para recordar:
app.views , es decir. app.views.foo en cljs/app/views/foo.cljsapp.views.dispatch/dispatch-view Multimethod, y cree su propio MultiMethod para despachar desde una clave adecuada, es decir. :app.foo . El método debe tomar dos argumentos, el primero es la clave en sí, la segunda son los parámetros del URI.index.cljs .router.cljs . El estado de la aplicación principal se mantiene en un átomo de reactivo compartido en app.state/app-state . También se proporciona un espacio de nombres app.api para llamadas API comunes.
Una nota importante con respecto al enrutamiento: cuando se vincula a otro componente dentro de la aplicación, es mejor usar la función app.router/app-link a medida que esto se inclina en el sistema de enrutamiento. HREFS normal funcionará, pero forzará una recarga de páginas, que será más lenta y también restablecerá el estado de la aplicación.
Además del frontend y el backend, también se incluyen algunos espacios de nombres comunes a través de archivos .cljc en src/cljc/app , que permiten que los datos y funciones clave se compartan por delante y posterior. El más importante de estos es app.domain en src/cljc/app/domain.cljc . Esto proporciona los esquemas de datos comunes para la aplicación, incluido el esquema para los archivos de configuración.
Se ha proporcionado un Docker-Compose.ML para iniciar una configuración básica de Postgres con configuraciones predeterminadas descritas anteriormente con un docker-compose up simple.
La configuración predeterminada abrirá conexiones NREPL a ambos frontend en el puerto 6809 y backend en el puerto 6502.
También hay un elemento adicional de reactivo-Tools agregado a la página en modo DEV que proporciona reflexión al estado de la aplicación actual.
Se proporciona una tarea boot cljfmt que ejecutará CLJFMT en todos los archivos en el directorio SRC. Las tareas check y fix de Boot-CLJFMT también están disponibles directamente, y se pueden usar para ejecutarse con archivos o directorios individuales según sea necesario.
Tanto el código frontend como el código de backend se han configurado para recargar automáticamente los cambios de archivo. Incluso hay una señal de audio útil para notificarle una vez que se haga una reconstrucción.
Tenga en cuenta que el sistema completo del servidor de backend solo se reiniciará por completo cuando ciertos archivos cambien. Esto se configura a través de la tarea build.boot Dev con el parámetro :files al paso del system .
Se han proporcionado algunas pruebas de integración básicas. Puede ejecutarlos con boot test o con boot test-watch , que iniciará un observador y ejecutará todas las pruebas en el cambio de archivo.
Las pruebas incluyen pruebas de navegador a través de Etaoin, y también deberá instalar el geckowebdriver , con sede en Firefox. La información y los enlaces sobre cómo hacer esto se puede encontrar aquí. En Mac se puede instalar con brew install geckodriver , en Ubuntu con firefox-geckowebdriver o en Windows con scoop install geckodriver . Por supuesto, también necesitará Chrome.
Esta aplicación se basa originalmente en la plantilla del sistema con alguna orientación adicional de Tenzing.
Desarrollado por Annaia Danvers (@Jarcane). Desarrollo hecho posible por Futurice.
Copyright (c) 2018 Annaia Danvers. El código se distribuye bajo la licencia pública de Eclipse v2.0 o en cualquier versión posterior. Para obtener más información, consulte LICENSE en el directorio raíz.
