【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
そのぶん金取るだけだよな
そんな主張もできない弱小は存在価値ないから他に吸収された方がいい >>670
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、有償で改修するだろう。
の間違いでは？
普通は不具合の修正に有償で対応する方を選ぶでしょ？ app.jsみたいなフレームワーク固有のファイルって
どんな役割なのかもよくわからんし
何を書けばいいのかもわからないしすげえ苦手だ。
最低限何を書けば動くの? フレームワークのドキュメントに書いてあるんじゃないですかね…
書いてないなら使う価値がない(品質が水準に達していない) 触ろうと思ってサンプルプロジェクト作って中途半端に弄ってから半年経ったわ jQueryとかnode.jsとかデファクトスタンダードでみんなやってる感のやつはどうも食指が動かない
変わり者ですみません nodeは一部の変態しかつかってないだろ？
スタンダードとかないわ >>678
それでは変わったことをやっている人が
みんなやってるものをやれば良いのでは？ んなこと言ってるくせに変わったものなんか使ってないんだろどうせ 自分から○○がやりたい！っていうのなら
それは前向きな意見であるが、
みんながやってるからやらない。
誰もやってないからそれをやるっていうのは
それをやりたいという意志がないので
後ろ向きな考え方だよ。やる気が無いといえる みんながやってるからやりたくない、はひねくれ者
気がついたらみんながやってることと違うことをやってた、てのが変わり者 javascriptとかいうデファクトスタンダードの権化を使うのをまずやめるべきだね >>676
async await使ってるならむしろどんどん触るべきじゃないのか。
俺はgoでサーバサイド書いてるからあえて使ってないけど、
全部jsでやるならkoaかも express使ってても自分でミドルウェア書きまくるわけじゃないからな
標準のやらpassportやら使うだけだからasync/await使えて嬉しいことはほぼない
結局エコシステム揃ってる方を使う >>691
koaってexpressのミドルウェア使えたはず。
だからエコシステム的には問題ない。
とは言えasync-awaitもところどころ詰まるところはあるのは分かる
(例えばarrayのmapに渡す関数としては使えないとか。)
でも今から使うならkoaの方かな。 expressのミドルウェア使うならexpressでええやん >>693
非同期処理を同期的にかける魅力には勝てない。 >>692
array.mapに非同期関数渡したいならrxjsで処理してtoPromiseすればおｋ >>697
いや。そもそもPromise.Allがmapと同義じゃんってわかったから
あえてrxjsは使わなくてもok まっ CORE ASP使っている身としては、koa2で十分なんだが、JadeからPugへの変更って必要だったのかえぇ〜？ いまいちのような感じかする。
軽いCMSにkoa2は便利。 重いのもいけそうではあるが・・・ >>699
jadeもpugも一緒だぞ
商標の問題で名前変えただけで あんましexpressもkoaも使ってるぜーって情報発信してる人いない気がする。
知らないうちにブロだクションで動いてるんかな expressってwebアプリケーションフレームワークって感じじゃないからな
rubyでいえばrack相当でrails相当じゃないから表に出ない expressはnode.js標準に付いていてもおかしくない程度の軽いフレームワークだしな ぶっちゃけ、express使うような案件だとphpでよくない？っておもっちゃう >>708
おれもゲームサーバーでnode+socket.io使ってるけど、expressで配信するコンテンツってphpでよくね？ってパターン多い気がする
どうしても非同期じゃないと無理ってパターン以外は非同期のデメリットがでかすぎる
とくにDBがらみの単純な登録画面とかね
phpの数倍の開発コストかかるよ expressでdbアクセスなんてしてないな
bffとして使ってるから
node/expressの後ろのapi鯖はphpだったりrailsだったりjavaだったり でもphpって1requestが1プロセスで高コストだから同時接続数を稼ごうと思ったらnode.jsの方が良いんじゃないの？dbがボトルネックだから気にする必要はない？ それにasync awaitつかえば非同期処理はかなり自然に書けないかな？
学習コストは高くなるかもだけど async/await使いたいけど、LTSになるまで待ってって言われてる(´･ω･`)
TypeScriptはコンパイルしたくないって言われた、、、 最終的にはアクセス増えたときのパフォーマンスの話になるんだろうけどそんなこと気にするレベルじゃない案件でわざわざ苦労してまでexpressでがんばる必要はないなと思う
必要な場面で局所的に使うのがnodeっていうイメージ >>716
むっちゃしんどかった。
goを学習してgorutineで書き直したわ。 express-resourceを使ってAPIサーバーを作りたいって考えているのですが
データベースへのアクセス手順を共通化したくなり、下記のようにしました。
class dbaccess {
constructor(db) {
this.db = db
}
index(req, res, next) {
console.log(this) // undefined
this.db.find({}, (e,r)=>res.json(r))
}
// 以下略
}
app.use('users', new dbaccess(db))
1 APIクライアントからの GET /
-> this が undefined になっていてエラーになる
2 下記のコードからのindex()呼び出し
var dba = new dbaccess(db)
dba.index(null, null)
-> thisの内容が表示される
何か上手い解決策はないでしょうか。 constructor内で
this.index.bind(this)でthisの束縛をすれば解決しませんか？ >>720
お答えいただきありがとうございます。
それを全部のメソッドにやるのも何かしっくりこないので、
下のようにクロージャにしてしまったら何とか期待する動作になりました。
function dbaccess(db) {
let _db = db;
return {
index(req, res) {
}
// 以下略
}
}
クラスだと上手くいかないのがイマイチ納得できてませんけど。 >>722
それが問題ならアロー関数をつかえば解決します。自動でthisを固定するんで。 >>719
おいおい、変なことしないほうが良いぞ
もうちょっと調べるべきだろ？
他のプロジェクトでそんな書き方してるか？
昔やったきりで忘れたし今のやり方は変わってるかもしれないから
適切なアドバイスはできないがよ、他はもっと簡単な書き方してるだろ？ >>724
http://qiita.com/kazusa-qooq/items/23926befcb87c0c7b26f
によると
req,res,nextの3引数を取る関数を作ればいいみたいね。
偶然にもクロージャーを使うというのは正解だけど
nextを省略してるってことは他のミドルウエアを後から追加したら
動かなくなる
こういうの見てるとtypescript使うべきって思う。
型でapp.useに渡すクロージャーを制約できるからこういう失敗がない。 722です
一応、最小限っぽいコードを書いてみました。
http://www.dotup.org/uploda/www.dotup.org1319642.zip.html
users.jsからdbaccessを利用していますが、ここをtags.js, articles.jsと増やしていきたいって考えています。
>>724
本家のサンプルも利用者のblog記事なども一通り見たのですが、
見つかるは全部関数なので、そもそもクラスでの利用を想定していないのだろうと当たりを付けて
影響なさそうなクロージャにしてしまいました
>>725
ミドルウェアの追加は想定していない、クライアントコードなので特に支障はないと判断してます
本音を言うと、ただ書き忘れただけなのですけど。 ちなみに、なんでクラスで書こうと思ったのかと言えば
クロージャとクラスのインスタンスが内部的には等価だと思っていたからです codepenとか使うかgithubに上げるかして欲しいわ。
正直zipでってなんかイャ >>728
将来の自分のためにも流儀は合わせておくべき。
コード量の削減に影響するとも思えない。 >>728
thisが違うことから等価じゃないことが証明されてるでしょ？
じゃあクラスで書こうと思った理由は消滅してるよね？
ならクラスで書くのをやめるべきだよね？ useの第2引数に何が許されてるのかドキュメント読みなさい forkの経緯を眺めてたけどこれio.jsの時と違って結構めんどくさいな
これまでのNodeは人治主義のOSSだったってことか シングルスレッドだから遅くならないって言うけど
マルチスレッド言語で動的にスケールすればいいでしょ？ Node.js Foundationに対し不安を持つグループによるNode.jsのフォークプロジェクト「Ayo.js」誕生
https://mag.osdn.jp/17/08/25/163000 シングルスレッドだから遅くならないなんて言っている人なんているかねぇ？
C10Kの話ならかなりニュアンスが違う。 優秀な一名をこき使うから速いんだな。
ほんの少しでも空時間があったら仕事をぶっこむ。
人間なら死ぬわ。 >>738
メモリ使用量が増えないってnodeのメリットじゃないの？
そんなのスケールアウトで十分だと思うんだが > メモリ使用量が増えないってnodeのメリットじゃないの？
だれがメモリ使用量が増えないというメリットが有ると
いったんだ？ お前の脳内か？ nodeが良かったのはは非同期apiにより
プロセスあたりのリクエスト処理数を高めたからでしょう？
マルチプロセスにすればその分リクエスト処理数もある程度スケールしてくれる。ただしdbアクセスは考慮しないものとする >>743
nodeとは全く別もので、ただのデータベース Nodeが普及したのは良いサイバーサイドJS環境だったから let dict = {}
で辞書のように使おうとしたんだけど、
dict['constructor']ではまった
アレイにkvペア入れて頑張るしか無いの?
16万項目あるので線形検索は躊躇う Mapを使うとかlet dict = Object.create(null)とか >>746
16万項目のデータをメモリ内に置くのか。
もっといい方法無いかな。realmとか使えればいいんだけど。 Object.createで上手くいった
try catchで検出してエラーになるのを、別管理と考えてたけど、すっきりした
さんきゅ >>748
db構築に使うフォーマット変換ツールなので、適切な時間で終了する事が要件で
利用リソース量はあまり気にしない eslintとそれにぶら下がるプラグイン本当互換性がない
ツール入れる所でトラブらないといけないとかだるいわ
これだからJavaScriptなんて書きたくないんだよ eslintのプラグイン何を使おうとしてるの？
使わなければいいじゃない >>742
そういうのもNginxやApacheがある程度やってくれるようになってるからね。
後ろは好きな言語をそのまま使えばいい。PHP-FcgidとかuWSGIとかRackとかServletとか。 >>755
非同期apiはphp処理系では無理じゃない？phpはインスタンスの生存時間がリクエストを受けてからレスポンスを返すまでの固定だよね。
どうやってイベントループ回すの？ >>756
フレームワークによってはイベントループで生存期間が無限のものもあったはず。
前の会社で、そういうWebSocketフレームワーク使おうとしてたよ。
…そんな用途全く想定してない普通のPHP用のオレオレライブラリ組み合わせて
メモリリーク起こしてたけど（藁 >>757
メモリリーク起こすなら使えないな。
phpってインスタンスの生存時間短い前提だから、
メモリリークってさほど気にしなくて良い言語なのかも。
素直にjsでいい気がするけどね。今の時代。
yahooで勤務してる知り合いも今はjsでサーバサイドを書いてるってさ。 もともとCGIはリクエスト毎にプロセス作ってサービスしてた
なので、一つのリクエストが終了するとperlやphpのプロセスも終了するので、オブジェクトを解放(リファレンス外す)しないCGIが多くある
ところが、これじゃおせーよと言うことで、終了させないで無理やりに複数リクエストを処理させる仕組みをでっち上げた
これがPHP-FcgidとかuWSGI
リークしまくりのサービスが出来上がり
三菱とかやりそうだろ だから一定数のリクエストを処理したらプロセス再起動する
三菱でも大丈夫 メモリだけじゃなくて
CPUもファイルI/Oも簡単に食い潰せるからな >>760
なるほどね。大雑把な作りだ。
大昔Dephiの案件をやった時に、PLが
ひとかたまりのEXEを画面ごとにバラバラのEXEにして
切り替えるたびに終了させる仕組みを作り出して、メモリリークを
極力抑える仕様にしてたの思い出した(データはDBにおいてる) >>760
三菱は自動再起動なんて技術がないから、連絡受けて手動で再起動してた 何故、三菱が引き合いに出されるのだ?
なんかやらかしたんかい。 三菱電機インフォメーションシステムズ (MDIS) 製のソフトウェアは、
1時間に400以上リクエストを送られると他のリクエストの処理が不可能になる不具合を含んでいた
これか?
9秒に1回以上で破たんするなんてどんな実装か興味津々 そもそもDOMとのメモリリークとかまともに対応してきたJS界のエンジンが優秀過ぎるだけで
他のサーバサイド言語で環境を跨いた循環参照とか上手く処理できるエンジンは無いし、他のGC技術や調整も何年も遅れてる WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
普通にやったんじゃできないよね。 ■ このスレッドは過去ログ倉庫に格納されています
