Experimente!
O BlogSearch é uma ferramenta de blog que permite um mecanismo de pesquisa sem serviços externos.
É como o DocSearch, mas para blogs.
Mais tecnicamente, o BlogSearch é um mecanismo de pesquisa de texto completo puro do cliente para sites estáticos, alimentados pelo SQLite compilado à WebAssembly.
Pesquisa puramente do lado do cliente
Nenhum servidor para manter. Sem custo de serviço.
Fácil. É construído para blogs e sites estáticos em mente.
Suporta estruturas populares de blog:
Jekyll
Gatsby
Hugo
… E quaisquer sites estáticos!
SQLITE-WASM: Execute o SQLite na web, usando o WebAssembly. Este projeto é feito para as necessidades do BlogSearch.
O fluxo de trabalho é consistente em duas etapas: 1. Você constrói um arquivo de índice | |
1. Construa um arquivo de índice | 2. Habilite a pesquisa |
O arquivo de índice
Em seguida, você copia o | Sua página da web deve carregar o mecanismo do BlogSearch. Existe apenas um motor disponível:
Carregue o mecanismo usando a tag <Cript> ou no arquivo JavaScript. Quando o motor buscar o arquivo |
Ao longo do projeto, os termos "índice" e "banco de dados" são frequentemente misturados, mas eles significam o mesmo arquivo sqlite .db.wasm na maior parte do caso. |
Jekyll (Jekyll-BlogSearch)
Gatsby (Gatsby-Plugin-BlogSearch)
Hugo (BlogSearch-Crawler)
Rastreador genérico (BlogSearch-Crawler)
Os usuários devem configurar uma ferramenta de construção de índice para coletar o valor dos campos para trabalhar corretamente no mecanismo de pesquisa.
A ferramenta de construção de índices deve coletar os seguintes campos padrão para cada postagem:
title : O título do post.
body : o conteúdo da postagem.
url : O link URL para o post.
categories : Uma lista de categorias ( , ) separada por vírgula a que o post pertence.
tags : uma lista de tags ( , ) separada por vírgula que a postagem possui.
Os usuários podem configurar todos os campos usando as seguintes propriedades:
| Exemplo | Resultado |
|---|---|
| |
{
...other field options...
categories: {
+ disabled: true,
},
} | |
No exemplo a seguir, o tamanho do arquivo de índice | |
{
...other field options...
body: {
+ hasContent: false,
},
} | |
| |
{
...other field options...
url: {
+ indexed: false,
},
} | |
Sua ferramenta de construção de índices pode ter opções específicas da ferramenta para o campo (por exemplo, opção parser para o blogsearch-crawler). Consulte a documentação da sua ferramenta de construção de índices para obter detalhes. |
< link rel =" stylesheet " href =" https://cdn.jsdelivr.net/npm/[email protected]/dist/basic.css " />
< script src =" https://cdn.jsdelivr.net/npm/[email protected]/dist/blogsearch.umd.js " > </ script >
< script src =" https://cdn.jsdelivr.net/npm/[email protected]/dist/worker.umd.js " > </ script >
< input id =" blogsearch_input_element " type =" search " placeholder =" Search Text " class =" form-control " />
< script >
blogsearch ( {
dbPath : 'your_index_file.db.wasm' ,
inputSelector : '#blogsearch_input_element' ,
} ) ;
</ script >Para obter mais detalhes e opções, vá para o subdiretório do BlogSearch.
O mecanismo de pesquisa basicamente é o sqlite com a extensão FTS5, compilada ao WebAssembly. O SQLITE FTS5 oferece o algoritmo de classificação BM25 embutido para a funcionalidade de pesquisa. Como o SQLite é o mecanismo de banco de dados mais portátil, você também pode abrir qualquer arquivo de banco de dados SQLite na Web! Graças ao SQLite, podemos escrever plugins facilmente para o BlogSearch com apenas algumas consultas SQL em diferentes linguagens de programação.
.db.wasm é recomendado Índice de Extensão de Arquivos? Não é um arquivo binário da WebAssembly. Por que não apenas .db ? Tentei fazê-lo .db , mas há um grande problema: o arquivo de índice não é compactado pelo servidor da web. Os Serviços Populares da Web do blog (especialmente as páginas do GitHub) geralmente servem um arquivo .db como application/octet-stream e não comprimem o arquivo. Ao mentir de que é um arquivo binário da WebAssembly .wasm , os servidores o reconhecem como application/wasm e o enviam comprimidos.
A compactação é importante porque reduz significativamente o tamanho do arquivo. Vi que o tamanho é reduzido para 1/3.
Para evitar o problema "mas funciona na minha máquina", é fortemente recomendável usar o Docker para criar tarefas.
Embora esse repositório seja um monorepo, onde cada subprojetos possui scripts de construção própria, você pode executar facilmente tarefas no diretório raiz.
| Se você deseja criar apenas um subproject específico, vá para o subdiretório e execute os comandos de fios. |
As ferramentas necessárias são as seguintes:
GNU Make (v4.2 ou superior é recomendado, seja avisado para os usuários do macOS!)
Docker
Docker-Compose
fio
Embora seja um projeto JS Makefile é usado porque é muito mais configurável e suporta a construção em paralelo.
Para versões específicas do NodeJS usadas no projeto, consulte o Dockerfile.
# Or yarn install, without docker
make install-in-docker # Or yarn install, without docker
make lib-in-dockermake start-in-docker
# You can access the demo page via 0.0.0.0:9000 # Or make test, without docker
make test-in-docker
# Run it in parallel
make test-in-docker -j4 --output-sync=target| Isso levará muito tempo! (~ 30 mintas) |
# It is highly recommended to use docker here
make examples-in-docker && make demo-in-docker| Isso levará muito tempo! (~ 30 mintas) |
# Or make all, without docker
make all-in-docker
# Or
# Parallel builds. This reduces the build time almost an half on my machine.
make all-in-docker -j4 --output-sync=targetmake clean
# Then run any commands above make bash-in-dockerEste projeto é inspirado no DocSearch e possui uma reimplementação no TypeScript.
Fora isso, o projeto é a licença do MIT. Consulte a licença