FoundKey/READING.md
Johann150 7821bbc28d
All checks were successful
ci/woodpecker/push/lint-client Pipeline was successful
ci/woodpecker/push/build Pipeline was successful
ci/woodpecker/push/lint-backend Pipeline was successful
ci/woodpecker/push/lint-foundkey-js Pipeline was successful
ci/woodpecker/push/lint-sw Pipeline was successful
ci/woodpecker/push/test Pipeline was successful
add more activitypub details to READING
2023-03-22 23:03:10 +01:00

99 lines
4.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file provides an overview of what functionality goes where.
As convention for this file, when a path is given that does **not** start with a slash, its a relative path.
Look further up in the section to find the "base path" it is relative to.
## backend
All the backend code is in `/packages/backend/src`.
### Database
For connecting to the database an ORM (objectrelational mapping) is used.
The ORM can map between database entries and TypeScript objects.
The type definitions for these objects can be found in `/packages/backend/src/models/`.
Definitions for individual objects are defined in `entities/`.
Some behaviour that is mostly used by the API is defined in `repositories/`.
These can be thought of like the database tables themselves.
Often there is functionality called "pack" in these, and by "packing" a database object you will get the API representation of that object.
Schemas for these API versions of the objects are defined in `schema/`.
### API
API stuff goes in `/packages/backend/src/server/api/`
All API routes are "mounted" in `index.ts`.
For this to work, the endpoint has to be tied into the respective path in `endpoints.ts`.
Endpoints are defined using a JSON object, and documentation is automatically generated using these objects.
The type definition for that object is also contained/documented in `endpoints.ts`.
Reading that file you can see that the endpoint behaviour is defined in `endpoints/`.
The paths below that directory should be the same as on the API.
Handling the API calls is done in `api-handler.ts`, which does some preprocessing of the request.
It then uses `authenticate.ts` to try to authenticate the user.
After that the actual endpoint code is run by `call.ts` after checking some more of the preconditions set by the endpoint definiton.
### ActivityPub
ActivityPub related code is in `/packages/backend/src/remote/activitypub/`
Both incoming and outgoing ActivityPub request are handled through queues, to e.g. allow for retrying a request when it fails, or spikes of many incoming requests.
#### Incoming Activities
Remote ActivityPub implementations will HTTP POST to the resource `/user/:userId/inbox` or `/inbox` (the latter is also known as the "shared inbox").
The behaviour for these routes is exactly the same: They add all the received data into the inbox queue.
This is defined in `/packages/backend/src/server/activitypub.ts`.
The inbox processor will do some basic things like verify signatures.
Incoming ActivityPub requests are processed by the code in `kernel/`.
The files/directories are generally named the same as the Activities that they process, which should help with orientation.
The entry point for processing an activity is `processOneActivity` in the `kernel/index.ts` file in that directory.
Parts of incoming activities may also be processed by `models/`.
#### Outgoing Activities
Outgoing activities are usually initiated in the logic of the API endpoints.
The bodies of outgoing ActivityPub requests are "rendered" using `renderer/`.
These files define several functions that are meant to be used together, e.g. `renderCreate(await renderNote(note, false), note)`.
The invocation of these functions is placed either in the API endpoints directly or in the services code.
The rendered bodies of the functions and the recipients are put into the deliver queue to be delivered.
### Services
If code for handling a task seems to big to e.g. do directly in an API endpoint or should be reused, it is probably placed in `/packages/backend/src/services/`.
### Queues
Code regarding queues is in `/packages/backend/src/queue/`.
Misskey defines several queues for processing things that might take longer in the background.
The queues themselves are defined in `index.ts`.
How the different queues are then processed is defined by the code in the `processors/` directory.
## client
All the client code is in `/packages/client/src/`.
The client uses Vue 3 and its Composition API, but there are also some older Options API components that have yet to be refactored (see CONTRIBUTING.md).
### Pages
If it is something you can navigate to, it is most likely a page.
These are defined in `/packages/client/src/pages/` and should be organized by the path you use to see them.
### Components
If it is not a page, it is probably a component.
Components can be things like the emoji picker, a tooltip, a widget.
Components can be combined to make bigger components or also pages.
They are defined in `/packages/client/src/components/`.
### Directives
Vue has "directives", e.g. you can add an attribute to a component like `v-tooltip`.
There are some built in directives like e.g. `v-if` and `v-for`.
Other custom directives are defined in `/packages/client/src/directives/`.
They are added to the Vue app in `index.ts` and their behavior is defined in separate files in the directory.