docs: cleanup adn nits
This commit is contained in:
0xSage
parent
af62e0fc69
commit
2a93b1a47d
@ -23,6 +23,8 @@ Jan can be used to build a variety of AI use cases, at every level of the stack:
|
||||
|
||||
### Modules
|
||||
|
||||
Jan is comprised of system-level modules that mirror OpenAI’s, exposing similar APIs and objects
|
||||
|
||||
- Modules are modular, atomic implementations of a single OpenAI-compatible endpoint
|
||||
- Modules can be swapped out for alternate implementations
|
||||
- The default `messages` module persists messages in thread-specific `.json`
|
||||
@ -38,8 +40,7 @@ Jan can be used to build a variety of AI use cases, at every level of the stack:
|
||||
|
||||
### Local Filesystem
|
||||
|
||||
- Jan runs on top of standard structure of local files on user's filesystem
|
||||
- This allows for composability and tinkerability
|
||||
Jan use the local filesystem for data persistence, similar to VSCode. This allows for composability and tinkerability.
|
||||
|
||||
```sh=
|
||||
/janroot # Jan's root folder (e.g. ~/jan)
|
||||
@ -89,7 +90,9 @@ Jan can be used to build a variety of AI use cases, at every level of the stack:
|
||||
|
||||
### Jan: a "global" assistant
|
||||
|
||||
Jan provides `/jan`, a default assistant that is available to users out-of-the-box. It is a generic assistant to illustrate power of Jan. In the future, it will support additional features e.g. multi-assistant conversations
|
||||
Jan ships with a default assistant "Jan" that lets users chat with any open source model out-of-the-box.
|
||||
|
||||
This assistant is defined in `/jan`. It is a generic assistant to illustrate power of Jan. In the future, it will support additional features e.g. multi-assistant conversations
|
||||
|
||||
- Your Assistant "Jan" lets you pick any model that is in the root /models folder
|
||||
- Right panel: pick LLM model and set model parameters
|
||||
3
docs/docs/docs/02_quickstart.md
Normal file
3
docs/docs/docs/02_quickstart.md
Normal file
@ -0,0 +1,3 @@
|
||||
---
|
||||
title: Quickstart
|
||||
---
|
||||
@ -1,202 +0,0 @@
|
||||
---
|
||||
title: Anatomy of 👋Jan
|
||||
---
|
||||
|
||||
This page explains all the architecture of [Jan](https://Jan/).
|
||||
|
||||
## Synchronous architecture
|
||||
|
||||
|
||||
|
||||
### Overview
|
||||
|
||||
The architecture of the Jan application is designed to provide a seamless experience for the users while also being modular and extensible.
|
||||
|
||||
### BackEnd and FrontEnd
|
||||
|
||||
**BackEnd:**
|
||||
|
||||
- The BackEnd serves as the brain of the application. It processes the information, performs computations, and manages the main logic of the system.
|
||||
|
||||
:::info
|
||||
This is like an [OS (Operating System)](https://en.wikipedia.org/wiki/Operating_system) in the computer.
|
||||
:::
|
||||
|
||||
**FrontEnd:**
|
||||
|
||||
- The FrontEnd is the interface that users interact with. It takes user inputs, displays results, and communicates with the BackEnd through Inter-process communication bi-directionally.
|
||||
|
||||
:::info
|
||||
This is like [VSCode](https://code.visualstudio.com/) application
|
||||
:::
|
||||
|
||||
**Inter-process communication:**
|
||||
|
||||
- A mechanism that allows the BackEnd and FrontEnd to communicate in real time. It ensures that data flows smoothly between the two, facilitating rapid response and dynamic updates.
|
||||
|
||||
### Plugins and Apps
|
||||
**Plugins:**
|
||||
|
||||
In Jan, Plugins contains all the core features. They could be Core Plugins or [Nitro](https://github.com/janhq/nitro)
|
||||
|
||||
- **Load:** This denotes the initialization and activation of a plugin when the application starts or when a user activates it.
|
||||
|
||||
- **Implement:** This is where the main functionality of the plugin resides. Developers code the desired features and functionalities here. This is a "call to action" feature.
|
||||
|
||||
- **Dispose:** After the plugin's task is completed or deactivated, this function ensures that it releases any resources it uses, providing optimal performance and preventing memory leaks.
|
||||
|
||||
:::info
|
||||
This is like [Extensions](https://marketplace.visualstudio.com/VSCode) in VSCode.
|
||||
:::
|
||||
|
||||
**Apps:**
|
||||
|
||||
Apps are basically Plugin-like. However, Apps can be built by users for their own purposes.
|
||||
|
||||
> For example, users can build a `Personal Document RAG App` to chat with specific documents or articles.
|
||||
|
||||
With **Plugins and Apps**, users can build a broader ecosystem surrounding Jan.
|
||||
|
||||
## Asynchronous architecture
|
||||
|
||||
|
||||
|
||||
### Overview
|
||||
|
||||
The asynchronous architecture allows Jan to handle multiple operations simultaneously without waiting for one to complete before starting another. This results in a more efficient and responsive user experience. The provided diagram breaks down the primary components and their interactions.
|
||||
|
||||
### Components
|
||||
|
||||
#### Results
|
||||
|
||||
After processing certain tasks or upon specific triggers, the backend can broadcast the results. This could be a processed data set, a calculated result, or any other output that needs to be shared.
|
||||
|
||||
#### Events
|
||||
|
||||
Similar to broadcasting results but oriented explicitly towards events. This could include user actions, system events, or notifications that other components should be aware of.
|
||||
|
||||
- **Notify:**
|
||||
|
||||
Upon the conclusion of specific tasks or when particular triggers are activated, the system uses the Notify action to send out notifications from the **Results**. The Notify action is the conduit through which results are broadcasted asynchronously, whether they concern task completions, errors, updates, or any processed data set.
|
||||
|
||||
- **Listen:**
|
||||
|
||||
Here, the BackEnd actively waits for incoming data or events. It is geared towards capturing inputs from users or updates from plugins.
|
||||
|
||||
#### Plugins
|
||||
|
||||
These are modular components or extensions designed to enhance the application's functionalities. Each plugin possesses a "Listen" action, enabling it to stand by for requests emanating from user inputs.
|
||||
|
||||
### Flow
|
||||
|
||||
1. Input is provided by the user or an external source.
|
||||
2. This input is broadcasted as an event into the **Broadcast event**.
|
||||
3. The **BackEnd** processes the event. Depending on the event, it might interact with one or several Plugins.
|
||||
4. Once processed, **Broadcast result** can be sent out asynchronously through multiple notifications via Notify action.
|
||||
|
||||
## Jan workflow
|
||||
|
||||
|
||||
|
||||
### Overview
|
||||
|
||||
The architecture of the Jan desktop application is structured into four primary modules: "Prompt Template," "Language Model," "Output Parser," and "Apps." Let's break down each module and understand its components.
|
||||
|
||||
### Prompt Template
|
||||
|
||||
This is where predefined templates are stored. It sets the format and structure for user interactions. It contains:
|
||||
|
||||
- **Character's definition:**
|
||||
|
||||
Definitions of various characters or entities that may be interacted with or invoked during user requests (e.g., name, personality, and communication style).
|
||||
|
||||
- **Model's definition:**
|
||||
|
||||
Definitions related to the different language models (e.g., objectives, capabilities, and constraints)
|
||||
|
||||
- **Examples:**
|
||||
|
||||
Sample inputs and outputs for guidance. If given good examples, LLM could enable basic reasoning or planning skills.
|
||||
|
||||
- **Input:**
|
||||
|
||||
The actual user query or request that is being processed.
|
||||
|
||||
### Large Language Model
|
||||
|
||||
This processes the input provided.
|
||||
|
||||
- **Local models:**
|
||||
|
||||
These are the downloaded models that reside within the system. They can process requests without the need to connect to external resources.
|
||||
|
||||
- **OpenAI:**
|
||||
|
||||
This will connect you with OpenAI API, allowing the application to utilize powerful models like GPT-3.5 and GPT-4.
|
||||
|
||||
:::info
|
||||
To use OpenAI models, you must have an OpenAI account and secret key. You can get your [OpenAI key](https://platform.openai.com/account/api-keys) here.
|
||||
:::
|
||||
|
||||
- **Custom Agents:**
|
||||
|
||||
These are user-defined or third-party models that can be integrated into the Jan system for specific tasks.
|
||||
|
||||
### Output Parser
|
||||
|
||||
Language models produce textual content. However, often, there's a need for more organized data instead of plain text. This is achieved using output parsers.
|
||||
|
||||
- **Parser:**
|
||||
|
||||
This component ensures that the output conforms to the desired structure and format, removing unwanted information or errors.
|
||||
|
||||
### Apps
|
||||
|
||||
This represents applications or extensions that can be integrated with Jan.
|
||||
|
||||
- **Characters:** Characters or entities that can be utilized within the applications.
|
||||
|
||||
- **Models:** Different Large Language Models, Large Multimodal Models, and Stable Diffusion models that the apps might use.
|
||||
|
||||
- **RAG:** Represents a "Retrieval Augmented Generation" functionality, which helps in fetching relevant data and generating responses based on it.
|
||||
|
||||
## Jan Platform
|
||||
|
||||
|
||||
|
||||
### Overview
|
||||
|
||||
The architecture of Jan can be thought of as a layered system, comprising of the FrontEnd, Middleware, and BackEnd. Each layer has distinct components and responsibilities, ensuring a modular and scalable approach.
|
||||
|
||||
#### FrontEnd
|
||||
The **FrontEnd** is the visible part of Jan that interacts directly with the user.
|
||||
|
||||
- **Controller:** This is the main control unit of the FrontEnd. It processes the user's inputs, handles UI events, and communicates with other layers to fetch or send data.
|
||||
|
||||
- **Apps:** This represents applications or extensions that can be integrated with Jan.
|
||||
|
||||
- **Execute Request** act as the initial triggers to initiate processes within the application.
|
||||
|
||||
#### Middleware
|
||||
|
||||
It's a bridge between the FrontEnd and BackEnd. It's responsible for translating requests and ensuring smooth data flow.
|
||||
|
||||
- **SDK:** Stands for Software Development Kit. It provides a set of tools, libraries, and guidelines for developers to build and integrate custom applications or features with Jan.
|
||||
|
||||
- **Core:** It's tasked with managing the connections between the FrontEnd and BackEnd. It ensures data is routed correctly and efficiently between the two.
|
||||
|
||||
- **Local Native:** Refers to the connectors that enable communication with local services or applications. This will use your own hardware to ddeploy models.
|
||||
|
||||
- **Cloud Native:** As the name suggests, these connectors are tailored for cloud-based interactions, allowing Jan to leverage cloud services or interact with other cloud-based applications.
|
||||
|
||||
:::info
|
||||
The Middleware communicates with the BackEnd primarily through **IPC** for Local and **Http** for Cloud.
|
||||
:::
|
||||
|
||||
#### BackEnd
|
||||
|
||||
It is responsible for data processing, storage, and other core functionalities.
|
||||
|
||||
- **Plugins:** Extendable modules that can be added to the Jan system to provide additional functionalities or integrations with third-party applications.
|
||||
|
||||
- **Nitro:** This is a high-performance engine or a set of services that power specific functionalities within Jan. Given its placement in the architecture, it's reasonable to assume that Nitro provides acceleration or optimization capabilities for tasks.
|
||||
@ -1,158 +0,0 @@
|
||||
---
|
||||
title: Build an app
|
||||
---
|
||||
|
||||
# Build and publish an app
|
||||
|
||||
You can build a custom AI application on top of Jan.
|
||||
In this tutorial, you'll build a sample app and load it into Jan Desktop.
|
||||
|
||||
## What you'll learn
|
||||
|
||||
After you've completed this tutorial, you'll be able to:
|
||||
|
||||
- Configure an environment for developing Jan apps.
|
||||
- Compile a app from source code.
|
||||
- Reload a app after making changes to it.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To complete this tutorial, you'll need:
|
||||
|
||||
- [Git](https://git-scm.com/) installed on your local machine.
|
||||
- A local development environment for [Node.js](https://node.js.org/en/about/).
|
||||
- A code editor, such as [Visual Studio Code](https://code.visualstudio.com/).
|
||||
|
||||
> When developing apps, one mistake can lead to unintended changes to your app. Please backup your data.
|
||||
|
||||
## Development
|
||||
|
||||
### Step 1: Download the sample app
|
||||
|
||||
- Go to [Jan sample app](https://github.com/janhq/jan-sample-app)
|
||||
- Select `Use this template button` at the top of the repository
|
||||
- Select `Create a new repository`
|
||||
- Select an owner and name for your new repository
|
||||
- Click `Create repository`
|
||||
- Git clone your new repository
|
||||
|
||||
### Step 2: Installation
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> You'll need to have a reasonably modern version of
|
||||
> [Node.js](https://nodejs.org) handy. If you are using a version manager like
|
||||
> [`nodenv`](https://github.com/nodenv/nodenv) or
|
||||
> [`nvm`](https://github.com/nvm-sh/nvm), you can run `nodenv install` in the
|
||||
> root of your repository to install the version specified in
|
||||
> [`package.json`](./package.json). Otherwise, 20.x or later should work!
|
||||
|
||||
1. :hammer_and_wrench: Install the dependencies
|
||||
|
||||
```bash
|
||||
npm install
|
||||
```
|
||||
|
||||
1. :building_construction: Package the TypeScript for distribution
|
||||
|
||||
```bash
|
||||
npm run bundle
|
||||
```
|
||||
|
||||
1. :white_check_mark: Check your artifact
|
||||
|
||||
There will be a tgz file in your src directory now
|
||||
|
||||
### Step 3: Update the App Manifest
|
||||
|
||||
The [`package.json`](package.json) file lets you define your apps metadata, e.g.
|
||||
app name, main entry, description and version.
|
||||
|
||||
### Step 4: Implementation
|
||||
|
||||
The [`src/`](./src/) directory is the heart of your app! You can replace the contents of this directory with your own code.
|
||||
|
||||
- `index.ts` is your app's mainentrypoint. You can access the Web runtime and define UI in this file.
|
||||
- `module.ts` is your Node runtime in which functions get executed. You should define core logic and compute-intensive workloads in this file.
|
||||
- `index.ts` and `module.ts` interact with each other via RPC (See [Information flow](./app-anatomy.md#information-flow)) via [`invokePluginFunc`](../../reference/01_init.md#invokepluginfunc)
|
||||
|
||||
Import the Jan SDK
|
||||
|
||||
```typescript
|
||||
import { core } from "@janhq/core";
|
||||
```
|
||||
|
||||
#### index.ts
|
||||
|
||||
Think of this as your "app frontend". You register events, custom functions here.
|
||||
|
||||
Note: Most Jan app functions are processed asynchronously. In `index.ts`, you will see that the extension function will return a `Promise<any>`.
|
||||
|
||||
```typescript
|
||||
import { core } from "@janhq/core";
|
||||
|
||||
function onStart(): Promise<any> {
|
||||
return core.invokePluginFunc(MODULE_PATH, "run", 0);
|
||||
}
|
||||
```
|
||||
|
||||
Define custom functions and register your implementation.
|
||||
|
||||
```javascript
|
||||
/**
|
||||
* The entrypoint for the app.
|
||||
*/
|
||||
|
||||
import { PluginService, RegisterExtensionPoint, core } from "@janhq/core";
|
||||
|
||||
/**
|
||||
* Invokes the `run` function from the `module.js` file using the `invokePluginFunc` method.
|
||||
* "run" is the name of the function to invoke.
|
||||
* @returns {Promise<any>} A promise that resolves with the result of the `run` function.
|
||||
*/
|
||||
function onStart(): Promise<any> {
|
||||
return core.invokePluginFunc(MODULE_PATH, "run", 0);
|
||||
}
|
||||
|
||||
/**
|
||||
* Initializes the plugin by registering the extension functions with the given register function.
|
||||
* @param {Function} options.register - The function to use for registering the extension functions
|
||||
*/
|
||||
export function init({ register }: { register: RegisterExtensionPoint }) {
|
||||
register(PluginService.OnStart, PLUGIN_NAME, onStart);
|
||||
}
|
||||
```
|
||||
|
||||
#### module.ts
|
||||
|
||||
Think of this as your "app backend". Your core logic implementation goes here.
|
||||
|
||||
```javascript
|
||||
const path = require("path");
|
||||
const { app } = require("electron");
|
||||
|
||||
function run(param: number): [] {
|
||||
console.log(`execute runner ${param} in main process`);
|
||||
// Your code here
|
||||
return [];
|
||||
}
|
||||
|
||||
module.exports = {
|
||||
run,
|
||||
};
|
||||
```
|
||||
|
||||
## App installation
|
||||
|
||||
|
||||
|
||||
- `Select` the built `*.tar.gz` file
|
||||
- Jan will reload after new apps get installed
|
||||
|
||||
## App uninstallation
|
||||
|
||||
To be updated
|
||||
|
||||
## App update
|
||||
|
||||
To be updated
|
||||
@ -1,11 +0,0 @@
|
||||
---
|
||||
title: Publishing an app
|
||||
---
|
||||
|
||||
After you have completed with local app development and want to publish to `Jan marketplace` for other to reuse, please follow the following steps
|
||||
|
||||
- Step 1: Update your local `package.json` and configure `npm login` correctly
|
||||
- Step 2: Run `npm publish` and set to public NPM package (so that other can install) - Please refer to our example [NPM retrieval plugin](https://www.npmjs.com/package/retrieval-plugin)
|
||||
- Step 3: Go to `Jan plugin catalog`(https://github.com/janhq/plugin-catalog) and create a `Pull request` for new `App artifact` (which is a renamed version of your App `package.json`) - Please refer to example [retrieval-plugin](https://github.com/janhq/plugin-catalog/blob/main/retrieval-plugin.json)
|
||||
- Step 4: We at Jan will be responsible to review and merge to `main`
|
||||
- Step 5: Once your new app is on `main`, you and other Jan users can find it in `Jan marketplace`
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 778 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 232 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 158 KiB |
@ -1,3 +0,0 @@
|
||||
---
|
||||
title: Installation
|
||||
---
|
||||
@ -1,76 +0,0 @@
|
||||
---
|
||||
title: Nitro
|
||||
slug: /nitro
|
||||
---
|
||||
|
||||
Nitro, is the inference engine that powers Jan. Nitro is written in C++, optimized for edge deployment.
|
||||
|
||||
⚡ Explore Nitro's codebase: [GitHub](https://github.com/janhq/nitro)
|
||||
|
||||
## Dependencies and Acknowledgements:
|
||||
|
||||
- [llama.cpp](https://github.com/ggerganov/llama.cpp): Nitro wraps Llama.cpp, which runs Llama models in C++
|
||||
- [drogon](https://github.com/drogonframework/drogon): Nitro runs Drogon, which is a fast, C++17/20 HTTP application framework.
|
||||
- (Coming soon) tensorrt-llm support.
|
||||
|
||||
## Features
|
||||
|
||||
In addition to the above features, Nitro also provides:
|
||||
|
||||
- OpenAI compatibility
|
||||
- HTTP interface with no bindings needed
|
||||
- Runs as a separate process, not interfering with main app processes
|
||||
- Multi-threaded server supporting concurrent users
|
||||
- 1-click install
|
||||
- No hardware dedendencies
|
||||
- Ships as a small binary (~3mb compressed on average)
|
||||
- Runs on Windows, MacOS, and Linux
|
||||
- Compatible with arm64, x86, and NVIDIA GPUs
|
||||
|
||||
## HTTP Interface
|
||||
|
||||
Nitro offers a straightforward HTTP interface. With compatibility for multiple standard APIs, including OpenAI formats.
|
||||
|
||||
```bash
|
||||
curl --location 'http://localhost:3928/inferences/llamacpp/chat_completion' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--header 'Accept: text/event-stream' \
|
||||
--header 'Access-Control-Allow-Origin: *' \
|
||||
--data '{
|
||||
"messages": [
|
||||
{"content": "Hello there 👋", "role": "assistant"},
|
||||
{"content": "Can you write a long story", "role": "user"}
|
||||
],
|
||||
"stream": true,
|
||||
"model": "gpt-3.5-turbo",
|
||||
"max_tokens": 2000
|
||||
}'
|
||||
```
|
||||
|
||||
## Using Nitro
|
||||
|
||||
**Step 1: Obtain Nitro**:
|
||||
Access Nitro binaries from the release page.
|
||||
🔗 [Download Nitro](https://github.com/janhq/nitro/releases)
|
||||
|
||||
**Step 2: Source a Model**:
|
||||
For those interested in the llama C++ integration, obtain a "GGUF" model from The Bloke's repository.
|
||||
🔗 [Download Model](https://huggingface.co/TheBloke)
|
||||
|
||||
**Step 3: Initialize Nitro**:
|
||||
Launch Nitro and position your model using the following API call:
|
||||
|
||||
```bash
|
||||
curl -X POST 'http://localhost:3928/inferences/llamacpp/loadmodel' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{
|
||||
"llama_model_path": "/path/to/your_model.gguf",
|
||||
"ctx_len": 2048,
|
||||
"ngl": 100,
|
||||
"embedding": true
|
||||
}'
|
||||
```
|
||||
|
||||
## Architecture diagram
|
||||
|
||||
|
||||
@ -1,74 +0,0 @@
|
||||
---
|
||||
title: "init"
|
||||
---
|
||||
|
||||
`init` is the entrypoint for your application and its custom logic. `init` is a reserved function that Jan will look for to initialize your application.
|
||||
|
||||
## Usage
|
||||
|
||||
Importing
|
||||
|
||||
```js
|
||||
// javascript
|
||||
const core = require("@janhq/core");
|
||||
|
||||
// typescript
|
||||
import * as core from "@janhq/core";
|
||||
```
|
||||
|
||||
Setting up event listeners
|
||||
|
||||
```js
|
||||
export function init({ register }) {
|
||||
myListener();
|
||||
}
|
||||
```
|
||||
|
||||
Setting up core service implementation
|
||||
|
||||
```js
|
||||
export function init({ register }: { register: RegisterExtensionPoint }) {
|
||||
register(DataService.GetConversations, "my-app-id", myImplementation);
|
||||
}
|
||||
```
|
||||
|
||||
## RegisterExtensionPoint
|
||||
|
||||
`RegisterExtensionPoint` is used for app initialization.
|
||||
|
||||
It lets you register `CoreService` functions/methods with the main application.
|
||||
|
||||
```js
|
||||
import { RegisterExtensionPoint } from "@janhq/core";
|
||||
```
|
||||
|
||||
```js
|
||||
type RegisterExtensionPoint = (
|
||||
extensionName: string,
|
||||
extensionId: string,
|
||||
method: Function,
|
||||
priority?: number
|
||||
)
|
||||
```
|
||||
|
||||
## invokePluginFunc
|
||||
|
||||
`invokePluginFunc` is a way to invoke your custom functions (defined in your `module.ts`) from your application client (defined in your `index.ts`)
|
||||
|
||||
```js
|
||||
// index.ts: your application "frontend" and entrypoint
|
||||
function foo(id: number) {
|
||||
return core.invokePluginFunc(MODULE_PATH, "foo", param1, ...);
|
||||
}
|
||||
|
||||
export function init({ register }: { register: RegisterExtensionPoint }) {
|
||||
register(Service.Foo, "my-app-id", foo);
|
||||
}
|
||||
```
|
||||
|
||||
```js
|
||||
// module.ts: your application "backend"
|
||||
export function foo(param1, ...) {
|
||||
// Your code here
|
||||
}
|
||||
```
|
||||
@ -1,94 +0,0 @@
|
||||
---
|
||||
title: "CoreService"
|
||||
---
|
||||
|
||||
`CoreService` provides an interface for implementing custom methods in Jan.
|
||||
It lets you define shared behavior across your custom application, like how your app handles state, models, or inferencing behavior.
|
||||
|
||||
## Usage
|
||||
|
||||
```js
|
||||
import { CoreService, ... } from "@janhq/core";
|
||||
```
|
||||
|
||||
## CoreService
|
||||
|
||||
The `CoreService` type bundles the following services:
|
||||
|
||||
- `StoreService`
|
||||
- `DataService`
|
||||
- `InferenceService`
|
||||
- `ModelManagementService`
|
||||
- `SystemMonitoringService`
|
||||
- `PreferenceService`
|
||||
|
||||
## StoreService
|
||||
|
||||
The `StoreService` enum represents available methods for managing the database store. It includes the following methods:
|
||||
|
||||
- `CreateCollection`: Creates a new collection in the data store.
|
||||
- `DeleteCollection`: Deletes an existing collection from the data store.
|
||||
- `InsertOne`: Inserts a new value into an existing collection in the data store.
|
||||
- `UpdateOne`: Updates an existing value in an existing collection in the data store.
|
||||
- `UpdateMany`: Updates multiple records in a collection in the data store.
|
||||
- `DeleteOne`: Deletes an existing value from an existing collection in the data store.
|
||||
- `DeleteMany`: Deletes multiple records in a collection in the data store.
|
||||
- `FindMany`: Retrieves multiple records from a collection in the data store.
|
||||
- `FindOne`: Retrieves a single record from a collection in the data store.
|
||||
|
||||
## DataService
|
||||
|
||||
The `DataService` enum represents methods related to managing conversations and messages. It includes the following methods:
|
||||
|
||||
- `GetConversations`: Gets a list of conversations from the data store.
|
||||
- `CreateConversation`: Creates a new conversation in the data store.
|
||||
- `DeleteConversation`: Deletes an existing conversation from the data store.
|
||||
- `CreateMessage`: Creates a new message in an existing conversation in the data store.
|
||||
- `UpdateMessage`: Updates an existing message in an existing conversation in the data store.
|
||||
- `GetConversationMessages`: Gets a list of messages for an existing conversation from the data store.
|
||||
|
||||
## InferenceService
|
||||
|
||||
The `InferenceService` enum exports:
|
||||
|
||||
- `InitModel`: Initializes a model for inference.
|
||||
- `StopModel`: Stops a running inference model.
|
||||
|
||||
## ModelManagementService
|
||||
|
||||
The `ModelManagementService` enum provides methods for managing models:
|
||||
|
||||
- `GetDownloadedModels`: Gets a list of downloaded models.
|
||||
- `GetAvailableModels`: Gets a list of available models from data store.
|
||||
- `DeleteModel`: Deletes a downloaded model.
|
||||
- `DownloadModel`: Downloads a model from the server.
|
||||
- `SearchModels`: Searches for models on the server.
|
||||
- `GetConfiguredModels`: Gets configured models from the data store.
|
||||
- `StoreModel`: Stores a model in the data store.
|
||||
- `UpdateFinishedDownloadAt`: Updates the finished download time for a model in the data store.
|
||||
- `GetUnfinishedDownloadModels`: Gets a list of unfinished download models from the data store.
|
||||
- `GetFinishedDownloadModels`: Gets a list of finished download models from the data store.
|
||||
- `DeleteDownloadModel`: Deletes a downloaded model from the data store.
|
||||
- `GetModelById`: Gets a model by its ID from the data store.
|
||||
|
||||
## PreferenceService
|
||||
|
||||
The `PreferenceService` enum provides methods for managing plugin preferences:
|
||||
|
||||
- `ExperimentComponent`: Represents the UI experiment component for a testing function.
|
||||
|
||||
## SystemMonitoringService
|
||||
|
||||
The `SystemMonitoringService` enum includes methods for monitoring system resources:
|
||||
|
||||
- `GetResourcesInfo`: Gets information about system resources.
|
||||
- `GetCurrentLoad`: Gets the current system load.
|
||||
|
||||
## PluginService
|
||||
|
||||
The `PluginService` enum includes plugin cycle handlers:
|
||||
|
||||
- `OnStart`: Handler for starting. E.g. Create a collection.
|
||||
- `OnPreferencesUpdate`: Handler for preferences update. E.g. Update instances with new configurations.
|
||||
|
||||
For more detailed information on each of these components, please refer to the source code.
|
||||
@ -1,85 +0,0 @@
|
||||
---
|
||||
title: "events"
|
||||
---
|
||||
|
||||
`events` lets you receive events about actions that take place in the app, like when a user sends a new message.
|
||||
|
||||
You can then implement custom logic handlers for such events.
|
||||
|
||||
## Usage
|
||||
|
||||
```js
|
||||
import { events } from "@janhq/core";
|
||||
```
|
||||
|
||||
You can subscribe to NewMessageRequest events by defining a function to handle the event and registering it with the events object:
|
||||
|
||||
```js
|
||||
import { events } from "@janhq/core";
|
||||
|
||||
function handleMessageRequest(message: NewMessageRequest) {
|
||||
// Your logic here. For example:
|
||||
// const response = openai.createChatCompletion({...})
|
||||
}
|
||||
function registerListener() {
|
||||
events.on(EventName.OnNewMessageRequest, handleMessageRequest);
|
||||
}
|
||||
// Register the listener function with the relevant extension points.
|
||||
export function init({ register }) {
|
||||
registerListener();
|
||||
}
|
||||
```
|
||||
|
||||
In this example, we're defining a function called handleMessageRequest that takes a NewMessageRequest object as its argument. We're also defining a function called registerListener that registers the handleMessageRequest function as a listener for NewMessageRequest events using the on method of the events object.
|
||||
|
||||
```js
|
||||
import { events } from "@janhq/core";
|
||||
|
||||
function handleMessageRequest(data: NewMessageRequest) {
|
||||
// Your logic here. For example:
|
||||
const response = openai.createChatCompletion({...})
|
||||
const message: NewMessageResponse = {
|
||||
...data,
|
||||
message: response.data.choices[0].message.content
|
||||
}
|
||||
// Now emit event so the app can display in the conversation
|
||||
events.emit(EventName.OnNewMessageResponse, message)
|
||||
}
|
||||
```
|
||||
|
||||
## EventName
|
||||
|
||||
The `EventName` enum bundles the following events:
|
||||
|
||||
- `OnNewConversation`
|
||||
- `OnNewMessageRequest`
|
||||
- `OnNewMessageResponse`
|
||||
- `OnMessageResponseUpdate`
|
||||
- `OnDownloadUpdate`
|
||||
- `OnDownloadSuccess`
|
||||
- `OnDownloadError`
|
||||
|
||||
## event.on
|
||||
|
||||
Adds an observer for an event.
|
||||
|
||||
```js
|
||||
const on: (eventName: string, handler: Function) => void = (eventName, handler);
|
||||
```
|
||||
|
||||
## event.emit
|
||||
|
||||
Emits an event.
|
||||
|
||||
```js
|
||||
const emit: (eventName: string, object: any) => void = (eventName, object);
|
||||
```
|
||||
|
||||
## event.off
|
||||
|
||||
Removes an observer for an event.
|
||||
|
||||
```js
|
||||
const off: (eventName: string, handler: Function) => void =
|
||||
(eventName, handler);
|
||||
```
|
||||
@ -1,76 +0,0 @@
|
||||
---
|
||||
title: "store"
|
||||
---
|
||||
|
||||
`store` is a helper object for working with Jan app's local storage database.
|
||||
|
||||
By default, Jan ships with a [pouchDB](https://pouchdb.com/) client side noSQL db to persist usage state.
|
||||
|
||||
_Note: default `store` logic is from [@data-plugin](https://www.npmjs.com/package/@janhq/data-plugin) which implements `StoreService`._
|
||||
|
||||
## Usage
|
||||
|
||||
```js
|
||||
import { store } from "@janhq/core";
|
||||
```
|
||||
|
||||
## Insert Data
|
||||
|
||||
You can use the store.insertOne function to insert data into a specific collection in the local data store.
|
||||
|
||||
```js
|
||||
import { store } from "@janhq/core";
|
||||
|
||||
function insertData() {
|
||||
store.insertOne("conversations", { name: "meow" });
|
||||
// Insert a new document with { name: "meow" } into the "conversations" collection.
|
||||
}
|
||||
```
|
||||
|
||||
## Get Data
|
||||
|
||||
To retrieve data from a collection in the local data store, you can use the `store.findOne` or `store.findMany` function. It allows you to filter and retrieve documents based on specific criteria.
|
||||
|
||||
store.getOne(collectionName, key) retrieves a single document that matches the provided key in the specified collection.
|
||||
store.getMany(collectionName, selector, sort) retrieves multiple documents that match the provided selector in the specified collection.
|
||||
|
||||
```js
|
||||
import { store } from "@janhq/core";
|
||||
|
||||
function getData() {
|
||||
const selector = { name: "meow" };
|
||||
const data = store.findMany("conversations", selector);
|
||||
// Retrieve documents from the "conversations" collection that match the filter.
|
||||
}
|
||||
```
|
||||
|
||||
## Update Data
|
||||
|
||||
You can update data in the local store using these functions:
|
||||
|
||||
store.updateOne(collectionName, key, update) updates a single document that matches the provided key in the specified collection.
|
||||
store.updateMany(collectionName, selector, update) updates multiple documents that match the provided selector in the specified collection.
|
||||
|
||||
```js
|
||||
function updateData() {
|
||||
const selector = { name: "meow" };
|
||||
const update = { name: "newName" };
|
||||
store.updateOne("conversations", selector, update);
|
||||
// Update a document in the "conversations" collection.
|
||||
}
|
||||
```
|
||||
|
||||
## Delete Data
|
||||
|
||||
You can delete data from the local data store using these functions:
|
||||
|
||||
store.deleteOne(collectionName, key) deletes a single document that matches the provided key in the specified collection.
|
||||
store.deleteMany(collectionName, selector) deletes multiple documents that match the provided selector in the specified collection.
|
||||
|
||||
```js
|
||||
function deleteData() {
|
||||
const selector = { name: "meow" };
|
||||
store.deleteOne("conversations", selector);
|
||||
// Delete a document from the "conversations" collection.
|
||||
}
|
||||
```
|
||||
@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "filesystem"
|
||||
---
|
||||
|
||||
The core package also provides functions to perform file operations. Here are a couple of examples:
|
||||
|
||||
## Usage
|
||||
|
||||
```js
|
||||
// javascript
|
||||
const core = require("@janhq/core");
|
||||
|
||||
// typescript
|
||||
import * as core from "@janhq/core";
|
||||
```
|
||||
|
||||
## Download a File
|
||||
|
||||
You can download a file from a specified URL and save it with a given file name using the core.downloadFile function.
|
||||
|
||||
```js
|
||||
function downloadModel(url: string, fileName: string) {
|
||||
core.downloadFile(url, fileName);
|
||||
}
|
||||
```
|
||||
|
||||
## Delete a File
|
||||
|
||||
To delete a file, you can use the core.deleteFile function, providing the path to the file you want to delete.
|
||||
|
||||
```js
|
||||
function deleteModel(filePath: string) {
|
||||
core.deleteFile(path);
|
||||
}
|
||||
```
|
||||
@ -1,59 +0,0 @@
|
||||
---
|
||||
title: "preferences"
|
||||
---
|
||||
|
||||
`preferences` is a helper object for adding settings fields to your app.
|
||||
|
||||
## Usage
|
||||
|
||||
To register plugin preferences, you can use the preferences object from the @janhq/core package. Here's an example of how to register and retrieve plugin preferences:
|
||||
|
||||
```js
|
||||
import { PluginService, preferences } from "@janhq/core";
|
||||
|
||||
const pluginName = "your-first-plugin";
|
||||
const preferenceKey = "";
|
||||
const preferenceName = "Your First Preference";
|
||||
const preferenceDescription = "This is for example only";
|
||||
const defaultValue = "";
|
||||
|
||||
export function init({ register }: { register: RegisterExtensionPoint }) {
|
||||
// Register preference update handlers. E.g. update plugin instance with new configuration
|
||||
register(PluginService.OnPreferencesUpdate, pluginName, onPreferencesUpdate);
|
||||
|
||||
// Register plugin preferences. E.g. Plugin need apiKey to connect to your service
|
||||
preferences.registerPreferences <
|
||||
string >
|
||||
(register,
|
||||
pluginName,
|
||||
preferenceKey,
|
||||
preferenceName,
|
||||
preferenceDescription,
|
||||
defaultValue);
|
||||
}
|
||||
```
|
||||
|
||||
In this example, we're registering preference update handlers and plugin preferences using the preferences object. We're also defining a PluginName constant to use as the name of the plugin.
|
||||
|
||||
To retrieve the values of the registered preferences, we're using the get method of the preferences object and passing in the name of the plugin and the name of the preference.
|
||||
|
||||
```js
|
||||
import { preferences } from "@janhq/core";
|
||||
|
||||
const pluginName = "your-first-plugin";
|
||||
const preferenceKey = "apiKey";
|
||||
|
||||
const setup = async () => {
|
||||
// Retrieve apiKey
|
||||
const apiKey: string =
|
||||
(await preferences.get(pluginName, preferenceKey)) ?? "";
|
||||
};
|
||||
```
|
||||
|
||||
## registerPreferences
|
||||
|
||||
## get
|
||||
|
||||
## set
|
||||
|
||||
## clear
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Building a chat app
|
||||
---
|
||||
|
||||
TODO
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: Building a RAG app
|
||||
---
|
||||
|
||||
TODO
|
||||
@ -35,8 +35,7 @@ const sidebars = {
|
||||
type: "category",
|
||||
label: "Installation",
|
||||
collapsible: true,
|
||||
collapsed: true,
|
||||
link: { type: "doc", id: "guides/install/install" },
|
||||
collapsed: false,
|
||||
items: [
|
||||
{
|
||||
type: "autogenerated",
|
||||
@ -49,6 +48,7 @@ const sidebars = {
|
||||
|
||||
docsSidebar: [
|
||||
"docs/introduction",
|
||||
"docs/quickstart",
|
||||
{
|
||||
type: "category",
|
||||
label: "Modules",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user