i18n - docs translations (#17434)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com>
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
2353bc62cc
commit
e0d4492013
+11
-11
@@ -1,22 +1,22 @@
|
||||
---
|
||||
title: Best Practices
|
||||
title: ベストプラクティス',
|
||||
---
|
||||
|
||||
This document outlines the best practices you should follow when working on the backend.
|
||||
この文書は、バックエンドで作業する際に従うべきベストプラクティスを概説しています。
|
||||
|
||||
## Follow a modular approach
|
||||
## モジュール化アプローチを採用する
|
||||
|
||||
The backend follows a modular approach, which is a fundamental principle when working with NestJS. Make sure you break down your code into reusable modules to maintain a clean and organized codebase.
|
||||
Each module should encapsulate a particular feature or functionality and have a well-defined scope. This modular approach enables clear separation of concerns and removes unnecessary complexities.
|
||||
バックエンドは、NestJSを使用する際の基本原則であるモジュラーアプローチを採用しています。 コードを再利用可能なモジュールに分割し、クリーンで整理されたコードベースを維持してください。
|
||||
各モジュールは特定の機能や機能性をカプセル化し、明確なスコープを持つべきです。 このモジュラーアプローチにより、関心事を明確に分離し、不要な複雑さを排除します。
|
||||
|
||||
## Expose services to use in modules
|
||||
## モジュールで使用するサービスを公開する
|
||||
|
||||
Always create services that have a clear and single responsibility, which enhances code readability and maintainability. Name the services descriptively and consistently.
|
||||
常に、明確で単一の責務を持つサービスを作成してください。これにより、コードの可読性と保守性が向上します。 サービスには意味のある一貫した名前を付けてください。
|
||||
|
||||
You should also expose services that you want to use in other modules. Exposing services to other modules is possible through NestJS's powerful dependency injection system, and promotes loose coupling between components.
|
||||
他のモジュールで使用したいサービスを公開する必要があります。 サービスを他のモジュールへ公開することは、NestJS の強力な依存性注入システムによって可能であり、コンポーネント間の疎結合を促進します。
|
||||
|
||||
## Avoid using `any` type
|
||||
## `any` 型の使用を避ける
|
||||
|
||||
When you declare a variable as `any`, TypeScript's type checker doesn't perform any type checking, making it possible to assign any type of values to the variable. TypeScript uses type inference to determine the type of variable based on the value. By declaring it as `any`, TypeScript can no longer infer the type. This makes it hard to catch type-related errors during development, leading to runtime errors and makes the code less maintainable, less reliable, and harder to understand for others.
|
||||
変数を `any` として宣言すると、TypeScript の型チェッカーは型チェックを行わなくなり、その変数にはあらゆる型の値を割り当てられるようになります。 TypeScript は、値に基づいて変数の型を決定するために型推論を使用します。 `any` として宣言すると、TypeScript は型を推論できなくなります。 これにより、開発中に型に関連したエラーを捕捉しにくくなり、実行時エラーを引き起こし、コードのメンテナンス性、信頼性が低下し、他の人が理解しづらくなります。
|
||||
|
||||
This is why everything should have a type. So if you create a new object with a first name and last name, you should create an interface or type that contains a first name and last name that defines the shape of the object you are manipulating.
|
||||
これがすべてに型を持たせるべき理由です。 したがって、名と姓を持つ新しいオブジェクトを作成する場合は、操作しているオブジェクトの構造を定義する、名と姓を含むインターフェースまたは型を作成する必要があります。
|
||||
|
||||
+15
-15
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: Custom Objects
|
||||
title: カスタムオブジェクト
|
||||
---
|
||||
|
||||
Objects are structures that allow you to store data (records, attributes, and values) specific to an organization. Twenty provides both standard and custom objects.
|
||||
オブジェクトは、組織独自のデータ（記録、属性、値）を保存するための構造です。 Twenty provides both standard and custom objects. Twenty は標準オブジェクトとカスタムオブジェクトの両方を提供します。
|
||||
|
||||
Standard objects are in-built objects with a set of attributes available for all users. Examples of standard objects in Twenty include Company and Person. Standard objects have standard fields that are also available for all Twenty users, like Company.displayName.
|
||||
標準オブジェクトは、すべてのユーザーが利用可能な一連の属性を備えた組み込みのオブジェクトです。 標準オブジェクトは、すべてのユーザーが利用可能な一連の属性を備えた組み込みのオブジェクトです。 Examples of standard objects in Twenty include Company and Person. 標準オブジェクトは、すべてのユーザーが利用可能な一連の属性を備えた組み込みのオブジェクトです。 Examples of standard objects in Twenty include Company and Person. 標準オブジェクトには、Twenty のすべてのユーザーが利用できる標準フィールドがあり、例えば Company.displayName があります。
|
||||
|
||||
Custom objects are objects that you can create to store information that is unique to your organization. They are not built-in; members of your workspace can create and customize custom objects to hold information that standard objects aren't suitable for.
|
||||
カスタムオブジェクトは、組織に固有の情報を保存するために作成できるオブジェクトです。 カスタムオブジェクトは、組織に固有の情報を保存するために作成できるオブジェクトです。 カスタムオブジェクトは、組織に固有の情報を保存するために作成できるオブジェクトです。 組み込みではないため、ワークスペースメンバーは、標準オブジェクトに適さない情報を保持するためにカスタムオブジェクトを作成およびカスタマイズできます。
|
||||
|
||||
## High-level schema
|
||||
## 上位スキーマ
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/images/docs/server/custom-object-schema.png" alt="High level schema" />
|
||||
<img src="/images/docs/server/custom-object-schema.png" alt="上位スキーマ" />
|
||||
</div>
|
||||
|
||||
<br />
|
||||
|
||||
## How it works
|
||||
## 仕組み
|
||||
|
||||
Custom objects come from metadata tables that determine the shape, name, and type of the objects. All this information is present in the metadata schema database, consisting of tables:
|
||||
カスタムオブジェクトは、オブジェクトの形状、名前、およびタイプを決定するメタデータテーブルから来ます。 このすべての情報は、テーブルで構成されるメタデータスキーマデータベースに存在します： このすべての情報は、テーブルで構成されるメタデータスキーマデータベースに存在します： このすべての情報は、テーブルで構成されるメタデータスキーマデータベースに存在します：
|
||||
|
||||
* **DataSource**: Details where the data is present.
|
||||
* **Object**: Describes the object and links to a DataSource.
|
||||
* **Field**: Outlines an Object's fields and connects to the Object.
|
||||
* **DataSource**: データの存在場所を示します。
|
||||
* **オブジェクト**: オブジェクトを説明し、DataSourceにリンクします。
|
||||
* **フィールド**: オブジェクトのフィールドを概説し、オブジェクトに接続します。
|
||||
|
||||
To add a custom object, the workspaceMember will query the /metadata API. This updates the metadata accordingly and computes a GraphQL schema based on the metadata, storing it in a GQL cache for later use.
|
||||
カスタムオブジェクトを追加するには、workspaceMemberが/metadata APIをクエリします。 これにより、メタデータが適切に更新され、メタデータに基づいてGraphQLスキーマが計算され、後で使用するためにGQLキャッシュに保存されます。 これにより、メタデータが適切に更新され、メタデータに基づいてGraphQLスキーマが計算され、後で使用するためにGQLキャッシュに保存されます。 これにより、メタデータが適切に更新され、メタデータに基づいてGraphQLスキーマが計算され、後で使用するためにGQLキャッシュに保存されます。
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/images/docs/server/add-custom-objects.jpeg" alt="Query the /metadata API to add custom objects" />
|
||||
<img src="/images/docs/server/add-custom-objects.jpeg" alt="カスタムオブジェクトを追加するために/metadata APIをクエリ" />
|
||||
</div>
|
||||
|
||||
<br />
|
||||
|
||||
To fetch data, the process involves making queries through the /graphql endpoint and passing them through the Query Resolver.
|
||||
データを取得するには、/graphqlエンドポイントを介してクエリを行い、Query Resolverを通過させるプロセスが必要です。
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/images/docs/server/custom-object-schema.png" alt="Query the /graphql endpoint to fetch data" />
|
||||
<img src="/images/docs/server/custom-object-schema.png" alt="データを取得するために/graphqlエンドポイントをクエリします" />
|
||||
</div>
|
||||
|
||||
+12
-12
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Feature Flags
|
||||
title: 機能フラグ
|
||||
---
|
||||
|
||||
Feature flags are used to hide experimental features. For Twenty, they are set on workspace level and not on a user level.
|
||||
機能フラグは試験的な機能を隠すために使用されます。 機能フラグは試験的な機能を隠すために使用されます。 Twentyでは、それらはワークスペースレベルで設定されており、ユーザーレベルではありません。 機能フラグは試験的な機能を隠すために使用されます。 Twentyでは、それらはワークスペースレベルで設定されており、ユーザーレベルではありません。
|
||||
|
||||
## Adding a new feature flag
|
||||
## 新しい機能フラグの追加
|
||||
|
||||
In `FeatureFlagKey.ts` add the feature flag:
|
||||
`FeatureFlagKey.ts`に機能フラグを追加します:
|
||||
|
||||
```ts
|
||||
type FeatureFlagKey =
|
||||
@@ -14,7 +14,7 @@ type FeatureFlagKey =
|
||||
| ...;
|
||||
```
|
||||
|
||||
Also add it to the enum in `feature-flag.entity.ts`:
|
||||
また、`feature-flag.entity.ts`の列挙型にも追加します:
|
||||
|
||||
```ts
|
||||
enum FeatureFlagKeys {
|
||||
@@ -23,7 +23,7 @@ enum FeatureFlagKeys {
|
||||
}
|
||||
```
|
||||
|
||||
To apply a feature flag on a **backend** feature use:
|
||||
**バックエンド**機能に機能フラグを適用するには、次を使用します:
|
||||
|
||||
```ts
|
||||
@Gate({
|
||||
@@ -31,16 +31,16 @@ To apply a feature flag on a **backend** feature use:
|
||||
})
|
||||
```
|
||||
|
||||
To apply a feature flag on a **frontend** feature use:
|
||||
**フロントエンド**機能に機能フラグを適用するには、次を使用します:
|
||||
|
||||
```ts
|
||||
const isFeatureNameEnabled = useIsFeatureEnabled('IS_FEATURENAME_ENABLED');
|
||||
```
|
||||
|
||||
## Configure feature flags for the deployment
|
||||
## デプロイメント用の機能フラグを設定する
|
||||
|
||||
Change the corresponding record in the Table `core.featureFlag`:
|
||||
Table `core.featureFlag` 内の対応するレコードを変更します:
|
||||
|
||||
| id | key | workspaceId | value |
|
||||
| ------ | ------------------------ | ----------- | ------ |
|
||||
| Random | `IS_FEATURENAME_ENABLED` | WorkspaceID | `true` |
|
||||
| id | キー | workspaceId | 値 |
|
||||
| ---- | ------------------------ | ----------- | --- |
|
||||
| ランダム | `IS_FEATURENAME_ENABLED` | WorkspaceID | `真` |
|
||||
|
||||
+40
-40
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Folder Architecture
|
||||
info: A detailed look into our server folder architecture
|
||||
title: フォルダ構成
|
||||
info: 当社のサーバーフォルダ構造の詳細な観察
|
||||
---
|
||||
|
||||
The backend directory structure is as follows:
|
||||
バックエンドのディレクトリ構造は以下の通りです:
|
||||
|
||||
```
|
||||
server
|
||||
@@ -21,37 +21,37 @@ server
|
||||
└───utils
|
||||
```
|
||||
|
||||
## Ability
|
||||
## 能力
|
||||
|
||||
Defines permissions and includes handlers for each entity.
|
||||
各エンティティの権限を定義し、ハンドラーを含みます。
|
||||
|
||||
## Decorators
|
||||
## デコレータ
|
||||
|
||||
Defines custom decorators in NestJS for added functionality.
|
||||
NestJS で機能を拡張するためのカスタムデコレーターを定義します。
|
||||
|
||||
See [custom decorators](https://docs.nestjs.com/custom-decorators) for more details.
|
||||
詳細については、[カスタムデコレータ](https://docs.nestjs.com/custom-decorators) を参照してください。
|
||||
|
||||
## Filters
|
||||
## フィルター
|
||||
|
||||
Includes exception filters to handle exceptions that might occur in GraphQL endpoints.
|
||||
GraphQLエンドポイントで発生する可能性のある例外を処理するための例外フィルターを含みます。
|
||||
|
||||
## Guards
|
||||
## ガード
|
||||
|
||||
See [guards](https://docs.nestjs.com/guards) for more details.
|
||||
詳細については、[ガード](https://docs.nestjs.com/guards) を参照してください。
|
||||
|
||||
## Health
|
||||
## ヘルス
|
||||
|
||||
Includes a publicly available REST API (healthz) that returns a JSON to confirm whether the database is working as expected.
|
||||
データベースが期待通りに動作しているかを確認するためのJSONを返す公開されたREST API (healthz) を含みます。
|
||||
|
||||
## Metadata
|
||||
## メタデータ
|
||||
|
||||
Defines custom objects and makes available a GraphQL API (graphql/metadata).
|
||||
カスタムオブジェクトを定義し、GraphQL API (graphql/metadata) を利用可能にします。
|
||||
|
||||
## Workspace
|
||||
## ワークスペース
|
||||
|
||||
Generates and serves custom GraphQL schema based on the metadata.
|
||||
メタデータに基づいてカスタムGraphQLスキーマを生成し、提供します。
|
||||
|
||||
### Workspace Directory Structure
|
||||
### ワークスペースディレクトリ構造
|
||||
|
||||
```
|
||||
workspace
|
||||
@@ -83,43 +83,43 @@ workspace
|
||||
└───workspace.factory.ts
|
||||
```
|
||||
|
||||
The root of the workspace directory includes the `workspace.factory.ts`, a file containing the `createGraphQLSchema` function. This function generates workspace-specific schema by using the metadata to tailor a schema for individual workspaces. By separating the schema and resolver construction, we use the `makeExecutableSchema` function, which combines these discrete elements.
|
||||
ワークスペースディレクトリのルートには、`workspace.factory.ts` が含まれ、`createGraphQLSchema` 関数が含まれています。 この関数は、メタデータを使用して、個々のワークスペース用のスキーマを調整し、ワークスペース固有のスキーマを生成します。 スキーマとリゾルバーの構築を分離することで、`makeExecutableSchema` 関数を使用し、これらの個別要素を組み合わせます。 この関数は、メタデータを使用して、個々のワークスペース用のスキーマを調整し、ワークスペース固有のスキーマを生成します。 スキーマとリゾルバーの構築を分離することで、`makeExecutableSchema` 関数を使用し、これらの個別要素を組み合わせます。 この関数は、メタデータを使用して、個々のワークスペース用のスキーマを調整し、ワークスペース固有のスキーマを生成します。 スキーマとリゾルバーの構築を分離することで、`makeExecutableSchema` 関数を使用し、これらの個別要素を組み合わせます。
|
||||
|
||||
This strategy is not just about organization, but also helps with optimization, such as caching generated type definitions to enhance performance and scalability.
|
||||
この戦略は、組織化だけでなく、パフォーマンスやスケーラビリティを向上させるための型定義のキャッシングのような最適化にも役立ちます。
|
||||
|
||||
### Workspace Schema builder
|
||||
### ワークスペーススキーマビルダー
|
||||
|
||||
Generates the GraphQL schema, and includes:
|
||||
GraphQLスキーマを生成し、含まれるもの:
|
||||
|
||||
#### Factories:
|
||||
#### ファクトリー:
|
||||
|
||||
Specialised constructors to generate GraphQL-related constructs.
|
||||
GraphQL関連の構造を生成するための専門的なコンストラクター。
|
||||
|
||||
* The type.factory translates field metadata into GraphQL types using `TypeMapperService`.
|
||||
* The type-definition.factory creates GraphQL input or output objects derived from `objectMetadata`.
|
||||
* type.factoryは、フィールドメタデータを`TypeMapperService`を使用してGraphQLタイプに変換します。
|
||||
* type-definition.factoryは、`objectMetadata`から導出されるGraphQLの入力または出力オブジェクトを作成します。
|
||||
|
||||
#### GraphQL Types
|
||||
#### GraphQLタイプ
|
||||
|
||||
Includes enumerations, inputs, objects, and scalars, and serves as the building blocks for the schema construction.
|
||||
列挙型、入力、オブジェクト、スカラーを含み、スキーマ構築の基礎となります。
|
||||
|
||||
#### Interfaces and Object Definitions
|
||||
#### インターフェースとオブジェクト定義
|
||||
|
||||
Contains the blueprints for GraphQL entities, and includes both predefined and custom types like `MONEY` or `URL`.
|
||||
GraphQLエンティティの設計図を含み、`MONEY`や`URL`のような定義済みおよびカスタムタイプが含まれます。
|
||||
|
||||
#### Services
|
||||
#### サービス
|
||||
|
||||
Contains the service responsible for associating FieldMetadataType with its appropriate GraphQL scalar or query modifiers.
|
||||
FieldMetadataTypeに対応するGraphQLスカラーまたはクエリ修飾子を関連付けるためのサービスを含みます。
|
||||
|
||||
#### Storage
|
||||
#### ストレージ
|
||||
|
||||
Includes the `TypeDefinitionsStorage` class that contains reusable type definitions, preventing duplication of GraphQL types.
|
||||
GraphQLタイプの重複を防ぐための再利用可能な型定義を含む`TypeDefinitionsStorage`クラスを含みます。
|
||||
|
||||
### Workspace Resolver Builder
|
||||
### ワークスペースリゾルバービルダー
|
||||
|
||||
Creates resolver functions for querying and mutating the GraphQL schema.
|
||||
GraphQLスキーマのクエリおよび変更を行うリゾルバー関数を作成します。
|
||||
|
||||
Each factory in this directory is responsible for producing a distinct resolver type, such as the `FindManyResolverFactory`, designed for adaptable application across various tables.
|
||||
このディレクトリ内の各ファクトリーは、様々なテーブルに適用可能な`FindManyResolverFactory`のように、異なるリゾルバータイプを生成する役割を果たします。
|
||||
|
||||
### Workspace Query Runner
|
||||
### ワークスペースクエリランナー
|
||||
|
||||
Runs the generated queries on the database and parses the result.
|
||||
データベースで生成されたクエリを実行し、その結果を解析します。
|
||||
|
||||
+10
-10
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: Message Queue
|
||||
title: メッセージキュー
|
||||
---
|
||||
|
||||
Queues facilitate async operations to be performed. They can be used for performing background tasks such as sending a welcome email on register.
|
||||
Each use case will have its own queue class extended from `MessageQueueServiceBase`.
|
||||
キューは非同期処理を実行するための手段を提供します。 それらは、登録時にウェルカムメールを送信するなどのバックグラウンドタスクを実行するために使用できます。
|
||||
各ユースケースには `MessageQueueServiceBase` から拡張された独自のキュークラスが必要です。
|
||||
|
||||
Currently, we only support `bull-mq`[bull-mq](https://bullmq.io/) as the queue driver.
|
||||
現在のところ、キュードライバとして `bull-mq`[bull-mq](https://bullmq.io/) のみをサポートしています。
|
||||
|
||||
## Steps to create and use a new queue
|
||||
## 新しいキューを作成して使用する手順
|
||||
|
||||
1. Add a queue name for your new queue under enum `MESSAGE_QUEUES`.
|
||||
2. Provide the factory implementation of the queue with the queue name as the dependency token.
|
||||
3. Inject the queue that you created in the required module/service with the queue name as the dependency token.
|
||||
4. Add worker class with token based injection just like producer.
|
||||
1. enum `MESSAGE_QUEUES` に、新しいキュー用のキュー名を追加します。
|
||||
2. 依存トークンとしてキュー名を持つキューのファクトリ実装を提供します。
|
||||
3. 依存性トークンとしてキュー名を使用して、作成したキューを必要なモジュール/サービスにインジェクトします。
|
||||
4. トークンベースのインジェクションを用いたワーカークラスをプロデューサーと同様に追加します。
|
||||
|
||||
### Example usage
|
||||
### 使用例
|
||||
|
||||
```ts
|
||||
class Resolver {
|
||||
|
||||
+32
-27
@@ -1,19 +1,24 @@
|
||||
---
|
||||
title: Backend Commands
|
||||
title: バックエンドコマンド
|
||||
---
|
||||
|
||||
## Useful commands
|
||||
## 便利なコマンド
|
||||
|
||||
These commands should be executed from packages/twenty-server folder.
|
||||
これらのコマンドは packages/twenty-server フォルダから実行してください。
|
||||
これらのコマンドは packages/twenty-server フォルダから実行してください。
|
||||
これらのコマンドは packages/twenty-server フォルダから実行してください。
|
||||
これらのコマンドは packages/twenty-server フォルダから実行してください。
|
||||
これらのコマンドは packages/twenty-server フォルダから実行してください。
|
||||
これらのコマンドは packages/twenty-server フォルダから実行してください。
|
||||
From any other folder you can run `npx nx {command} twenty-server` (or `npx nx run twenty-server:{command}`).
|
||||
|
||||
### First time setup
|
||||
### 初期設定
|
||||
|
||||
```
|
||||
npx nx database:reset twenty-server # setup the database with dev seeds
|
||||
```
|
||||
|
||||
### Starting the server
|
||||
### サーバーの起動
|
||||
|
||||
```
|
||||
npx nx run twenty-server:start
|
||||
@@ -25,77 +30,77 @@ npx nx run twenty-server:start
|
||||
npx nx run twenty-server:lint # pass --fix to fix lint errors
|
||||
```
|
||||
|
||||
### Test
|
||||
### テスト
|
||||
|
||||
```
|
||||
npx nx run twenty-server:test:unit # run unit tests
|
||||
npx nx run twenty-server:test:integration # run integration tests
|
||||
```
|
||||
|
||||
Note: you can run `npx nx run twenty-server:test:integration:with-db-reset` in case you need to reset the database before running the integration tests.
|
||||
注: 統合テストを実行する前にデータベースをリセットする必要がある場合、 `npx nx run twenty-server:test:integration:with-db-reset` を実行できます。
|
||||
|
||||
### Resetting the database
|
||||
### データベースのリセット
|
||||
|
||||
If you want to reset and seed the database, you can run the following command:
|
||||
データベースをリセットおよびシードしたい場合は、次のコマンドを実行してください:
|
||||
|
||||
```bash
|
||||
npx nx run twenty-server:database:reset
|
||||
```
|
||||
|
||||
### Migrations
|
||||
### マイグレーション
|
||||
|
||||
#### For objects in Core/Metadata schemas (TypeORM)
|
||||
#### Core/Metadata スキーマ (TypeORM) のオブジェクトに対して
|
||||
|
||||
```bash
|
||||
npx nx run twenty-server:typeorm migration:generate src/database/typeorm/core/migrations/nameOfYourMigration -d src/database/typeorm/core/core.datasource.ts
|
||||
```
|
||||
|
||||
#### For Workspace objects
|
||||
#### ワークスペースオブジェクトに対して
|
||||
|
||||
There are no migrations files, migration are generated automatically for each workspace,
|
||||
stored in the database, and applied with this command
|
||||
マイグレーションファイルはなく、それぞれのワークスペースに対して自動的に生成され、
|
||||
データベースに保存され、このコマンドで適用されます。
|
||||
|
||||
```bash
|
||||
npx nx run twenty-server:command workspace:sync-metadata -f
|
||||
```
|
||||
|
||||
<Warning>
|
||||
This will drop the database and re-run the migrations and seed.
|
||||
これによりデータベースが削除され、マイグレーションとシードが再実行されます。
|
||||
|
||||
Make sure to back up any data you want to keep before running this command.
|
||||
このコマンドを実行する前に、保持したいデータをバックアップしてください。
|
||||
</Warning>
|
||||
|
||||
## Tech Stack
|
||||
## 技術スタック
|
||||
|
||||
Twenty primarily uses NestJS for the backend.
|
||||
Twenty は主にバックエンドに NestJS を使用しています。
|
||||
|
||||
Prisma was the first ORM we used. But in order to allow users to create custom fields and custom objects, a lower-level made more sense as we need to have fine-grained control. The project now uses TypeORM.
|
||||
最初に使用した ORM は Prisma でした。 最初に使用した ORM は Prisma でした。 But in order to allow users to create custom fields and custom objects, a lower-level made more sense as we need to have fine-grained control. 最初に使用した ORM は Prisma でした。 But in order to allow users to create custom fields and custom objects, a lower-level made more sense as we need to have fine-grained control. 現在のプロジェクトでは TypeORM を使用しています。
|
||||
|
||||
Here's what the tech stack now looks like.
|
||||
現在の技術スタックは次のようになっています。
|
||||
|
||||
**Core**
|
||||
**コア**
|
||||
|
||||
* [NestJS](https://nestjs.com/)
|
||||
* [TypeORM](https://typeorm.io/)
|
||||
* [GraphQL Yoga](https://the-guild.dev/graphql/yoga-server)
|
||||
|
||||
**Database**
|
||||
**データベース**
|
||||
|
||||
* [Postgres](https://www.postgresql.org/)
|
||||
|
||||
**Third-party integrations**
|
||||
**サードパーティ統合**
|
||||
|
||||
* [Sentry](https://sentry.io/welcome/) for tracking bugs
|
||||
* [Sentry](https://sentry.io/welcome/) バグトラッキング用
|
||||
|
||||
**Testing**
|
||||
**テスト**
|
||||
|
||||
* [Jest](https://jestjs.io/)
|
||||
|
||||
**Tooling**
|
||||
**ツール**
|
||||
|
||||
* [Yarn](https://yarnpkg.com/)
|
||||
* [ESLint](https://eslint.org/)
|
||||
|
||||
**Development**
|
||||
**開発**
|
||||
|
||||
* [AWS EKS](https://aws.amazon.com/eks/)
|
||||
|
||||
+20
-20
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: Zapier App
|
||||
title: Zapierアプリ
|
||||
---
|
||||
|
||||
Effortlessly sync Twenty with 3000+ apps using [Zapier](https://zapier.com/). Automate tasks, boost productivity, and supercharge your customer relationships!
|
||||
[Zapier](https://zapier.com/) を使って、3000以上のアプリと Twenty を簡単に同期できます。 タスクを自動化し、生産性を高め、顧客関係を強化しよう！
|
||||
|
||||
## About Zapier
|
||||
## Zapierについて
|
||||
|
||||
Zapier is a tool that allows you to automate workflows by connecting the apps that your team uses every day. The fundamental concept of Zapier is automation workflows, called Zaps, and include triggers and actions.
|
||||
Zapierは、チームが毎日使用するアプリを連携させてワークフローを自動化するツールです。 Zapierの基本的な概念は、Zapsと呼ばれる自動化ワークフローであり、トリガーとアクションを含みます。 Zapierは、チームが毎日使用するアプリを連携させてワークフローを自動化するツールです。 Zapierの基本的な概念は、Zapsと呼ばれる自動化ワークフローであり、トリガーとアクションを含みます。 Zapierの基本的な概念は、Zapsと呼ばれる自動化ワークフローであり、トリガーとアクションを含みます。
|
||||
|
||||
You can learn more about how Zapier works [here](https://zapier.com/how-it-works).
|
||||
Zapierの仕組みについてもっと知りたい方は[こちら](https://zapier.com/how-it-works)をご覧ください。
|
||||
|
||||
## Setup
|
||||
## セットアップ
|
||||
|
||||
### Step 1: Install Zapier packages
|
||||
### ステップ 1: Zapier パッケージをインストール
|
||||
|
||||
```bash
|
||||
cd packages/twenty-zapier
|
||||
@@ -20,33 +20,33 @@ cd packages/twenty-zapier
|
||||
yarn
|
||||
```
|
||||
|
||||
### Step 2: Login with the CLI
|
||||
### ステップ 2: CLI でログイン
|
||||
|
||||
Use your Zapier credentials to log in using the CLI:
|
||||
Zapierの資格情報を使用してCLIでログインしてください。
|
||||
|
||||
```bash
|
||||
zapier login
|
||||
```
|
||||
|
||||
### Step 3: Set environment variables
|
||||
### ステップ3：環境変数をセットアップします
|
||||
|
||||
From the `packages/twenty-zapier` folder, run:
|
||||
`packages/twenty-zapier`フォルダーから実行します。
|
||||
|
||||
```bash
|
||||
cp .env.example .env
|
||||
```
|
||||
|
||||
Run the application locally, go to [http://localhost:3000/settings/api-webhooks](http://localhost:3000/settings/api-webhooks), and generate an API key.
|
||||
アプリケーションをローカルで実行し、[http://localhost:3000/settings/api-webhooks](http://localhost:3000/settings/api-webhooks)にアクセスしてAPIキーを生成してください。
|
||||
|
||||
Replace the **YOUR_API_KEY** value in the `.env` file with the API key you just generated.
|
||||
.envファイルの**YOUR_API_KEY**値を生成したAPIキーで置き換えてください。
|
||||
|
||||
## Development
|
||||
## 開発
|
||||
|
||||
<Warning>
|
||||
Make sure to run `yarn build` before any `zapier` command.
|
||||
`zapier`コマンドを実行する前に`yarn build`を実行してください。
|
||||
</Warning>
|
||||
|
||||
### Test
|
||||
### テスト
|
||||
|
||||
```bash
|
||||
yarn test
|
||||
@@ -58,25 +58,25 @@ yarn test
|
||||
yarn format
|
||||
```
|
||||
|
||||
### Watch and compile as you edit code
|
||||
### コードを編集しながら監視＆コンパイル
|
||||
|
||||
```bash
|
||||
yarn watch
|
||||
```
|
||||
|
||||
### Validate your Zapier app
|
||||
### Zapierアプリを検証
|
||||
|
||||
```bash
|
||||
yarn validate
|
||||
```
|
||||
|
||||
### Deploy your Zapier app
|
||||
### Zapierアプリをデプロイ
|
||||
|
||||
```bash
|
||||
yarn deploy
|
||||
```
|
||||
|
||||
### List all Zapier CLI commands
|
||||
### すべてのZapier CLIコマンドを列挙
|
||||
|
||||
```bash
|
||||
zapier
|
||||
|
||||
Reference in New Issue
Block a user