clojurice
1.0.0
Um aplicativo inicial de partida para aplicativos da Web de pilha completa no Clojure
Você precisará de inicialização instalada, bem como Java 1.8+ e PostgreSQL 9.6+. O Docker também é recomendado para o desenvolvimento local.
A melhor maneira de iniciar um novo projeto é simplesmente clicar no botão "Use este modelo" na parte superior da página do Github. Como alternativa, se você não deseja usar o Github para o seu projeto, pode baixar o mestre .zip, extraí -lo localmente e git init a partir daí.
Para iniciar o ambiente de desenvolvimento:
docker-compose up &
boot dev
Isso iniciará a compilação de back -end e front -end, com o site hospedado no localhost: 7000. A documentação da API também pode ser encontrada em http: // localhost: 7000/api-docs
Para construir o projeto para um Uberjar fazer:
boot build <target-dir>
Um Uberjar chamado "app- (versão) -standalone.jar" será encontrado no diretório de destino. O número da versão do projeto pode ser definido no build.boot .
A configuração é tratada por meio de arquivos EDN no diretório resources/config . base.edn fornece a configuração base que se aplica a todos os ambientes, enquanto os dois perfis, dev.edn e prod.edn são carregados em seus respectivos ambientes e têm precedência sobre base.edn . Além disso, no tempo de carregamento, os arquivos de configuração são verificados no esquema Config localizado no domain.cljc .
A configuração do front -end é fornecida através da API na GET /api/config e fornece um subconjunto da configuração, conforme definido no esquema FrontendConfig em domain.cljc .
A API de back-end principal pode ser encontrada no api.clj e é escrita em Compojure-Api. Há também um tutorial sobre como trabalhar com a Sintaxe Compojure-Api.
A injeção de dependência e o manuseio dos componentes do sistema são tratados via sistema e o modelo Raamwerk. É isso que permite a recarga ao vivo do back -end, mas também orquestra todos os componentes do aplicativo (servidores estáticos e API, configuração, db, etc.). Os principais construtores para estes são encontrados no app.systems . Existe uma função base build-system que pega um nome de perfil de configuração e produz o mapa do sistema base para esse perfil e, em seguida, funções que produzem os sistemas Prod e dev.
De nota mais importante é o :site-endpoint , que é o componente que lida com rotas estáticas como o índice principal e aponta para app.routes/site , e :api-endpoint , que é o componente da API REST e aponta para app.api/api-routes . Cada uma dessas funções leva um único argumento (chamado sys por convenção), que é um subconjunto do mapa do sistema, contendo as chaves listadas como dependências no vetor passado para component/using . Portanto, para que um componente esteja disponível para o ponto final, sua chave precisa ser adicionada a esse vetor.
As migrações de banco de dados são tratadas com um componente RAGTIME, configurado para executar automaticamente no servidor Iniciar ou recarregar. As migrações estão localizadas em resources/db/migrations , que contém arquivos .up.sql e .down.sql para migrações, nomeados de acordo com o esquema descrito na documentação do Ragtime. O mapa de configuração do ragtime está disponível no mapa do sistema como :migrations e, portanto, pode ser acessado a partir do REPL ou de qualquer componente que o herda como uma dependência. Este mapa pode ser passado para as funções no ragtime.repl para as migrações de corrida ou reversão manualmente.
Para abstração SQL, o honeysql é usado no topo do clojure.java.jdbc. O HoneyyySQL fornece uma maneira de escrever consultas SQL como mapas, que podem ser construídos e compostos como qualquer outro mapa de Clojure, e depois formatados no SQL para chamar com o driver JDBC. Uma função auxiliar, app.query/make-query é fornecida no query.sql para envolver a chamada para o driver JDBC, portanto, é preciso apenas fornecer o mapa do sistema e o mapa de consulta SQL para obter um resultado.
O front-end é construído com reagente, usando uma combinação de despacho multimethod para renderizar cada visualização e roteamento do lado do cliente com o BIDE. Como tal, a adição de uma nova sub-visualização requer algumas etapas importantes para lembrar:
app.views , ou seja. app.views.foo em cljs/app/views/foo.cljsapp.views.dispatch/dispatch-view e crie seu próprio Multimethod para despachar a partir de uma chave adequada, ou seja. :app.foo . O método deve levar dois argumentos, o primeiro é a chave em si, o segundo é qualquer parâmetros do URI.index.cljs .router.cljs . O estado principal do aplicativo é mantido em um átomo de reagente compartilhado em app.state/app-state . Um espaço para nome de app.api também é fornecido para chamadas de API comuns.
Uma nota importante sobre o roteamento: ao vincular a outro componente dentro do aplicativo, é melhor usar a função app.router/app-link , pois isso liga o sistema de roteamento. Os HREFs normais funcionarão, mas forçará uma página recarregada, que será mais lenta e também redefinirá o estado-estado.
Além do front -end e do back -end, também incluem alguns espaços de nome comuns via arquivos .cljc no src/cljc/app , que permitem que dados e funções importantes sejam compartilhados na frente e nas costas. O mais importante deles é app.domain em src/cljc/app/domain.cljc . Isso fornece os esquemas de dados comuns para o aplicativo, incluindo o esquema para os arquivos de configuração.
Foi fornecido um docker-compose.yml para iniciar uma configuração básica do Postgres com as configurações padrão descritas acima com um simples docker-compose up .
A configuração padrão abrirá as conexões NREPL para ambas as frontend na porta 6809 e back -end na porta 6502.
Há também um elemento adicional de reagente-dev-tools adicionado à página no modo dev que fornece reflexão ao estado de aplicativo atual.
É fornecida uma tarefa de boot cljfmt que será executada cljfmt em todos os arquivos no diretório SRC. As tarefas check e fix do Boot-CLJFMT também estão disponíveis diretamente e podem ser usadas para ser executada contra arquivos ou diretórios individuais, conforme necessário.
Tanto o código de front -end quanto de back -end foram configurados para recarregar automaticamente as alterações do arquivo. Existe até uma sugestão de áudio útil para notificá -lo assim que uma reconstrução for concluída.
Observe que o sistema de servidor de back -end completo será reiniciado apenas quando determinados arquivos mudarem. Isso é configurado através da tarefa build.boot Dev com o parâmetro :files na etapa do system .
Alguns testes básicos de integração foram fornecidos. Você pode executá-los com boot test ou com boot test-watch , que iniciará um observador e executará todos os testes na alteração do arquivo.
Os testes incluem testes de navegador via etaoin, e você também precisará instalar o geckowebdriver baseado em Firefox. Informações e links sobre como fazer isso podem ser encontrados aqui. No Mac, ele pode ser instalado com brew install geckodriver , no Ubuntu com firefox-geckowebdriver ou no Windows com scoop install geckodriver . É claro que você também precisará de Chrome.
Este aplicativo é baseado originalmente no System-Template com algumas orientações adicionais do Tenzing.
Desenvolvido por Annaia Danvers (@jarcane). Desenvolvimento possibilitado por Futurice.
Copyright (c) 2018 Annaia Danvers. O código é distribuído sob a licença pública Eclipse v2.0 ou qualquer versão posterior. Para obter mais informações, consulte LICENSE no diretório raiz.
