【非同期】node.js part.1【javascript】

**デフォルトの名無しさん** · 2020/02/29(土) 01:21:17.89

Node.js はスケーラブルなネットワークアプリケーションを構築するために設計された非同期型のイベント駆動の JavaScript 環境です。

**デフォルトの名無しさん** · 2020/02/29(土) 04:35:56.03

Node.jsは最高
PHPとかRailsなんかよりよっぽど優れてるのに人気無い

**デフォルトの名無しさん** · 2020/02/29(土) 16:38:59.09

優れてるけど面倒だよね
でもこれからはNode.jsが主流になると思う

**デフォルトの名無しさん** · 2020/02/29(土) 21:31:49.87

RDBMSとの親和性がまだ合理化されたないから
じゃないかな
ActiveRecord導入したらいい

**デフォルトの名無しさん** · 2020/03/01(日) 00:42:33.97

今ドキのwebサービス作ろうと思ったら、PHP、Python、Railsあたりはもう古い、というか無理があるからな
どれにせよリアルタイム性は必要

**デフォルトの名無しさん** · 2020/03/02(月) 04:44:44.15

正直NodejsとJavaScriptとTypeScriptの違いが全然わからん
Nodejsはjs/tsを動かすエンジンみたいなモンって認識で合ってる？

**デフォルトの名無しさん** · 2020/03/02(月) 05:54:42.20

【node.js】サーバサイドjavascript 5【Nashorn】
https://mevius.5ch.net/test/read.cgi/tech/1518528093/

**デフォルトの名無しさん** · 2020/03/03(火) 01:16:46.98

>>5
どのあたりに無理があるか詳しく教えて欲しいです

**デフォルトの名無しさん** · 2020/03/03(火) 02:03:41.61

>>6
絶対に必要なのが、VSCode, Node.js, yarn。
Node.js, yarn は、Ruby on Rails でも使う

TS は、JS を型付けする、トランスパイラ。
最終的には、JSへ変換して、Node.js で実行される

**デフォルトの名無しさん** · 2020/03/03(火) 02:13:36.25

>>8
別に無理はない。
Ruby on Rails 6 では、Webpacker, 通知機能のNotification もサポートした

サーバー側は、Rubyで、GUI は、HTML, CSS, JS。
サーバー側に、Node.js を使うこともできるけど、Rubyの方が可読性が高いし、バグらない。
まあ、Node.js は、Rubyのコピーだから、だいたい同じだけど

Ruby + React, Vue.js とか、jQuery, Bootstrap とか

10 · 2020/03/03(火) 02:28:51.71

#205 Push Notifications with ActionCable
https://www.driftingruby.com/episodes/push-notifications-with-actioncable

Ruby on Rails のActionCable で、
JavaScript のPush Notifications を実装する動画

**デフォルトの名無しさん** · 2020/03/03(火) 03:49:50.53

>>10
5でruby pythonあたりでwebサービス作るのは古いと言っているのに、railsを押してくるのは何故ですか？
初学者なので教えて頂けると嬉しいです

**デフォルトの名無しさん** · 2020/03/05(木) 14:41:44.14

熱く語っていた大先生方が消えてしまって悲しい

**デフォルトの名無しさん** · 2020/03/08(日) 20:19:56.01

レｗｗレイルズｗｗｗｗ

**デフォルトの名無しさん** · 2020/03/09(月) 01:44:20.76

>>14
railsのこと馬鹿にしてるみたいだけど、railsのどこがダメなのか教えてほしい

**デフォルトの名無しさん** · 2020/03/09(月) 03:06:42.31

レｗｗレイノルズｗｗｗｗ

**デフォルトの名無しさん** · 2020/03/12(木) 00:21:36.55

とにかくめんどくせえわ

**デフォルトの名無しさん** · 2020/03/14(土) 15:56:43.66

>>15
webアプリなんかだと、リアルタイム性を重視したり大量のアクセスを捌くならnodejsだよ

**デフォルトの名無しさん** · 2020/03/14(土) 16:37:00.94

>>4
スケールの観点から流行らんだろ。
何か新しいやり方で出るまでは変に入れん方がいい。

**デフォルトの名無しさん** · 2020/03/23(月) 20:24:04.69

>>15
SSR が面倒臭い
モダンなWeb開発するには力不足

**デフォルトの名無しさん** · 2020/03/23(月) 21:41:38.05

>>20
railsにはapiモードがあるけど、それじゃダメなの？

**デフォルトの名無しさん** · 2020/03/27(金) 23:08:28.41

app層がどんなアーキテクチャだろうと
前段にロードバランサやNGINX噛ませれば
並列化でイベント駆動になるやん
node使って鯖側のコードまでコールバック地獄に陥る必要は
ないわ
そう考えるとappサーバはrailsの方がええやろ

**デフォルトの名無しさん** · 2020/03/27(金) 23:39:03.67

railsのいいところ
・モノリシック
・ruby

railsの悪いところ
・モノリシック
・ruby

node (next/nuxt) を使うのはフロントエンドのいわゆるbffなんでdbアクセスはしない
nodeはdbにアクセスするバックエンドのapiを叩くだけ
だからバックエンドにrailsでもいいんだけどapiサーバならgoでもいいよね、goの方がいいよねってのが最近の流れかな
モノリシックならrailsが強かったけどマイクロサービス(を意識)するならフロントエンドで強いnode+バックエンドで強いgoが増えてる感じ
typescriptが当たり前になってきてるように静的型チェックが好まれてきてるってのもあってruby/rails推す人は減ってる
うちのバッグエンドは相変わらずjavaだけどな

**デフォルトの名無しさん** · 2020/03/28(土) 02:32:46.37

>>23
なるほど！！わかりやすい説明ありがとう

**デフォルトの名無しさん** · 2020/03/28(土) 14:25:46.82

サーバー側を、JavaScript, Node.js で作るのは苦痛。
Ruby で良い

どの道、主戦場は、Docker/Kubernetes だし

**デフォルトの名無しさん** · 2020/03/28(土) 15:04:34.69

こういう話をしてるんだけどね
https://image.itmedia.co.jp/ait/articles/1803/12/news012_06.jpg

nodeで作るのはサーバといってもbackend for frontendsのところな
ここは大部分がreactやvueをゴリゴリ使うところだからrails使っても結局jsやで
だったらnodeの方がずっといい
next/nuxtがある今は尚更
db触るapiサーバはrailsでもいいけど人気はgoでjavaでもいい(ここでnodeは使わない)

まずはこの記事でも読んでくれ
https://www.atmarkit.co.jp/ait/spv/1803/12/news012.html

その上でrailsを推すならbff作るにもnodeよりrailsが向いてると言いたいのかbff不要でモノリシック最高と言いたいのか明確にしてくれ

**デフォルトの名無しさん** · 2020/03/28(土) 15:52:46.92

BFFって目的が違うだけで使う技術はただのバックエンドと変わらんと思うが？
BFFがSSRにReact使うというなら、ただのバックエンドだってSSRするわけだし。

**デフォルトの名無しさん** · 2020/03/28(土) 16:22:33.70

旧来のモノリシックなバックエンドでssrする場合はサーバサイド専用のテンプレート言語を使ってた
古のerbやjsp、その最たるものはphpだな
最近のssrはspaとして動くjsのコードをサーバでもそのまま使うところが違う
だから必然的にjsの実行環境がサーバサイドでも必要になる
それもあってnodeでbffを構築するのが有力な選択肢になってるわけ
railsでもreact/vueをssrできるといっても結局はhypernovaでnodeプロセスを立てるわけじゃん(hypernovaは古いのかな？知らんけど何使っても中はnodeでしょ)
だったら素直にnode使ったほうがいいよね
どうせフロントエンドの大部分はjsなんだしフロントエンドエンジニアはみんなjs書いてるんだから極々一部のために複雑な構成にしたくないしruby書きたくもない

**デフォルトの名無しさん** · 2020/03/28(土) 16:27:26.03

「SSRやるならnodeが良い。」って話にBFF関係なやん、ってだけ。
べつにnodeバックエンドは否定しないよ？

**デフォルトの名無しさん** · 2020/03/28(土) 16:43:39.28

いやいや、nodeはdbを捏ねるにはライブラリも実績も乏しいからbffでないバックエンドには向かないぞ
bffっていう立ち位置ができるまでnodeはサーバサイドjsではなくフロントエンドのコマンドラインツール(grant/gulpってあったな)止まりだったことを忘れたか？

**デフォルトの名無しさん** · 2020/03/28(土) 17:10:15.44

は？いつの時代の話をしている？
うちのnodeバックエンドはmongoやpostgresも普通に使ってるけど？

**デフォルトの名無しさん** · 2020/03/28(土) 17:26:36.88

いつの時代でも広くは使われてないだろ
お前んとこの事例がレアケースなだけで
だから「ただのバックエンド」に普通nodeは入らない

**デフォルトの名無しさん** · 2020/03/28(土) 17:37:38.75

まさか、ただのnodeバックエンドよりSSR使ったBFFの方が多いとでも？
本当にそんな統計があったとしたら興味深いが。

