ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探るGraphQL この記事は GraphQL Advent Calendar 2020 13 日目の記事です。 前回の記事は @maaz118 さんの GraphQL の @defer, @stream ディレクティブを試してみる でした。 GraphQLにおける2つのPagination方式 Offset-basedとCursor-based GraphQLにおけるpaginationには、Offset-based paginationとCursor-based paginationの2つが主な方法としてあります。 GraphQLの公式ページには3つの例が載っています。 https://graphql.org/learn/pagination/#pagination

この記事は GraphQL Advent Calendar 2020 10 日目の記事です。 前回の記事は @mtsmfm さんの Swift 用 graphql-codegen plugin の graphql-codegen-swift-operations を作った でした。 はじめに PrismaはGraphQLを実装するためのクライアントライブラリ,ORM(Prisma1においてはGraphQLサーバ自体も含む)として広く知られていると思いますが、Prismaはversion2(以下、ただのPrismaと書いている箇所はPrisma2を指します)より、ORM部分に注力し、GraphQLとは直接関係ない方向に成長していく方向に舵を取っています。 (参考: https://www.prisma.io/blog/prisma-2-is-coming-soon-mwwfhevie993)

この記事はfreee Engineers Advent Calendar 2016の5日目です。 こんにちは、freeeのエンジニアの @joe-re です。 僕からはflowtypeによる、Fluxアーキテクチャへの型システムの導入についてお話しさせていただきます。 背景 Reactによるコンポーネント指向設計、Fluxによる単方向フローによって、僕たちは階層化されすぎているViewにおけるイベントの発行と購読、煩雑なDOM操作と状態管理から解放されました。 Fluxアーキテクチャにおいては、Component、ActionCreator、Storeがそれぞれの層で完全に分離されています。StoreはComponentの存在を知らないし、ComponentはStoreを購読するだけで中のロジックは一切知らないし、ActionCreatorはただの関数群です。 チーム開発の中でこの関係性を

背景 ひと昔前までフロント側build toolと言えば grunt が主流でしたが、今は gulp が主流になりました。 gulpは現在のところ3.9が最新ですが、水面下では4.0が準備中です。 4.0は久しぶりの major version release だけあって、結構な breaking changes が含まれる予定です。 4.0がいつリリースされるかは分かりませんが、 4.0 branch は用意されていて、そのほとんどの機能はもう動かすことができます。 本エントリではchangelogを見ながら、その機能を実際に試していって、どういったものか説明していこうと思います。 今回書いたコードはgithubにあげたので、もし試したい方がいればどうぞ。 資料 changelog API document バージョン $ ./node_modules/gulp/node_modules

背景 僕が本格的にWebのエンジニアになったのは2014年頃からで、早いものでもう丸2年ほど経ってしまうことになります。 Webに転向してからは主にフロントエンドエンジニアとして勤務してきました。 よく言われることですが、最近のフロントエンドの趨勢は本当に早いです。 最初はキャッチアップに苦労したことを覚えています。 しかし段々と新しい何かを覚えることは苦でなくなり、今はこの流れに身を置くことが楽しいと思えるようになってきました。 激動の趨勢の中で、Webのフロントエンドエンジニアが口にするパラダイムは日ごとに変化しています。 この記事は元々社内向けに書いたものです。 色々なバックグラウンドを持つエンジニアと一緒にフロントの設計を考える場面で、共通言語を持つきっかけになればいいなー、という思いから書いたものですが、いい機会なので外向けに修正して公開してみます。 Webのフロントエンドを新し

2017/1/8 追記 ※ この記事の内容は古い(React.PropTypesへの型チェックなどはすでにundocumentedになっている)ので、 http://qiita.com/joe-re/items/d6fd262a8c6017f41e22 を参照してください。 Flowtype is 何 Flow is a static type checker, designed to find type errors in JavaScript programs: とある通り、JavaScriptの世界に静的な型チェックを導入するものです。 /* @flow */ function foo(x) { return x * 10; } foo('Hello, world!'); というコードは、foo関数の実行時にstringを渡しています。 しかしfoo関数は、引数(string)と10

こんにちは、freeeでフロントエンドエンジニアをしている @joe_re です。 freee Engineers Advent Calendar 2015の4日目を書きます。 僕からはfreeeで現在進行中の革命について、フロントエンドのビルドプロセスを中心に書こうと思います。 革命 ってなんのこと？ というのはフロントエンドヤンキーこと @ymrl が 2日目で書いたので詳しくはそちらをご参照頂ければ幸いです。 背景 弊社ではRuby on Railsを主軸にしてWebサービスを作っています。 Railsは素晴らしいフレームワークですが、めまぐるしく変化する昨今のフロントエンドについては、このままRailsの用意しているRailに乗ったままでは時代に取り残されてしまう危機感があります。 僕たちは時代に取り残されている場合じゃない。 最先端でかつ適切な技術を用いて未来を切り開いていかなく

背景 gulpでフロントエンドのビルドプロセスを組んでいるならSprocketsを通さなければ良い。 と言いたくても、なかなかそうすぐには完全移行はできず、ビルドしたものはapp/assets/配下に出力して最終的にはSprocketsさんにどうにかしてもらっている日々を過ごしています。 そんな中でscssのビルドをgulpに移行したのですが、Sprocketsでは.cssファイルではimage-urlやasset-urlなどのhelperメソッドが使えず、imageのasset_pathが解決できません。 とはいえ、せっかくフロント側でlibsass使ってビルドしたものを.scss拡張子に戻して、再びSprocketsのScss Processorにかけるなんてリソースの無駄すぎて嫌だ。(libsassに比べると、ruby-sass遅過ぎる。) じゃあ無理やり.css.erbに変換するか

小さいアプリケーションなら、styleは変更がある度に毎回フルビルドしてしまっても1sもかからないかもしれない。 しかし大きくなって、5s以上かかると非常に苦痛だ。 というわけで差分ビルドしたい。 Sassの差分ビルドで問題になること 差分ビルド自体は簡単で、gulp-cachedとかを使えば、前回と差分があるものだけをビルドできる。 なんだけど、その場合に問題になるのがsassの依存関係(@import)の解決だ。 単純に差分のあったファイルをビルドするだけだと、@import元を辿れない。 そうすると@import元のファイルが変更についてこない。 いや、でもnode-sassのwatchオプションって@import元辿ってるよな、あれってどうなってるんだ？？ と思って実装を見てみたら、sass-graphというnpmを使って辿っていた。 お、これ使えば差分ビルド時に依存関係の解決もで

はじめに 最近Mithril.jsで遊んでいる。 Mithril.jsは最近流行りのReactと同じ仮想DOMな実装のjsフレームワーク。 とにかく速度が爆速で、Reactの5倍速いらしい。 ↓の記事がすごく分かりやすい。(僕がやってみようと思ったきっかけもこの記事でした。) 最速MVCフレームワークMithril.jsの速度の秘密 - Qiita 上記の記事にも書いてあるけど、Mithrilはredrawするタイミングが少し特殊で、それが高速化の一端を担っている。 ブラウザから画像をアップロードして、プレビューする実装をしてみて、その辺が理解できたので紹介。 環境 Mithril.js 0.2 資料 auto-redrawのタイミングに関する公式ドキュメント コード imageView = {} imageView.vm = init: -> @image = m.prop(null)

はじめに react-railsという、ReactをAsset Pipelineに乗せて使えるようにしてくれるruby gemsがある。 この記事では、これを使用してReactの公式tutorialを進めていく。 公式のtutorialではサーバ側はすでに実装済みとして進んでいる。 今回はせっかくなのでtutorialを進める中でサーバ側も実装していくことにする。 ちなみに使ってみた個人的な感想としては、RailsのAsset Pipelineに乗せるならすごく順当かなー、という感じ。 browserifyを使いたい。bowerもオワコンと呼ばれてしまう。そんなこの時代。 Asset Pipelineは捨てたい感じがあるけど、既存のアプリケーションを徐々にReactコンポーネント化していく、みたいな時には良いと思う。 方針 きまぐれで、必要そうなところはReactの説明する。けど英訳とかは