Versuchen Sie es!
BlogSearch ist ein Blogging -Tool, das eine Suchmaschine ohne externe Dienste ermöglicht.
Dies ist wie DocSearch, aber für Blogs.
Technisch gesehen ist BlogSearch eine reine clientseitige Suchmaschine mit Volltext für statische Websites, die von SQLite mit der WebAssembly kompiliert wird.
Rein clientseitige Suche
Kein Server zum Verwalten. Keine Servicekosten.
Einfach. Es ist für Blogs und statische Websites erstellt.
Unterstützt beliebte Blog -Frameworks:
Jekyll
Gatsby
Hugo
… Und alle statischen Websites!
SQLite-WASM: Führen Sie SQLite im Internet mit WebAssembly aus. Dieses Projekt wird für die Bedürfnisse von BlogSearch gemacht.
Der Workflow besteht aus zwei Schritten: 1. Sie erstellen eine Indexdatei | |
1. Erstellen Sie eine Indexdatei | 2. Aktivieren Sie die Suche |
Die Indexdatei
Anschließend kopieren Sie das generierte | Ihre Webseite sollte die BlogSearch -Engine laden. Es gibt nur einen Motor:
Laden Sie die Engine mit <Script> Tag oder in JavaScript -Datei. Sobald die Engine die Datei |
Während des gesamten Projekts werden die Begriffe "Index" und "Datenbank" oft gemischt, aber sie bedeuten, dass die gleiche SQLite .db.wasm -Datei im optimalen Fall. |
Jekyll (Jekyll-Blogsearch)
Gatsby (Gatsby-Plugin-Blogsearch)
Hugo (Blogsearch-Crawler)
Generisches Crawler (BlogSearch-Crawler)
Benutzer sollten ein Indexbuilding -Tool konfigurieren, um den Wert der Felder zu sammeln, um die Suchmaschine ordnungsgemäß zu bearbeiten.
Das Indexbuilding -Tool sollte die folgenden Standardfelder für jeden Beitrag sammeln:
title : Der Titel des Beitrags.
body : Der Inhalt des Beitrags.
url : Der URL -Link zum Beitrag.
categories : Eine von Kommas getrennte ( , ) Liste von Kategorien, zu denen der Beitrag gehört.
tags : Eine von Kommas getrennte ( , ) Liste von Tags, die der Beitrag hat.
Benutzer können alle Felder mit den folgenden Eigenschaften konfigurieren:
| Beispiel | Ergebnis |
|---|---|
| |
{
...other field options...
categories: {
+ disabled: true,
},
} | |
Im folgenden Beispiel wird die Größe der Indexdatei | |
{
...other field options...
body: {
+ hasContent: false,
},
} | |
| |
{
...other field options...
url: {
+ indexed: false,
},
} | |
Ihr Indexbuilding-Tool Mai verfügt über Toolspezifische Optionen für das Feld (z. B. parser Option für BlogSearch-Crawler). Weitere Informationen finden Sie in der Dokumentation Ihres Indexbuilding -Tools. |
< 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 >Weitere Details und Optionen finden Sie in das Unterverzeichnis der BlogSearch.
Die Suchmaschine ist im Grunde genommen SQLite mit der FTS5 -Erweiterung, die mit WebAssembly zusammengestellt wird. Der SQLite FTS5 bietet den integrierten BM25-Ranking-Algorithmus für die Suchfunktionalität. Da SQLite die tragbarste Datenbank -Engine ist, können Sie auch alle SQLite -Datenbankdateien im Web öffnen! Dank SQLite können wir mit nur wenigen SQL -Abfragen in verschiedenen Programmiersprachen problemlos Plugins für BlogSearch schreiben.
.db.wasm empfohlener Dateierweiterungsindex? Es ist keine Binärdatei mit WebAssembly. Warum nicht nur .db ? Ich habe versucht, es zu machen .db aber es gibt ein großes Problem: Die Indexdatei wird vom Webserver nicht gzip komprimiert. Beliebte Blog-Webdienste (insbesondere Github-Seiten) bedienen normalerweise eine .db Datei als application/octet-stream und komprimieren die Datei nicht. Indem die Server sie als application/wasm erkennen und sie komprimiert werden, erkennen die Server eine Webassembly -Binärdatei .wasm
Komprimierung ist wichtig, da sie die Dateigröße erheblich reduziert. Ich habe gesehen, dass die Größe auf 1/3 reduziert ist.
Um zu vermeiden, dass „es auf meinem Maschinenproblem funktioniert“, wird dringend empfohlen, Docker zum Erstellen von Aufgaben zu verwenden.
Obwohl dieses Repository ein Monorepo ist, in dem jedes Unterprojekt über eigene Build -Skripte verfügt, können Sie Aufgaben im Stammverzeichnis problemlos ausführen.
| Wenn Sie nur ein bestimmtes Teilprojekt erstellen möchten, gehen Sie zum Unterverzeichnis und führen Sie Garnbefehle aus. |
Die erforderlichen Werkzeuge sind die folgenden:
Gnu make (v4.2 oder höher wird empfohlen, für macOS -Benutzer gewarnt werden!)
Docker
Docker-Compose
Garn
Obwohl es sich um ein JS -Projekt handelt, wird Makefile verwendet, da es viel konfigurierter ist und das Gebäude parallel unterstützt.
Für bestimmte NodeJS -Versionen, die im Projekt verwendet werden, lesen Sie bitte die 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| Dies wird viel Zeit in Anspruch nehmen! (~ 30 Mintues) |
# It is highly recommended to use docker here
make examples-in-docker && make demo-in-docker| Dies wird viel Zeit in Anspruch nehmen! (~ 30 Mintues) |
# 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-dockerDieses Projekt ist von DocSearch inspiriert und hat eine Neuauflagen in TypeScript.
Davon abgesehen ist das Projekt MIT -Lizenz. Siehe Lizenz