カミナシ・エンジニアの@issei です。
先日行われたGo conference にてgoldスポンサー枠にて登壇してきました。
kaminashi-developer.hatenablog.jp
本日は、その際のカミナシ側の登壇資料を紹介します。
発表趣旨
カミナシではバックエンドのAPIサーバーの開発にGolangを利用しております。
カミナシからは「ノンデスクワーカー向けノーコードサービスのつらみ・うまみ」というタイトルにて、 デスクレスSaaSというあまり前例の無いサービスにおいてGoをどう利用しているのかについて、発表させていただきました。
カミナシについて
製造現場等のノンデスクワーカの分野では、まだまだ紙を主役とした人力の業務フローがメインです。 結果としてミスが多くなりがちになり、基幹業務外の仕事に時間を割かれがちになってしまいます。
カミナシでは、このような紙を主体とした業務フローをデジタル化し、ノーコードで作成できる現場管理アプリを提供しています。
木構造な内部データ
ノーコードサービスゆえ、内部データが木構造で定義されており、これによりサービス内でのloop処理や条件分岐処理等をユーザが直感的に使用できるようになっています。
これにより、ユーザー自身がノーコードで独自のワークフローを作成・編集できるようになっています。
開発におけるうまみ
Goをサービスに用いることで当社が開発を通じて感じたうまみを紹介しました。
多階層テーブルと静的型付けとの相性
多階層なテーブルを扱うサービスを開発する上でのGoの静的型付けの特性から受ける恩恵について紹介しました。
他言語からの敷居の低さ
当社エンジニアの入社前の使用言語を例にGo未経験から実務をこなすまでの敷居の低さの恩恵を紹介しました。
開発におけるつらみ
Goをサービスに用いることで当社が開発を通じて感じたつらみを紹介しました。
カミナシでは、リレーションを多くもつデータ構造ゆえ、gormに関わるつらみを中心に紹介しました。
コード行数の増加
テーブル間のリレーションが多い分、preloadを多用しがちになるほか、 (genericsがないことからの) switch文やforloopの多用、によって可読性が落ちてしまうつらみを紹介しました。
RDBでの性能低下
上記で述べた通りpreloadを多用しているので、ORM側で大量のクエリを発行してしまい結果、 application⇄DB間の通信回数が増加することでRDBでの性能低下につながってしまったつらみを紹介しました。
上記への対策として、
- application側では、ORMから一部、テーブル結合を行うような生クエリに書き換えを実施
- DB側では、外部キーに対するindexの追加を実施
することで、両者間の通信速度が改善された事例を併せて紹介しました。
テストデータの用意
多階層なデータ構造ゆえ、テストデータをJSONにて愚直に書いてしまうと用意に膨大な時間がかかるため、自動でエンティティを生成できるような外部モジュール ( factory-go )を使用した事例を紹介しました。
まとめ
現在カミナシではデスクレスSaaSというあまり前例の無いサービス開発をしており、やりがいがある一方で、今回共有した通りまだまだ多階層なテーブルデータを扱うための課題感があるのが現状です。
これらの課題に一緒に取り組んでくれる方、現場ドリブンにて現場の反応を直に感じながらのサービス開発志向のある方等、 EM/アプリエンジニア/SREと幅広く募集しておりますので、ご応募お待ちしております！
