cubic-js / cubic Goto Github PK

From @Kaptard on April 15, 2017 20:43

Implement some sort of cache to reduce input to resource-node for most-used methods.

Copied from original issue: nexus-devs/NexusHub#5

There should be a isConnected function in the cubic-client public API, for example to set the api status without going into the internal components: https://github.com/nexus-devs/NexusHub/blob/development/ui/components/ui/status.vue#L34
Something like this would probably do:

isConnected () {
    return this.client.api.connection.readyState === state.OPEN
}

Just like they're done on NexusHub, except more generalised.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

From @Kaptard on April 24, 2017 7:37

Invalid requests return no information about rejection reason.

To fix: Return Error Object with proper reason. If return value instance of error -> send error back.

Copied from original issue: nexus-devs/NexusHub#9

Manual setup is way too difficult and involves too many steps. See below:

• Generate RSA keypair*
• Load RSA keys at relevant nodes in index.js
• Create Users with root permission (optimally for each node)*
• Add user key/secret at relevant nodes in index.js
• Also: Keys may need to be copied to different servers when running cross-server environments

* could be automated
Index.js modifications could be automated too, but might be a bit too hacky

Possible Solutions:

• CLI tool to automate these things
• (Preferrably) Automate from within the framework.
  -> RSA keypairs are generated automatically if given value is empty (update default config for this)
  -> No index.js editing necessary, we'd just update the blitz.config
  -> Have a service in the blitz.js loader which is activated in production and generates keys for each
  loaded core node type
  -> Again no index.js editing necessary, just modify the keys and pass new config to worker
  initialization in loader

Note: For the second solution, the generated data needs to be written to config anyway, which makes me think we could do this by default, even during development. However this would require to allow any connections on /token calls in development since the default user will be overwritten and databases with the new users might get dropped.

From @Kaptard on April 15, 2017 20:41

Min-diff between requests still working.
Bug occurred after refactoring auth.js into auth & limit.

Copied from original issue: nexus-devs/NexusHub#4

Clustering modules currently broken.

1. child_process.fork(/path/to/server.js) still causes EADDRINUSE errors
2. API-Node requires common place to handle all connected Core-Nodes. Otherwise some api-nodes won't have any core-node to send requests to.
3. There's currently no mechanism to prevent single request being processed by multiple core-nodes, since requests are merely broadcasted in /root nsp. Suggestion: Send "req" to nodes -> First node to answer with "ok" is passed the actual request to.

0.4.0 moves all loader logic into blitz-js-loader and serves as a wrapper for the main modules (api, core, auth, view) instead.

Consider forking and upgrading. Original repo.

From @Kaptard on April 24, 2017 7:39

If method is routed but Method.js has not connected to the mongodb, unhandled promise rejection occurs because this.db inside Method is not defined.

Suggestion: Return 'Not ready' (202 - Accepted)

Copied from original issue: nexus-devs/NexusHub#10

Shows status of active nodes. Which nodes are running? How many nodes are alive? How many connections are present on each node? How much CPU/RAM does each node take? Also add node specific information, eg:

• Requests/s on API node
• Clients on API node
• Availability of core nodes
• etc

Implement as CLI or web-page, although Web-Page seems easier to maintain. MVP would include very basic information and should work as 'status page' for public use as well.

Main modules still require proper JSDoc documentation

title.

Attach logger to global blitz object. Use to determine log levels. E.g. blitz.log.silly("smth").
Adjustable via config.

Having a function that can be used for a 0-config setup, which automatically generates example files unless already present, would likely make the framework much more accessible. It would also create a basis for quick prototyping, which I could've used personally a couple of times already.

Vue 3 is coming out soon with some nice stuff, for example faster SSR and native suspense. Migrate to Vue 3 once it's out of beta and switch from Webpack to Rollup once there's a Vue 3 plugin for it.

So, instead of having a hardcoded timeout of 500ms/1000ms, it should scale by 100ms * 2 every reconnect attempt.

This way we'll ensure that low bandwidth connections can still reach the API.

Need option to use combined middleware on certain routes only.

See this issue here: nexus-devs/NexusHub#346

The current clustering mechanism with multiple spawned child processes is pointless when the same can be done much more easily through docker. It also reduces the code base, improves performance and enhances reliability.

tl;dr, remove clustering, there are no downsides.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

See http://imgur.com/a/lbvVN for reference.
Check is sent, core node should have responded, at least it logs the incoming check, but API considers the node busy. That would mean the timeout set in before the response got back.

Edit: After further investigation, publish and cache transmissions take way longer than their initial request resolve. The more these 'pile up', the more likely that the API gets no response.

Edit2: Check acknowledged returns in a similar bulk. Must be something with Socket.io.

From @Kaptard on April 24, 2017 6:5

Need help looking into these heapdumps for potential memory leaks. To analyze: Open Chrome, go to Profiles in dev tools and load the snapshot.

Copied from original issue: nexus-devs/NexusHub#8

Main framework and all modules require automated testing. Different connection/authorization combinations. Malformed requests on every single route. Etc.

Add logging for new log levels.

From @Nakroma on April 28, 2017 14:31

Add scripts and services that get run on startup or shutdown, sort of like middleware.
Example:

[{ name: "Ensure and create index", script: "/scripts/mongo_index.js", entry: "start" }, ... ]

Makes this issue obsolete / easier to implement: nexus-devs/NexusHub#11

Copied from original issue: nexus-devs/NexusHub#13

e.g.

blitz.get("/register", (req, res, next) => {...})

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Unhandled errors aren't logged by raven yet. Documentation.

Right now, if an error occurs on either the API or Core node, it simply doesn't respond. Instead, we should put a try/catch around it on both the API and Core node, and return the error in plaintext in development, or encrypted in production.

Title. It probably just requires a res.setHeader(...) in the default endpoint.

tested on ubuntu 16.04.

0|index    | /var/www/live/warframe-nexus/node_modules/blitz-js-api/index.js:49
0|index    |         this.server.use(route, fn, "GET")
0|index    |                    ^
0|index    |
0|index    | TypeError: Cannot read property 'use' of undefined
0|index    |     at api.get (/var/www/live/warframe-nexus/node_modules/blitz-js-api/index.js:49:20)
0|index    |     at process.on.msg (/var/www/live/warframe-nexus/node_modules/blitz-js-util/index.js:44:44)
0|index    |     at emitTwo (events.js:106:13)
0|index    |     at process.emit (events.js:194:7)
0|index    |     at process.nextTick (internal/child_process.js:766:12)
0|index    |     at _combinedTickCallback (internal/process/next_tick.js:73:7)
0|index    |     at process._tickCallback (internal/process/next_tick.js:104:9)

Add caching for the API to pull in case of a lot of requests

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

There's no documentation about it, but the initial setup presented in README.md causes errors if you don't have a local Redis instance set up.

Might just need a mention that it is required. (Along with others that I'll list below as I find them)

• Redis
• MongoDB

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Currently, clustered nodes are accessible through the blitz.node[id].workers . Having a blitz.node[id][method] - method would heavily simplify usage.