Questions and feedbacks

okuramasafumi
okuramasafumi commented 4 months

現在のBasecampでの「サイエンスプロジェクト」で話せることがあったら教えてください。

Like(0)

okuramasafumi
okuramasafumi commented 4 months

Basecampでは、複数モデルに渡る処理をどのように書いていますか?

Like(0)

aeroastro
aeroastro commented 4 months

モックのAPIやAPIドキュメントを作る作業はフロントエンドチームとバックエンドチームが共同で作る体制でしょうか?

はい。案件ごとの差はありますが、共同で作る体制が多いです。 例えば、満たすべき要件に対して両者で話し合いながら概念設計を進め、その結果をスキーマに反映し、モックのAPIやAPIドキュメントを作っていきます。バックエンドチーム、フロントエンドチームが、それぞれの得意な領域から、設計に対してフィードバックしていきます。設計の為のたたき台を作ったりする部分や、設計結果をスキーマに落とし込み、APIとして利用できるようにする部分はバックエンドチームが担当する場合が多いです。

APIの規模や難易度が大きくなるほど、よりスキーマ確定前の設計時の共同作業に比重が置かれる傾向があります。

Like(0)

aeroastro
aeroastro commented 4 months

命名変更以外の非互換 schema 変更を伴う場合の対応はどのように行っていますか?(versioning?)

まず、APIの出力に対して、新しい field を追加するという場合は、スキーマとしての互換性は失われますが、SDKを利用するコードに修正は必要無いため、そのまま追加を行います。

次に、APIの入力に対して、新しい field を増やすという場合は、スキーマとしての互換性は失われますが、バックエンド側で初期値を与えてあげることで、旧スキーマを参照する SDK からのアクセスも同一エンドポイントでハンドリング可能であるため、そのまま追加を行う場合が多いです。

fieldの削除等、 schema だけでなく、 SDK I/F としても互換性が失われるものについては、開発フェーズや、利用度合い等、様々な事情を考えた上で、様々な策が取られます。(詳しく説明すると非常に長くなってしまうので、すみませんが、今回は割愛させてください。)

これらが不適切となる運用段階での大幅な変更(大幅なschema変更や内部ロジック変更等)がある場合には、エンドポイントベースでの versioning を行 う場合があります。schemaから生成されるコードと、SDKの外部I/Fの間に層が存在することによって、SDK I/F としては同一のままになる場合もあります。また、APIの特性によっては、ロジックやデータのバージョンを示す field をスキーマ内に持つことで、新・旧の互換性を保持しているものもあります。

Like(0)

aeroastro
aeroastro commented 4 months

gRPCの利用は検討されたのでしょうか?

はい。検討しました。 しかし、プロジェクト当初は、RESTfulを選択することによる恩恵が大きいということで、開発者の意向として RESTful が選択されました。

これらの背景をより詳しく見ていくと以下のようになります。

  • RPC or RESTful という文脈においては、特に Rails においては、 RESTful を利用することによる生産性向上が大きかった。
  • そもそも、検討時における gRPC は、エコシステムも含め、今のように成熟したものではなかった。

また、SDK において開発者に使いやすい I/F を提供したいという都合上、カスタムのコードジェネレータを設計・実装する必要があるという部分は 、当時、仮にgRPCを導入していた世界線であっても、あまり楽にはならなかったのではないかと推測されます。

Like(0)

willnet
willnet commented 4 months

@indigolain

暗黙な依存が存在するfactoryに関して、これを良い感じにリファクタする方法やアプローチがあれば教えていただきたいです。

factorybotの定義を確認し、暗黙な依存があればそれを剥がした状態でテストを実行、コケたところを一つづつ修正していく、という地道な作業をしていくしか方法はなさそうです…。大変だと思いますが頑張ってください!

Like(0)

itkrt2y
itkrt2y commented 4 months

ライブラリの乱立が落ち着いたとはいえ、JSはパラダイムが広くやはり情報収集は難しいと感じています 板倉さんがどのように情報収集をされているか教えてください

「Webpackerは使うな」とちっちゃく書いてありましたが、よろしければ軽くお話いただけるとうれしいです。

いろいろ理由はありますが...

  • 不要なnpm package入れすぎ
  • 覚えること多すぎ。しかも、ほとんど不要
    • 個人的には、webpackを覚えるよりwebpackerを覚える方がはるかに難しいです
  • webpackの設定変更がwebpackerでラップされていることによって二度手間になる
  • 素のwebpackを理解することを遠ざけることにより、Railsエンジニアと他言語のエンジニアたちとのフロントエンド知識格差がどんどん広がっていく

webpackerのいいところって javascript_pack_tag を書くといい感じにscriptタグ書いてくれて再ビルドもdev serverを起動しないでも勝手にやってくれる、ってところだと思うのですが、それくらいなら自分で書いても大したことないので自分で書くといいです(参考: https://medium.com/takeyuweb-tech/rails-typescript-webpack%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89-21c4402bbb01

トークの紹介にあった

「今、なぜフロントエンドを学ばなければならないか」 「何を理解すれば、これからのフロントエンドを理解できるようになるか」 この辺りのお話をもう少しききたいです!

スライド最後のページを参照ということで

一瞬Elmの名前が映りましたが、来ると思いますか?

来ないと思います。ですが、Haskellなんかと同じで一部では重宝されるだろうし、来ないけど死ぬこともないライブラリな気がします。

Like(0)

kirikak2
kirikak2 commented 4 months

ActionTextはActionViewを使っていなくてSPA主体のアプリケーションでも何か恩恵をうけることは出来ますか?

Like(0)

banyan
banyan commented 4 months

@yaboojp

簡単な back-office などのちょっと JS を使いたい要件であれば普通に使うと思います。

Like(0)

banyan
banyan commented 4 months

@anonymous

  • cookie 系のライブラリで RFC6265 に準拠していると plus sign を encode しないですが、Rails はするために、converter などの処理があるライブラリを使っています。
  • 不便とは違いますが、preflight のリクエストが発生しないように同じドメインで受けて nginx 等で api サーバが assets に流すかなどをしています。

結構昔から SPA として切り分けているため、あんまり不便な点が思いつきませんね... すみません 😅

Like(0)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano