麺つゆで麺食うときだいたい生姜入れてもいけるんだけど、そもそも最近麺つゆで麺を食わない
For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
PayPayは決済が完了したことを相互がわかりやすい手段が必要だってなったときにもっとかしこいソリューションを提案できなかったエンジニアか、それを採用しなかったビジネス側がダメ
みんながAPを取れない理由がわかってきたぞ…
申し込みが始まったというのに一向に申し込みフォームを開く気力が出なくてそもそも申込試験がクリアできない…
うちのマルチアカウントはTerraformで展開してるけど正直そんなにメンテしてないしなぁ
ちゃんとロールとか振りたくはあるよね(自分でやりたいとは言っていないのでインフラエンジニア募集中)
これは悪い癖なんですが、Kotlinでモデル定義するだけでGraphQLサーバー起動できるフレームワーク作ろうかなとかいう気がもたげてきています
どうせ途中で投げ出すからやめなさい
でもまぁ、普通にモデルに @GraphAccessible みたいなアノテーションをつける必要はありそうで、そういう方向性を考えるとJava系言語でのGraphQLフレームワークはかなり未来がありそう
ちなみに多分GraphQLの良さを保ちながらアクセス管理をする方法はあって、それはモデル側にアクセス境界を定義することですね
ただ、それをやるとなると多分現時点では自作フレームワークを構築する羽目になるのであまり得策でなさそう
結局それってせっかくGraphQLでエンドポイント単一にしたのにこのリソースはこのフィルタリング処理みたいな掛け方をしてるはずで、どう考えてもメリットがない
アクセス権限がないリソースも一覧には含めて一回返してからエッジでフィルタリングするみたいな挙動をしていて、空っぽなのに次ページはあるみたいなページネーションの応答が帰ってくる それがFacebook Graph API
これはFacebookの例で、マイクロサービス化の影響もあると思うんで一概にGraphQLがとは言えないんですが、奴らのAPIはGraphQLを語っておきながらクエリチェイン出来ないCollectionがあったりするので、かなり苦しそうな感じがあります
このアカウントは、notestockで公開設定になっていません。
更新はGraphQL向いてないのすごく正しい
GitHubのGraphQLでの更新はなんか残念だし、FacebookはもうGraphQLであることをを諦めてる感ある
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
GraphQL、扱うオブジェクトの権限管理とかがなくてモデルのデータ全部吐き出していいんだったら採用するとこういう利点があると思うし、逆に外部にオープンにしてるような攻撃受けやすい環境では使うべきじゃなさそう
このアカウントは、notestockで公開設定になっていません。