development主張Node.jsは現状フロントエンドユーティリティに最も適しているNode.jsは一般にサーバーサイドでの運用は難しいし、自分もそう思うどうせやるなら、Node.jsにしかできないことをやるべきだNode.jsのキラーアプリはRailsクローンではなく単体ソースからクライアント・サーバーのコードを同時に生成するIsomorphicフレームワークであるべきだ。Isomorphicなフレームワークを自分で作ってみたいと思っていた。今ならせめてConceptualな実装ぐらいならいけるのではないか、という着想があった。着想React、renderComponent以外はサーバーでも動くし、データドリブンな設計すればギリギリまでサーバーで動いてそのレイヤーでテスタブルにできるんじゃないだろうかrenderComponentの部分を専用のラッパで呼んでやれば完璧なラッパーでnodeで走らせてテスト出来て最高なのでは?クライアントではできないStorageが抽象化APIがあると嬉しいよなStorage抽象、Meteorぐらいしかみたことないし作ってみるかAPI案まずはDBを扱うStorageクラスだけ実装しようとしてみた。いうかここがキモになる(と、最初は思っていたら最難関だった)。dataクライアント・サーバーで両方共こんなAPIが動いてほしい。サーバーでもバリデーションできると嬉しい。サーバーに投げて404の返事が来る前に弾かれるんならクライアントで叩きたい。Mongoose(mongo)で決め打ちする大雑把に共通インターフェースを用意する。考えが全然甘かったとにかくAPIデザインが難しい下手なクラサバ抽象化は結果として使いにくくなる一行書くにつれてもう片方で出来ないことが増えて、泥沼に入り込んでいく感じがある同じ名前のAPIで別物、っていうのが思った以上に気を使うし実装する過程で発狂しそうになるセキュリティサンドボックスを厳密にするために、クライアントとサーバーの細かい部分をどう折り合いをつけるか難しい大雑把なAPI提供してクライアントからやり放題になるの辛いとはいえ、なんか適当に作ったデフォルト実装で実際の使用時に満足するわけない結局ブラウザのcommonjsとサーバー側でrequireできるライブラリが違うので意識しないのは無理あとkoaだとyield必須なんだけどクライアントで動かないのでそこを気をつけたりしないとならなかった(これはライブラリ選択の問題で自分のせいだけど)とにかく考えることが多くて、実際のユースケースを消化した上でよっぽどAPIセンスが良くないと設計できない。Meteorちょっと触った程度の自分はちょっと限界を感じて、諦めた。https://github.com/mizchi-sandbox/ismexample以下がこうやりたい的なAPIなんだけどここまでたどり着ける気がしないので一旦pendingmeteorの苦労がわかりました。S...2017-02-07GraphQLを勉強した自分でGraphQLサーバーを実装しながら勉強したログ。月別アーカイブはてなブログをはじめよう!mizchiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。