バックエンドとフロントエンドの処理分担

IM-LogicDesigner（バックエンド）とIM-BloomMaker（フロントエンド）を組み合わせた開発では、処理をどちらでも実装できる場面が多くあります。こうした場面でどちらに実装するかの判断を個々の開発者に任せると、プロジェクト全体で実装方針がそろわず、あとから手を入れにくいシステムになりがちです。

ここでは、このような課題に対する処理分担の考えかたについて、ルールの一例を紹介します。あくまで一例のため、このルールを強制するものではありません。ルールはプロジェクトやチームの方針に合わせて調整してください。

注記

処理分担の考えかた自体は、ローコード開発に固有のものではありません。ソフトウェア設計に共通する一般的な論点で、このページで紹介するルールも、その一般的な考えかたをもとにしています。

ルールが必要な理由

処理分担のルールを決めておかないと、次のような問題が起こりやすくなります。

• 類似処理がバックエンドとフロントエンドに重複して実装される
• 本来共通化すべきビジネスロジックが画面ごとに分散する
• 機能追加のたびに「どちらで実装するか」の議論が発生する
• 開発者によって実装方針が異なり、一貫性が損なわれる

このため、開発効率や保守性の観点から、あらかじめ処理分担のルールを決めておくことをおすすめします。

責務を整理する

バックエンドとフロントエンドには、それぞれ得意とする処理があります。特性を活かし、適切に役割分担することで、保守性や再利用性の高いシステムを実現できます。

責務分担の早見表

領域	担当技術	おもな責務
バックエンド	IM-LogicDesigner	ビジネスロジック、データ処理、共通処理
フロントエンド	IM-BloomMaker	UI制御、画面表示加工、ユーザ操作

責務の詳細

バックエンドとフロントエンドのおもな責務は次のとおりです。

バックエンド（IM-LogicDesigner）

• データベースアクセス：CRUD操作や複雑なクエリ実行
• ビジネスロジック：業務ルール、計算処理、データ変換
• 共通処理：複数画面で使用される処理
• 外部システム連携：API呼び出しやファイル処理
• データバリデーション：バックエンドでの入力値検証

ヒント

バックエンドには、画面に依存しない汎用的な処理を実装します。これにより、複数の画面から再利用しやすくなります。

実装すべき処理の例：

データベース関連

• ユーザ情報の登録・更新・削除
• 複数テーブルを結合した検索処理
• トランザクション制御が必要な処理
• 大量データの一括処理

ビジネスロジック

• 価格計算、税率計算
• 在庫管理ロジック
• ワークフロー制御
• 承認プロセス処理

共通処理

• ログイン認証処理
• 権限チェック処理
• メール送信処理
• ファイルアップロード・ダウンロード処理

フロントエンド（IM-BloomMaker）

• UI制御：画面要素の表示・非表示、有効・無効制御
• 画面表示加工：データフォーマットや表示用の変換
• ユーザ操作制御：ボタンクリックや画面遷移
• 入力支援：リアルタイムバリデーションや自動補完
• 画面固有ロジック：その画面でのみ使用される処理

警告

フロントエンドの処理は、あくまで表示や操作性の改善を目的とします。重要なビジネスロジックは、セキュリティや一貫性を保つためバックエンドで実装してください。

実装すべき処理の例：

UI制御

• 条件に応じたボタンの有効・無効制御
• 入力値に応じた項目の表示・非表示
• プログレスバーやローディング表示
• モーダルダイアログの制御

画面表示加工

• 日付フォーマットの変換（2024/11/18 → 令和6年11月18日）
• 数値の桁区切り表示（1000000 → 1,000,000）
• ステータスに応じた色分け表示
• 一覧データのソート・フィルタ

画面遷移・リンク制御

• 一覧画面から詳細画面への遷移リンク
• パンくずナビゲーション
• タブ切り替え制御
• 条件に応じた画面遷移先の分岐

入力支援

• リアルタイム入力チェック
• 自動計算機能（単価 × 数量 = 金額）
• 住所の自動補完
• 入力候補の表示

ケースごとの処理パターン例

実際の開発では、データの加工・取得方法や、アクションの呼び出し方法、トランザクション処理などのケースで、バックエンドとフロントエンドの分担をどのように組むかの判断が必要になります。ここでは、おもなパターンと、そのメリット・デメリットを紹介します。

注記

略称表記

• LD：IM-LogicDesigner（バックエンド）
• BM：IM-BloomMaker（フロントエンド）

データ加工

画面表示用に整形されたデータを返すか、生データを返して画面側で整形するか

例：日付表示の場合

• バックエンド側加工：2024-11-18 を 2024年11月18日 に変換してから送信する
• フロントエンド側加工：2024-11-18 を受信後、画面で 令和6年11月18日 に変換する
• ハイブリッド：基本形式 2024年11月18日 で送信し、画面で和暦に変換する

実装パターン	責務分担	適用場面	メリット・デメリット
バックエンド側加工	LD：データ取得＋表示用加工 BM：受信データをそのまま表示	バックエンドに処理を集約したい場合	✅BM側の処理を単純化できる ❌表示領域ごとにLDの作成が必要 ❌LDでの処理が増加する
フロントエンド側加工	LD：生データの取得のみ BM：データ受信＋表示用加工	画面固有の表示形式に対応する場合	✅LD側の処理を単純化できる ✅画面変更への柔軟性が高い ❌BMでの処理が増加する ❌カスタムスクリプト実装がほぼ必須
ハイブリッド	LD：基本加工まで実施 BM：最終的な表示調整	汎用性と柔軟性を両立したい場合	✅対応力が高い ❌責務境界があいまいになりやすい

