sateffen / nodgine Goto Github PK

Maybe there should be an $UTIL object within the nodgine, helping with some alltime known polyfills. Maybe even have methods to extend the original prototypes with some new methods.
A good example of such useful functions is underscorejs

The $ROUTERtests have to be refactored, to fit coding style.

There should be a configurable minimum log-level for the logger, so the user could say "log just warnings and errors" in production to have a cleaner logfile.

A lot of IDEs have support for JSDoc, so it would be nice, if this could be used. So if the documentation on the wiki is good enough, I should think about switching from YUIDoc to JSDoc to use this helpful support.

The current test system is pretty simple, but they are hard to read.
The testsystem gets changed to a BDD style test system, with a new written spec.
Additionally, it's generating a coverage report.

The old tests will be still there, till the new spec is done.

List, what needs to be done:

• application
• bootstrap
• logger
• router
• service

The $SERVICE tests have to be refactored, to fit coding style.

The documentation should be overhauled, because it's telling pretty much nothing.

The main concept of this library is based around promises, that should get pointed out. That way it's simpler to compare to other solutions like koa or express.

The readme is currently pretty messy and not nice. People seeing it will go like "wtf? No". For the next version, the readme should be rewritten.

Usually a real cool application doesn't only use HTTP, it's using Websockets as well. Maybe there is a possibility to ingetrage websockets into the nodgine, so the webserver and websockets can listen at the same port, so there is no need for CORS cause of different ports.
I guess there has to be some research done, whether it's possible with some other frameworks or whether there is a need for native support.

For development there should be a new log-level called debug. This is under log and is for development only.

The load-path stuff was a bad idea, that has no future. A real node application will handle this by far better.

Remove it.

Currently the services are registered after the routes and processors, when configuring the project by json.
This should be the other way around to prevent errors, when a routecontroller wants to query for an service.

The logger can not be configured by the (undocumented) JSON-configuration.

The $LOGGER tests have to be refactored, to fit coding style.

Imagine, a service has a lot of routes, 50, maybe 100, and the most requested ones are the last ones. That would be a lot of overhead, every request again.
Maybe there should be a way to count each request, and sort the list of routes and controllers, so the most requested is at the top, the least requested at the bottom. Then some load in peaks could be minimized. Not a lot, but it could save some CPU by allocating only a very little more memory.

The exceptions aren't useful for debugging, but they should. So every exception should be reworked to a meaningful expression

The documentation is automatically generated, but is not pretty good. Maybe some handwritten documentation would help. Some examples would be fine, too.

If the basepath in the server.json is relative, the software assumes, that it's relative to the nodgine, not to server.json.

There should be an API for setting up filters for input and output on requests.
Maybe filters for compressing output, or filtering input for malicious content.

In the class-definitions are a lot of "Object.definePropertys" calls. This calls can be replaced by Object.defineProperties to optimize readability and performance.

Sometimes you don't want to provide options for an https server, so the aOptions argument of $APPLICATION.startHTTPS should be optional.

The nodgine should be usable from the commandline to start a json file, just like:

nodgine server.json

The "setEncoding" "getEncoding" and postString are all deprecated. They will get removed.

In the arguments, passed thru to the controllers, the * should be contained. The star is maybe covering important information, that should be parsed afterwards.

There should be an option to configure an interface in the JSON. Currently it's only possible to set a port.

Maybe there should be an possibility configure the whole process via a json file. Currently the main javascript file is simply a file, that calls hundred times addRoute, hundred times registerService, finally startHTTP and then run. This gets pretty unreadable. A json file would be better.

Currently, the complete request body is written to a buffer. That allows an attacker to set a request body with more than 1gb, which exhausts the complete memory, and crashes the server.

There should be a configurable limit, which protects the process from to huge request bodys.

A limit should be set to 4mb, 8mb or 10mb.

Currently a service gets it's own unique id by the system. This doesn't look like the first idea of the services interface. The first idea was to have a simple interface like handling DOM-elements: By type (class) and id. There should be a possibility to set an own id at the registration of a service, so this id could be used in the whole application, instead of using the type to identify a single service.

The extensions like for the preprocessors, postprocessors, or even static-file route-controllers should be moved to another repository and module.

After this they can be loaded separately and you can develop them independently, without releasing nodgine versions where nothing changes.

Currently the post-data can be accessed by request.post . This is a string, but a string is not useful in every situation. There should be the possibility to access the original buffer as well.
With the buffer-access the performance of some actions will increase as well.

All methods of the main objects, should be writeable. It's not the "javascript-style" to refuse rewriting them.

The default nodejs API allowes to setup an "hostname". This hostname should be usable with the nodgine as well.

The API for the $SERVICE was changed, this has to be written in the wiki, when version 0.4 is released.

There should be an option to define routes, where the pre- and postprocessors should be triggered, so not all processors are triggered every call.

The $APPLICATION tests have to be refactored, to fit coding style.

See title

See title, it's important.

Currently an url pattern like /test/* needs to get at least /test/ in the path, /test is not enougth. This should be changed, so the last slash is optional.

Firefox sends a content-type like "application/JSON; encoding=utf8". This isn't recognized, but it should.

The components should not be written in uppercase, linke $LOGGER, oder $APPLICATION. This should get corrected to $Logger, $Application, $Router and so on.

There should be an option for named logger, just like in java

See title

The project should be restructured to something more convenient like
/src
/dist
/test
and remove the docs, because it's in the wiki

In $ROUTER.setEncoding the encoding isn't checked, whether it exists or not. This should be checked and the TODO removed.

It's a common use case, to serve a folder as static file directory. So if the user calls myurl.com/app/test.js the file test.js belonging to configured directory should be served.
Currently you have to write this by yourself, every time again, this is not cool. There should be a default route-controller that could be used for this, if wanted.

The user should be able to log more than just strings. There should be an option to log objects and so on as well.

The faq documenation contains a wrong object as params for the request and response classes.

With the current nodgine the response.writeContiunue is not possible. This should be possible to use, cause some applications may rely on this.