Skip to main content
Code Review

Return to Question

deleted 59 characters in body; edited tags; edited title
Source Link
Jamal
  • 35.2k
  • 13
  • 134
  • 238

Web socket server which needs to query some Passing API and to passdata chunk per chunk of data to its socket clients every M seconds

config.jsconfig.js

Just some boilerplate instruction for node-random package, where iI want to fetch 10 decimals number betwenbetween [0, 40]. That is all. I used just exports here instead of module.exports because in the future iI expect to change this file to support all application configs, like:

exports.mongodb_conn_url = "...";

so exports.mongodb_conn_url = "...";fetch_options so fetch_options and config about database should be logically divided.

Main logic (server.jsserver.js)

For bounty to be collected i would appreciate following:
I would appreciate the following:

  1. I'm aiming for code correctness, best practices and design pattern usage usage, especially for the part related to emitting events in node. I see see massively that developers inherit from EventEmitterEventEmitter before use anyusing any emitting. I don't see here any advantage of using that practice.
  2. Will it be better to implement ReadableStreamReadableStream here? I don't know to much much about streams, but it seems here, in some way, i'm creating something something that looks a like stream. So instead of mixing that logic with with the server - how to implement a subclass of ReadableSteamReadableSteam and then then just to require it.

Web socket server which needs to query some API and to pass chunk per chunk of data to its socket clients every M seconds

config.js

Just some boilerplate instruction for node-random package, where i want to fetch 10 decimals number betwen [0, 40]. That is all. I used just exports here instead of module.exports because in the future i expect to change this file to support all application configs, like:
exports.mongodb_conn_url = "..."; so fetch_options and config about database should be logically divided.

Main logic (server.js)

For bounty to be collected i would appreciate following:

  1. I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.
  2. Will it be better to implement ReadableStream here? I don't know to much about streams, but it seems here, in some way, i'm creating something that looks a like stream. So instead of mixing that logic with the server - how to implement a subclass of ReadableSteam and then just to require it.

Passing API data chunk per chunk to its socket clients every M seconds

config.js

Just some boilerplate instruction for node-random package, where I want to fetch 10 decimals number between [0, 40]. That is all. I used just exports here instead of module.exports because in the future I expect to change this file to support all application configs, like:

exports.mongodb_conn_url = "...";

so fetch_options and config about database should be logically divided.

Main logic (server.js)

I would appreciate the following:

  1. I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before using any emitting. I don't see any advantage of using that practice.
  2. Will it be better to implement ReadableStream here? I don't know to much about streams, but it seems here, in some way, i'm creating something that looks a like stream. So instead of mixing that logic with the server - how to implement a subclass of ReadableSteam and then just to require it.
Notice removed Draw attention by Community Bot
Bounty Ended with no winning answer by Community Bot
Tweeted twitter.com/#!/StackCodeReview/status/546831396141293569
Notice added Draw attention by Srle
Bounty Started worth 100 reputation by Srle
added 409 characters in body
Source Link
Srle
  • 105
  • 2
  • 2
  • 9

I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.For bounty to be collected i would appreciate following:

  1. I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.
  2. Will it be better to implement ReadableStream here? I don't know to much about streams, but it seems here, in some way, i'm creating something that looks a like stream. So instead of mixing that logic with the server - how to implement a subclass of ReadableSteam and then just to require it.

I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.

For bounty to be collected i would appreciate following:

  1. I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.
  2. Will it be better to implement ReadableStream here? I don't know to much about streams, but it seems here, in some way, i'm creating something that looks a like stream. So instead of mixing that logic with the server - how to implement a subclass of ReadableSteam and then just to require it.
deleted 25 characters in body; edited title
Source Link
Jamal
  • 35.2k
  • 13
  • 134
  • 238

Node.js, web Web socket server which needs to query some API and to pass chunk per chunk of data to its socket clients every M seconds

Let's say that iI want to query some API which will respond with array of random numbers
[4, ..., 17, ..., 25].:

[4, ..., 17, ..., 25]

To keep things simple enough, let's say that array has always 10 elements.
ForFor every element in that array i, I need to emit via socket to all clients just ONE number every M seconds till end of array. When end of array is reached fetch again.When the end of the array is reached, fetch again.

The API that iI want data from is found http://www.random.org/here (it's about true random numbers generator) and iI choose some abstraction for fetching data(node package: node-random available at https://github.com/dlom/node-randomhere).

Sadly iI can't find an abstraction(package) which support JSON API from the random.org, all. All of them just supportsupports something that random.org callcalls "Old API for automated clients" (which only support htmlHTML and text/plaintext/plain responses), there is actually a new version of the API called "API for automated clients" which supports JSON response. So it would be faster or nothing at all to parse raw JSON instead text/plain response.So it would be faster or nothing at all to parse raw JSON instead text/plain response.

Actual code:
config.js

mainMain logic (server.js)

Now another server which acts as a client of this socket server can connect to this like:

Sorry for long post. I'm aiming here for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inheritsinherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.

Node.js, web socket server which needs to query some API and to pass chunk per chunk of data to its socket clients every M seconds

Let's say that i want to query some API which will respond with array of random numbers
[4, ..., 17, ..., 25]. To keep things simple enough let's say that array has always 10 elements.
For every element in that array i need to emit via socket to all clients just ONE number every M seconds till end of array. When end of array is reached fetch again.

API that i want data from is http://www.random.org/ (it's about true random numbers generator) and i choose some abstraction for fetching data(node package: node-random available at https://github.com/dlom/node-random)

Sadly i can't find abstraction(package) which support JSON API from the random.org, all of them just support something that random.org call "Old API for automated clients" (which only support html and text/plain responses), there is actually new version of the API called "API for automated clients" which supports JSON response. So it would be faster or nothing at all to parse raw JSON instead text/plain response.

Actual code:
config.js

main logic (server.js)

Now another server which acts as client of this socket server can connect to this like:

Sorry for long post. I'm aiming here for code correctness, best practices and design pattern usage especially for the part related to emitting events in node. I see massively that developers inherits from EventEmitter before use any emitting. I don't see here any advantage of using that practice.

Web socket server which needs to query some API and to pass chunk per chunk of data to its socket clients every M seconds

Let's say that I want to query some API which will respond with array of random numbers:

[4, ..., 17, ..., 25]

To keep things simple enough, let's say that array has always 10 elements. For every element in that array, I need to emit via socket to all clients just ONE number every M seconds till end of array. When the end of the array is reached, fetch again.

The API that I want data from is found here (it's about true random numbers generator) and I choose some abstraction for fetching data(node package: node-random available here).

Sadly I can't find an abstraction(package) which support JSON API from the random.org. All of them just supports something that random.org calls "Old API for automated clients" (which only support HTML and text/plain responses), there is actually a new version of the API called "API for automated clients" which supports JSON response. So it would be faster or nothing at all to parse raw JSON instead text/plain response.

config.js

Main logic (server.js)

Now another server which acts as a client of this socket server can connect to this:

I'm aiming for code correctness, best practices and design pattern usage, especially for the part related to emitting events in node. I see massively that developers inherit from EventEmitter before use any emitting. I don't see here any advantage of using that practice.

Source Link
Srle
  • 105
  • 2
  • 2
  • 9
Loading
default

AltStyle によって変換されたページ (->オリジナル) /