**デフォルトの名無しさん** · 2020/03/28(土) 18:07:38.88

ssrはともかくdbアクセスするバックエンドよりもしないbffの方が事例として紹介された数は断然多いと思うぞ
instagram, twitter, netflix, yahoo(us)辺りはssrもしてるbffの有名どころ、facebookはssrなしbff、airbnbがssrするbffの先駆者(もうやめてるが)、paypal, walmart, ebay, grouponとかはbffって用語が普及する前(もちろんssr以前)からその用途で使ってた
国内だとca, pixiv, recruit辺りがssrするbffの事例出してたかな
nodeをbffじゃないバックエンドって国内で有名な事例はcaくらいじゃね

**デフォルトの名無しさん** · 2020/03/28(土) 18:44:55.87

>ssrはともかくdbアクセスするバックエンドよりもしないbffの方が事例として紹介された数は断然多いと思うぞ

別に珍しくもないからわざわざ紹介されんだけでは？

**デフォルトの名無しさん** · 2020/03/28(土) 18:58:26.38

少なくともnodeが出て数年(10年代前半)は本番で使ってるというだけで珍しかったはずだけどもういいよ
君とは違う世界線に住んでると思ってくれ

**デフォルトの名無しさん** · 2020/03/29(日) 14:33:20.38

>>27
railsはssrしているが、bffではない。
bffはbackends for frontendsだから、reactやvueなどモダンなフロントエンドのために存在するものだから

**デフォルトの名無しさん** · 2020/03/29(日) 15:58:34.26

>>37
それは目的の話で>>27も目的は違うと書いてるわけでな

**デフォルトの名無しさん** · 2020/03/29(日) 18:00:10.33

>>38
目的と技術は両方とも一緒でしょ

サーバーがフロントエンドのために存在しているものが、その名の通りbffでしょ

**デフォルトの名無しさん** · 2020/03/29(日) 18:34:46.34

>>39
BFFは特定のクライアントのためのAPI Gatewayを用意するアーキテクチャパターン
該当する役割を担ってるサーバー/レイヤー/コンポーネントを便宜上BFFと呼んでるだけ

BFFは目的の話でそれを実現する技術スタックとして何を使うかとは別の話

**デフォルトの名無しさん** · 2020/03/29(日) 18:44:15.05

>>40
bffの目的というのはssrや特定のクライアントに対してのapi endpointの定義とかだよね？

あと、サーバー、レイヤー、コンポーネントのそれぞれの違いを教えてほしい

**デフォルトの名無しさん** · 2020/03/29(日) 18:51:50.89

それくらいググれよ……

**デフォルトの名無しさん** · 2020/03/29(日) 18:54:02.46

>>39
だとするとツッコミどころがおかしいぞ。
>>27は(目的が違うだけで)使う技術は同じだからbffとただのバックエンドを区別して考える
必要はないと言っているわけで。

**デフォルトの名無しさん** · 2020/03/29(日) 19:06:04.34

27はその後のレス読むと(railsではなく)nodeバックエンドの話をしてるからややこしい
37はrailsの話してるから全然噛み合ってない気がする

node bffとnodeバックエンド：目的は違うが技術は同じ
node bffとrailsバックエンド：目的も技術も違う

**デフォルトの名無しさん** · 2020/03/29(日) 19:18:11.09

サーバサイドにnode.jsをまだ使ったことないけれど、エコシステム整ってくれば既存のバックエンド言語を置き換えるくらいのポテンシャルある感じなんだ？

**デフォルトの名無しさん** · 2020/03/29(日) 19:20:02.24

>>43
ここではっきりして欲しいのは目的が何を指しているのか。

みんなそれぞれが口に出している目的が違う気がする

**デフォルトの名無しさん** · 2020/03/29(日) 19:27:04.31

(ダメだこいつ・・・)

**デフォルトの名無しさん** · 2020/03/29(日) 19:30:17.50

目的に違いがあるのかもしれないがそこに意味はない→「目的」を掘り下げる意味もない
ってことなんだが。

**デフォルトの名無しさん** · 2020/03/29(日) 20:23:03.93

>>45
いいえ

**デフォルトの名無しさん** · 2020/04/04(土) 01:57:12.17

>>49
バックエンドをnodeで開発してるけど全然辛くないよ。
何が問題だと考えてるの？

**デフォルトの名無しさん** · 2020/04/04(土) 02:48:49.28

>>50
辛くない程度じゃ既存の言語を置き換える理由になるわけないだろ
逆にどれほどのアドバンテージがあるのか>>45に教えてあげれば？