データ取得

画面表示に必要なデータを、どのような粒度のロジックフローで取得するか

例：顧客詳細画面の場合

• 単一フロー統合：顧客・注文・商品をひとつのSQLでJOIN取得する
• 分割フロー：顧客情報取得 → 注文履歴取得 → 商品詳細取得
• 段階的取得：顧客情報を取得し、必要時のみ詳細注文情報を追加取得する

実装パターン	責務分担	適用場面	メリット・デメリット
単一フロー統合	ひとつのSQLで全データを取得 LDフロー：1件／BMアクション：1件	関連性の高いデータをまとめて取得する場合	✅シンプルで高速 ❌SQLが複雑になりやすい ❌再利用性が低い
分割フロー	テーブルごとにSQLを分割 LDフロー：複数／BMアクション：複数	独立性の高いデータを個別に取得する場合	✅再利用性が高い ✅保守しやすい ❌処理回数が増加する
段階的取得	必要に応じて段階的に取得 LDフロー：条件分岐あり／BMアクション：1件	大量データや条件付き取得の場合	✅効率的で柔軟 ❌制御が複雑になる ❌デバッグが難しい

アクション連携

ユーザ操作1回に対して、BMアクションからLDを何回、どの単位で呼び出すか

例：商品登録処理の場合

• 単発実行：「登録」ボタン → 商品登録LDを1回呼び出す
• 連続実行：「登録」ボタン → 商品登録 → 在庫設定 → カテゴリ更新を順次実行する
• 段階実行：「基本情報入力」→「詳細設定」→「最終確認」→「登録実行」

実装パターン	責務分担	適用場面	メリット・デメリット
単発実行	BMアクション1件でLDを1回呼び出す	単純なCRUD操作	✅シンプルでわかりやすい ❌機能拡張時の柔軟性が低い
連続実行	複数のBMアクションでLDを複数回呼び出す	関連する複数処理をまとめる場合	✅トランザクション制御が可能 ❌処理時間が増加する
段階実行	処理段階ごとに分割してLDを呼び出す	ウィザード型処理	✅UX向上、中断可能 ❌状態管理が複雑になる

トランザクション管理

複数のデータ更新をひとまとまりの処理として扱うトランザクション制御を、どこで実装するか

例：注文処理の場合

• LD側で単一制御：注文登録 → 在庫減算 → 決済処理をひとつのLDフロー内で制御する
• サブフローによる複数制御：メインフロー（全体制御）から、注文登録サブフロー・在庫更新サブフロー・決済処理サブフローを呼び出す
• BM側制御：注文情報入力・確認・決済の各段階で、BMアクションが制御する

実装パターン	責務分担	適用場面	メリット・デメリット
LD側で単一制御	LDフロー内でエラー処理フローを含めて単一制御する	複数テーブルを同時に更新する場合	✅データ整合性を保証できる ❌フローが複雑化する
サブフローによる 複数制御	メインフローがサブフローを呼び出し、サブフロー単位で制御する	処理単位でトランザクションを分離する場合	✅処理単位で制御できる ✅再利用性が高い ❌フロー設計が複雑になる
BM側制御	LDを分割し、BM側のアクションから複数回呼び出して制御する	画面操作と連動する場合	✅UXを向上できる ❌整合性の管理が難しい

備考

サブフローを使用したトランザクション制御の詳細については、トランザクションを使用する（IM-LogicDesignerチュートリアルガイド）の記載を参照してください。

業務シナリオでの適用例

実際の業務システムでよく登場する処理を例に、バックエンドとフロントエンドの分担を示します。

ユーザ登録処理

バックエンド（IM-LogicDesigner）

• ユーザ情報のデータベース保存
• メールアドレス重複チェック
• パスワードハッシュ化
• 登録完了メール送信

フロントエンド（IM-BloomMaker）

• 入力フォームの制御
• リアルタイム入力チェック（文字数、形式）
• パスワード強度表示
• 登録成功・失敗メッセージの表示

商品一覧・詳細画面

バックエンド（IM-LogicDesigner）

• 商品データの検索・取得
• 在庫数の計算
• 価格計算（割引適用など）
• 商品カテゴリの階層取得

フロントエンド（IM-BloomMaker）

• 一覧データの表示制御
• 詳細画面への遷移リンク生成
• 商品画像の表示制御
• 在庫状況に応じた表示色の変更
• 検索条件の保持・復元

判断に迷ったら

処理の性質によっては、どちらで実装すべきか判断に迷うこともあります。次の観点を参考に、どちらで実装するかを検討してください。

判断基準：汎用性や重要度の高い処理はバックエンドに、画面固有の処理はフロントエンドに実装する

バックエンドでの実装を検討すべき要素

• 複数の画面で使用される処理
• データベースアクセスが必要
• セキュリティ上の重要な処理
• 外部システム連携が必要
• 複雑なビジネスロジックがある

フロントエンドで実装を検討すべき要素

• 特定画面でのみ使用される処理
• UI/UXの向上
• リアルタイム処理
• 表示形式の変換