見出し画像

Bubbleの本番運用で辛かったこと3選

遅くなりましたが、実際にBubbleで本番運用した際に辛いと感じたことを3つ取り上げてみます。辛かったことは以下3つです。

1.(運用)プロダクトのUpdateの度に再読み込みが必要
2.(保守)機能が複雑化すると各処理の把握が困難
3.(保守)修正差分を比較できない

前提として運用と保守の内容になるため、少し細かい内容であったりプロダクトの性質によっては問題にならないものも含まれます。

1.(運用)プロダクトのUpdateの度に再読み込みが必要

Bubbleで開発を行ったことがある方ならわかると思いますが、Bubbleはデプロイをするたびに以下のような再読み込みを求めるメッセージが画面上部に表示されます。

スクリーンショット 2021-01-17 18.18.53

メッセージを直訳すると下記のようになります。

We just updated this page.
Please refresh the page to get the latest version.
You will not be able to use the app until you refresh.

(直訳)このページを更新しました。ページを更新して最新バージョンを入手してください。更新するまでアプリを使用できません。

別に開発中はリロードして反映を確認するだけなので問題はないのですが、サービスの内容によっては本番運用した際に困る場合があります。

例えば、ユーザーが文字を入力した後に保存ボタンを押そうとしたタイミングで、上記のメッセージが表示されると保存ボタンが押せないのでユーザーは入力を無駄にするか、別途コピーしてリロードしてもらうことになります。(初回の登録フォームでこれが出ると離脱しちゃいそうですよね。。)

さらにリアルタイム性が求められるサービス(例えばWEB会議をするようなサービス)だと一度切断をしてもらわないといけなくなるため体験は大幅に下がります。

ちなみにこの更新のメッセージですが、当該画面を修正していなかったとしても、どこか1箇所でも修正をしてデプロイすれば表示されます。(要するにデプロイを行えば、利用中の全ユーザに更新メッセージが表示されると言うことです)。そして、この仕様はBubbleのフォーラムでもかなり苦情の声が上がっていました。

上記の仕様に対して、自分が行った対策としては下記の2つです。

①更新メッセージの修正
抜本的な対策ではないものの、「入力している場合には別途テキスト等コピーして、再読み込みをしてください」と言うようなメッセージを設定しました。メッセージは下記から変更できます。

スクリーンショット 2021-01-17 18.38.30

②アクセス状況をリアルタイムで計測し、アクセスがないタイミングでデプロイ(アプリ更新)
15秒ごとに入力が大変な画面にユーザがいないかチェックするためのログを仕込みました。そして誰もいないのを見計い、更新を実施し、ユーザーに極力迷惑をかけないようにしていました。下記のURLが実装の参考になると思います。

2.(保守)機能が複雑化すると各処理の把握が困難

1つ目の説明が重かったので、2つ目はさっくり行きます。
機能が複雑化する見込みがある場合にはワークフローが非常にややこしくなるのでBubbleはおすすめしません。最も処理が重い画面で35個ほどイベントがあるのですが、その1つの中にも処理が5~10ぐらい入っているので完全に訳が分からなくなってきましたw

画像3

対策としては、Customのイベントを作成し、共通処理を行うことで処理の数を減らすとかでしょうか?とはいえ、イベントの数自体は減らせそうにはないのであまり効果的ではないと思います。

3.(保守)修正差分を比較できない

コードであればこのように修正前後で差分が見れますが、Bubbleでは見れません。

スクリーンショット 2021-01-17 19.05.00


上記のような形で表示されていれば、デプロイするときにこの処理の修正が間違っていそうだとか、逆に修正が必要にも関わらずは差分が出ていなければ修正漏れだと気付けるのですが、Bubbleは1つ1つイベントを開いて目で追っていくしかありません。もし見落としていた処理があったら不具合につながる。。と思うと怖くて修正箇所が多い場合には、かなりビクビクしながらデプロイをしていました。

まとめ

今回は以上になります。前回の記事はメリットを記載して、今回の記事はデメリットを記載しました。

改めてBubbleのメリットは「開発の早さ」と「費用があまりかからない」ことの2つであり、小規模開発やMVPには非常に向いていると思いました。

反対にデメリットは「運用・保守性の低さ」とそれゆえ「チーム開発・中〜大規模に不向きである」と言う点だと思います。(ゆくゆく大きくなるプロジェクトであれば移行を行うべきかどうかも検討をしておいた方が良いと思います)

デメリットに関しては韻を踏んで激しくディスりたかったのですが、ちょっと思いつかなかったのでやめましたw
あと、ここには書きませんでしたが、不具合発生時のログの見方が初見だと分かりにくくて苦労したので次回はその辺りも記載しようかと思います!

では、最後まで読んでくださりありがとうございました。

この記事が気に入ったらサポートをしてみませんか?