さきにお断りをいれておきます。
昔話を交えながら、Strapiってこんな風につかうのかな？という私感を書いたポエムです。
そして、私はStrapiを使ったことがありません。社内で別なチームがStrapiを使って開発していることを傍らで見た印象で書いています。

結論から言ってしまうと、、、

このStrapi Advent Calendarでは、他のHeadlessCMSの比較や動かし方がわかりやすく書かれており、開発の省力化に貢献すると思うので少数精鋭でプロダクト開発しているチームなら利用することを検討してみては？と思います。

Strapiはデータモデルに従ったBackend APIを提供してくれる

Tomigieさんが書いたStrapi Quick Start Guide 日本語訳を見てもらえうと分かる通り、Content-Typesを作成してPublish操作などすることで自動的にAPIが生成されます。
生成されたAPIも山上さんが書いたブログの通り、カスタマイズすることができます。

そのため、DB定義やデータモデルが決まっていれば、Backendが簡単に生成することができるのでオススメです。

あとは、FrontendとBackendを開発チームが別々に作る場合、BackendのモックAPIサーバとして利用することもできそうです。というのも、このStrapi PluginでSwaggerを生成できるため、先行してFrontendを作成して、Strapiで生成したSwaggerをもとにAPIを製造していくこともできそうです。

Strapiを使うときの勘所

Strapiを使う場合の勘所としてはデータモデルをベースにコードを生成しているので、モデル設計が緩い状態では自動生成するとは言え、戻り作業が増えるので注意が必要になりそうなイメージです。
CRUDのAPIが生成されてURLも /{Content-Types}/:idという感じになるため、モデルのキーが変わった場合に影響が大きそうです。

スクラム開発でもウォーターフォール開発でもデータモデルがキモだったりしますので、そこのブレが少なくなってから使ってみるのが良いと思われます。

このStrapiでは、APIを自動生成しますが、REST APIを設計する時の勘所がとても良くまとまったブログがクラスメソッドの都元さんが書かれているので、ご紹介しておきます。

Classmethod Developers.IO: Developers.IO 2018 で「API 設計」の話をしてきた

さて、昔話ですが、、、

昔からコードを書く量をいかに少なくして、プログラマーがよりクリエィティブなUXの向上やマネタイズな部分に時間を使えるようにするか？が至上命題でいまでも苦心していることが多いと思います。Strapiではモデルを作成することで、モデルに対応するCRUDのAPIが生成されるようになっています。

その昔、カード型データベースと呼ばれるデータを単票形式で保管することに特化したものがありました。これは、現在の年賀状ソフトの住所録をイメージしてもらうとわかり易いと思います。UIとして個人の住所を登録するものがあり、UIから直接にDBへ記録されます。
個人の住所録など小規模であれば、メンテナンスや検索速度の問題は顕著になりませんが、大規模になった場合には単票の検索性の悪さや単票１枚に項目が多くなったり、冗長な項目が増えてデータの肥大化するなどの問題が発生します。

手軽なUIとRDBのいいとこ取りを目指した例として、マイクロソフトAccessを挙げることできます。
Accessでは、DBのテーブル項目をUIのフォームへ配置し、UIから直接CRUDを実現することができました。また、一覧画面を作ればテーブルのデータを全て閲覧したり、フィルタすることができました。
この状況は、簡便な方法としてCSS（クライアント・サーバ・システム）と呼ばれるシステムでも利用されていました。（もちろん、CSSでFrontendをVBやCで組んで、DBとの関係性を疎にする仕組みが多数を占めるようにはなっていました）

その後、時代はWebになり、FrontendとDBがつながっていた関係性からFrontend＋Backend＋DBという３階層のプログラム構成になり、MVC/MVVCといわれるアーキテクチャになりました。FrontendではAjaxを使って非同期で処理しつつ美麗なUIを表示し、Backendではバッチ処理で実施していたような複雑なビジネスロジックの実装が必要になりシステムが巨大化していきました。

巨大化システムをいかに素早く作るかということで、ソースコードの自動生成システムが大手SIerを中心に開発されて発売されていました。仕組みは、だいたい一緒でシステムで取り扱う項目（画面、DB）を洗い出して、その項目をモデルとして登録し、そこからBackendを生成するものでした。（O/Rマッピングを生成する感じですね）
項目を一元管理して、そこから生成するのでケアレスミスを少なくすることができ、冗長なコードをプログラマーが書かなくてもよく、開発スピードが上がることが期待されていました。筆者の経験としては開発スピードは速くなった気がします。仕様が揺らぐプロジェクトでDB設計が変わると影響範囲が大きくなりがちで苦労した思い出はあります。

このStrapiでもデータモデルに変更があった場合、大きな影響が予想されるので、しっかりとユーザーストーリーやユースケースが洗い出されていることを重要かもしれませんね。