目的は、Swiftでのサーバーアプリケーション開発の安定した健全なエコシステムを作ることです。現在フォーカスしているのは、コミュニティが信頼できる高品質で十分にメンテナンスされたライブラリやツールの開発を促進することです。このトークでは、2018年9月にSSWGが発表されて以降の最近の開発を振り返ります。オープンになっていなかったプロセスや参加する方法、コミュニティとチームが行なっているプロジェクトやプロポーザルの詳細について説明します。Serverを使うのか。人にとっても良い、デベロッパーも大好き、安全、エクスプレッシブでローレベルからハイレベルまで対応できる、コードシェアリングにも便利。ガベージコレクション不要なのが気に入っています。リソースが競合する問題が発生するがSwiftにはその問題がないいくつかユースケースがあるIBMプラットフォーム、Vapor、Amazon(ビデオプロセッサーパイプライン)、Appleも小さなものから大きなシステムまでプロダクトに使っています。OpensourceKitura,Vapor、、、Appleからいくつかライブラリが出ています。FoundationDB、その他にもGoogleと一緒にGRPCがあります。真ん中のロケットマークがSwiftNIO、去年このステージでアナウンスされたものでしたここまではいいですよねではこれが自分にとって正しいものなのか。既存のシステムがあると思いますが、こたえは、Yesです。開発中のものがあります。DBとのやり取りが必要になってくる。DBドライバの状態はいろいろなものが混在してたくさんある。Cと組み合わされた勝ちがあるということでCクライアントに対応しているのでそれを活用できるということはあるが足りないものがある、一貫性が足りない。全体として一環とした同時実行モデルが存在していません。WebがブロッキングでDBがノンブロッキングだとうまくいきません。ノンブロッキングの場合にどういう種類のプログラミングモデルでどのFeatureなのか、色々なモデルが必要あと可観測性がとても重要システム全体として中を見ることができるようにする、全体を見ることができるようにする。テキスト情報で何が起きたか全部見ることが出来雨量にする。システムが大きくなったときにいろんなコンポーネントがロギングしている。いろいろなライブラリ、コンポーネントがあるなら同じようなロギング体制が必要。メトリクスも数字的な情報とか文脈を反映する情報、パフォーマンスなどをあつめる。すべてのコンポーネントの情報を一箇所に集めて表示したくなりますよね。それから追跡、システムを流れてコンポーネントに飛んだときにトラッキングできなければなりません。大きなシステムでは追跡が難しいのでTracingの仕組みが必要になる。ヘッダやエンベロープなどキューのペイロードにつくものですね。必要なレベルの統合がなされていないのでバラバラのところがあるのでもう少し一貫して統合する必要がる。Dockerも重要ですよね。macBookを使っていますが本番はLinux。コードのスプリットがあるかもしれません。本番のエミュレーションにはDockerが有効に働く。IBM、Apple、Vaporで行ったServerWorkingGroupSwift言語そのものの外の部分、Networking、HTTP、セキュリティに関する部分、こちらはSwiftNIO今足りないものを足している分散システムイベントドリブン、、、Evolutionと似ているピッチから投票、プロポーザル、それが終わってインキュベーションプロセスに入る。ライブラリが3つのレベルで受け入れられた段階。いくつか対応しているプロジェクトDeveloperが特定のSwiftバージョンをDockerベースで実行できるようにしたいコミュニティの努力で発展してきたいまオフィシャルな場所としてAppleのGithubに入っています。何が重要か、アーキテクチャーです。他のライブラリ、フレームワークをもってきたときにどこにログを送るか知らなくていい。アプリケーションオーナーがそれを決めることができる。全体の一つとして観測性を提供することができるが、すべてAPIベース。これは他のエコシステムの体験からもってきたものロガーがミューテーションする。typesystemを活用する。closureを使うログを送ることを遅らせることができる常に送るとパフォーマンスコストが高いログを取らなければいけないときは評価することができるメトリクスはまだプロポーザルフェーズです。API、メトリクスライブラリは切り分けられている。様々なシステムからメトリクスを見ていく。ライブラリは分けられているので、これによってライブラリは情報を、たとえばHTTP、Webフレームワークであれ、使っていただくことができる。個々ではこのメトリクスがどこに行くかを決めるのではない、これが重要な要素に成る。いうコードが書かれるのかCounterに対応しているモノリシックに増分していける。一つ、タイマータイプリクエストにどれくらい時間がかかっているのかという評価ができる。タイマーの形が非常に面白いのは、量化をしていくときに使うことができる。DBだとか、あるいはピークアワーオフピークアワーで変わっていくが実際に99%タイルがどうかというときにつかえる汎用的なReorderタイプが有るヒストグラムであればこうしたものがバックグラウンドのモデルとして使えるゲージも使えるDBクライアントPostgreSQLドライバを使ってSwiftNIOとのコンカレンシーモデルを作ったRedisで同じようなことをしようとされています。ネットワークライブラリ新しいバージョンリリースしましたSwiftNIOは主要な変更は5との協業性エコシステムのアンブロックをしてオンボーディングしていただきたいということで大きなバージョン変更。HTTP/2も比較的大きな変更がありました。Cライブラリベースだった。結果的にパフォーマンスをみていてCライブラリではないだろうということでSwiftで書き直しました。SSLも前のバージョンから変わってきましたBoring?SSLに寄ってできるようになったのがSwiftPMSwiftNIOベースアプリケーションのモビリティを高めた皆さんの参画をお待ちしています問題点、改善点などをお寄せください。フォーラムでいろいろな話があります色々ライブラリを書いていただきたいものがあります。Releaseが行われています。皆さんにもご参画いただきたいと思います。ありがとうございました。はてなブログPro大学時代に耳が聞こえない生徒が講義に参加できるようにリアルタイムに文字起こしするバイトをしていました。いまはエンジニアとして働きつつ、勉強会やカンファレンスで話される技術分野の知見を文章に残し、検索可能にしたり、地方で活動する方に届けたいと思っています。お役に立ちましたら、支援いただけると幸いです。(24)注目記事はてなブログをはじめよう!niwatakoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。