Arkitektura

Alamin kung saan nakatira ang code at anong mga patakaran ang umiiral bago ka magbago ng malaking bagay.

Ang maikling bersyon

Ang HolyArrs ay isang Go program na may built-in na web app. Ito ang nagseserbisyo ng web app at ng JSON API sa port 6262, at nag-iimbak ng data nito sa 2 SQLite file sa config folder. Tumatawag ito sa mga downloader, Pinagkukunan (sa pamamagitan ng Jackett o Prowlarr), media server, mga channel ng alerto at sa metadata server ng HolyArrs.

Sundan ang isang request. May humiling ng pelikula sa Explore.

1. Itinatala ng requests ang hiling.
2. Pagkatapos maaprubahan, hihingi ang movies ng mga release sa sources.
3. Ibinibigay ng mediafiles ang puntos ng bawat isa ayon sa Mga patakaran sa pagpili.
4. Ipinapadala ng downloads ang pinakamahusay sa downloader.
5. Kapag tapos na, ini-import ng mediafiles ang file.
6. Sinasabihan ang mediaservers at alerts.

Mapa ng code

app/backend/cmd/holyarrs/            main.go starts the program; wiring.go builds the modules and joins them
app/backend/internal/<module>/       one flat folder per module
app/backend/internal/core/           plumbing every module may use
app/backend/tools/                   dev-only programs
app/frontend/                        the SvelteKit web app; embed.go bundles its build
app/frontend/src/routes/<page>/      thin pages that combine module parts
app/frontend/src/lib/<module>/       each module's web code
app/frontend/src/lib/ui/             parts used by 2 or more modules, and nothing else
app/frontend/src/lib/core/           server client, app state, helpers
app/tests/                           end-to-end tests (Playwright)
deploy/                              the Dockerfile and release scripts
docs/                                guides and these pages

Nasa root ng repo ang go.mod dahil hindi maaabot ng go:embed ang parent folder.

Saan makikita ang mga bagay

Gusto mong baguhin	Tingnan sa
Paano napipili ang isang release	internal/mediafiles
Isang downloader client	internal/downloads, contract test sa internal/downloads/conformance_test.go
Isang channel ng alerto	internal/alerts
Sign-in, mga user, API key	internal/accounts
Ang wizard sa unang takbo	internal/setup, app/frontend/src/routes/welcome
Pag-import ng tapos na file (unpack, tag, pagtutugma)	internal/importer
Mga folder ng Aklatan, pag-ampon at pagpapalit ng pangalan	internal/library
Paano pinipili at inaayos ang mga row at shelf	internal/suggest
Aling mga bahagi ng app ang naka-on	internal/core/parts
Address ng isang page	app/frontend/src/routes/
Isang migration	internal/core/database/migrations/
Ang Docker image	deploy/Dockerfile

Ang mga patakaran

Ang mga check sa app/backend/tools/structurecheck ang nagpapabagsak ng build kapag may nasira. Patakbuhin ang mga ito gamit ang linya sa Testing.

• Ayos ng layer. Ang isang module ay nag-i-import lang ng mga module sa mas mababang layer, at ang root package lang nila. Hindi nag-i-import sa isa’t isa ang mga module sa parehong layer.
• Pagtawag pataas. Kapag may kailangan ang mas mababang module mula sa mas mataas, ang mas mataas ang magpapasa ng simpleng data pababa, o ang mas mababa ang magde-define ng maliit na interface na pupunuan ng wiring.go.
• Sa bahay lang ang SQL. Ang mga store*.go file lang ng isang module ang may hawak ng SQL, at sa sarili lang nitong mga table. Para basahin ang mga row ng ibang module, tawagin ang service nito.
• Sa core ang mga shared table. Abutin ang settings, schedules, secrets, jobs at events sa pamamagitan ng mga helper ng core.
• Isang labasan lang. Bawat tawag sa labas ay dumadaan sa core/outbound.
• Mga tampok na hindi pa bukas ay nagrerehistro ng switch sa core/startup. Habang naka-off ito, wala ang route at itinatago ng page ang tampok.
• Walang grab-bag na package. Walang util, common, shared o helpers.

Ang ayos ng layer ay nasa Modules.

Para sa mga eksperto

Sa loob ng isang module

Pare-pareho ang mga pangalan ng file ng bawat backend module.

File	Laman
routes.go	Mga API route, bawat isa ay may kailangang permiso
service.go at mga topic file	Logic na tinatawag ng ibang module
store.go, store_<topic>.go	Lahat ng SQL para sa sariling mga table ng module
types.go	Mga record ng module

Sa panig ng web, ang lib/<module>/ ay may index.ts (ang puwedeng gamitin ng ibang module), ang mga Svelte part nito at ang mga test ng mga iyon, at api.ts at state.svelte.ts lang kapag may sarili itong mga tawag o state.

Mga core package

Ang core ay plumbing. Walang tuntunin ng produkto rito at wala itong ini-import na module.

Package	Laman
core/database	Pagbubukas at pag-migrate ng dalawang SQLite file, mga query helper, helper ng settings at events, shared na field ng row, pagpuputol ng history
core/files	Mga helper ng file at folder, libreng espasyo sa disk
core/releasename	Quality, group at numero ng episode mula sa pangalan ng release
core/outbound	Ang nag-iisang paraan para tumawag sa mga server sa labas, may pagsusuri ng address
core/secrets	Ang imbakan ng key at pag-ikot ng key
core/logs	Ang log ng app at mga tala ng crash
core/jobs	Ang pila ng gawain, mga iskedyul at ang mga loop na nagre-restart pagkatapos ng crash
core/webserver	Plumbing ng router, URL base, compression, live push
core/startup	User na pagpapatakbuhan, mode na mababa ang memory, mga switch ng mga tampok na hindi pa bukas, limitasyon ng memory, mga bahagi
core/parts	Ang mga switch ng bahagi na tinatanong ng bawat module bago ito mag-serve o tumakbo
core/model	Mga shared na type tulad ng actor at subject

Kapag kailangang hawakan ng core ang data ng isang module, nagrerehistro ang module ng hook sa core sa wiring.go. Ganito gumagana ang pag-ikot ng key.

Data

File	Laman
holyarrs.db	Ang Aklatan, mga kahilingan, settings at lahat ng iba pang mahalaga
holyarrs-events.db	History at iba pang row ng pangyayari. Lumalaki ito at pinuputol nang hindi ginagalaw ang pangunahing file

Ang mga migration ay may-numerong SQL file sa core/database/migrations/main at core/database/migrations/events. Tumatakbo ang mga ito sa pagsisimula.

Kaugnay

• Modules
• Contributing
• Testing