Hello, first post here.
I would like to express my concerns for the direction of the Node client.
I have worked on a large number of node libraries and I believe that public modules should be made using the highest standards and implement the best practices of the industry.
This is a small list of changes that can greatly increase the trust level of Node developers towards Aerospike.
-
Move logic that is not performance-critical to Javascript.
I understand that it is an easy way to make a port to simply include the C++ code to save time and effort. Yet, as a Javascript developer, I want to know what the libraries that I require do. In a very explicit manner. This is a lot to ask, but I see direct positive impacts on devs. Faster builds (less classes to compile), more visibility in the JS code.
-
Give the JS part some love.
You can see a clear difference in the quality of the C++ portion versus the Node part. This makes me think that Javascript is regarded as a second class citizen by Aerospike. Almost no comments, no structure, linter errors. (I opened a merge request for the linting part : ran linter on js libs, added debug module by fed135 · Pull Request #81 · aerospike/aerospike-client-nodejs · GitHub). There are great style guides available, such as this one: GitHub - airbnb/javascript: JavaScript Style Guide
-
Follow the industry guidelines.
Avoid printing directly in the console. This applies to any library. You don’t want your console polluted by logs you didn’t ask for while running your app. There are GREAT tools available on NPM to solve just that. (I opened an issue : Feature request: stop printing directly to stdout · Issue #82 · aerospike/aerospike-client-nodejs · GitHub)
-
Don’t bundle benchmarks, docs and examples.
Benchmarks and examples should be put in a different project, and documentation too. We don’t need those when requiring the library, say in production. It’s about 350kb of stuff we have to download. Check how Waterline does it : GitHub - balderdashy/waterline-docs: WARNING: The content in this repo is out of date! See https://github.com/balderdashy/sails-docs for the most up-to-date documentation
-
More verbosity!
I would be very interesting to see incoming and outgoing requests info in the console. Check out how request - npm used the debug module (debug - npm)
-
More feedback from collaborators
It would be my pleasure to work on some of those requests. Yet, I get no replies or acknowledgement to my issues or merge requests. A big part of choosing a technology to work with is the amount of support, the solving rate for issues and finally : community involvement. There are currently a lot of unattended issues and merge requests. You will lose the interest/respect of the community and fall behind if you don’t follow up on community requests. It would also be very interesting to have visibility on the roadmap and currently assigned tasks/bugs.
