たつのおとしごのしっぽ

技術に楽しくしがみつく えんじにあ の備忘録

【Engineering Team Presentation】各社の事業を支えるアーキテクチャの感想

イベント参加

【Engineering Team Presentation】各社の事業を支えるアーキテクチャ - connpass

日経電子版のキャッシュ戦略

  • API-Secret発行のルール
    • APIkeyの中に検索して出にくい文字列を入れておく
    • Secretの種類判別が可能
    • GitHub検索をかけて流出に気付ける
  • 表示速度によるWebの離脱率が上がっている
  • 性能チェックはサーバーログではなくフロントエンド側でやるのが望ましい
    • サーバーログだと正しく測定できない
  • レイヤーごとに色々なキャッシュがある
    • ブラウザキャッシュ
      • 再利用時の通信量が減らせる。最速
    • CDNキャッシュ
      • 配信目的なら高効率
    • Appバックエンドキャッシュ
      • バックエンドAP Iが落ちたときの代用が可能
  • push通知後はアクセス数が増える(10倍近く)

Mercari iOSクライアント Re-Architectureのその後

micro view controller

  • ViewControllerを分割する
  • UIStackViewで繋げてUIScrollViewに載せる
  • iOSのAtomicDesignのような印象(感想)

Stateの管理が大変

  • Fluxライクな方法、Store、Action、Dispatchで管理する

Declarative UI　についてはこの辺りをみると良さそう
https://old.black/2020/10/06/what-is-declarative-ui/
https://stackoverflow.com/questions/33655534/difference-between-declarative-and-imperative-in-react-js

新規事業「Bill One」を加速させる技術選択

  • バックエンド

    • Kotlin＋Ktor

  • DDD

    • エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) を読もう

クリーンアーキテクチャ脱却とSwiftUI導入までの道のり

  • MVP、MVVM、CleanArchotectureなどの混在設計

    • 長いプロダクトではありがちらしい

  • MVVM＋CleanArchitecture から MVC＋Storeパターンに

    • -> UIの変更の修正がしやすくSwiftUIに移行しやすい
    • CleanArchitectureから脱却したのはアプリ側にビジネスロジックがなく単純であったため
    • 複雑な画面はStoreパターンやFluxに近い設計になる。State構造体で管理する

質問の回答も興味深かったです。
Androdiの設計

Androidは基本をMVVMにして、Repositoryを用意するような設計になっている
Androidの設計にあたってはGoogle推奨の設計ドキュメントが公開されているため
iOSは表示周りはFrameworkに依存していて共通化が難しい

会計 freee バックエンドの今後

  • 開発者がみるべきスコープを決める
    • 機能をマイクロサービス に切り出す
    • 機能を分離する目的だけだとまずい

巨大なモノリスで辛かったためModular Monolith で設計する
-> アプリ内をドキュメントごとにモジュールに分解する

https://www.infoq.com/jp/news/2019/10/shopify-modular-monolith/ より Shopify の Modular Monolith について

拡大に伴ってShopifyは保守不能になり始めたため、新しい機能を提供することが難しくなった。例えば、ひとつのコードの変更によって、一見無関係なコードに意図しない副作用が発生したり、アプリケーションのビルドとテストに長時間を要したりするようになったのだ。
...

私たちがモノリスの望ましい部分として考えていたことのすべては、コードの所在とデプロイ先がひとつの場所であることの結果である、ということが分かりました。同時に、私たちが問題だと考えていたことのすべては、コード内の異なる機能間にバウンダリが欠けていたことの直接的な結果である、ということが分かったのです

モノリスのような単一で展開可能なユニットを維持しながら、マイクロサービスのようにシステムのモジュール性を高めることが設計目標であるという認識に達したのだ、とWesteinde氏は説明する。これを実現するため、Shopifyでは、モジュラモノリス(modular monolith)パターンを採用した。この方法では、コード間のバウンダリは可能になるが、コードは同じ場所に配置され、同じ場所に展開される。

下記の記事なども良さそう
https://qiita.com/tkyowa/items/ae9fa550237cb6f48318