DEV Community

Cover image for Check Out My First Node.js Package: Json Flex DB!

Check Out My First Node.js Package: Json Flex DB!

Rizmy Abdulla 🎖️ on March 29, 2024

Hello folks, I'm thrilled to share something really exciting with you all – my very first open-source Node.js package, Json Flex DB! It's a fantas...
Collapse
 
miketalbot profile image
Mike Talbot ⭐

Firstly congratulations on publishing a package! I think it would be worth documenting that this is an in-memory database.

Thinking about the actual database code:

  • I'd seriously think about debouncing the save method - it's going to kill performance stringifying and writing files all the time, especially in high data processing environments when there are a lot of changes.
  • I don't see how the indexes are being used. I see you writing to them, but never using the values written - only checking if an index is present.
  • Your method of generating a random key is going to lead to clashes, Math.random() isn't very random. Personally, I use nanoid to do this, but even a function based on Date.now() would be more likely to be unique over any significant number of records.
Collapse
 
yashlalpotu11 profile image
YASH LALPOTU

Agree with your points, thanks for sharing.

Collapse
 
lnahrf profile image
Lev N. • Edited

Congratulations on your first npm package 🙂
Npm packages are a great way to learn how to develop tools.

The concept is also great for a first package, wrapping your head around the basics of how a database works is knowledge that will give you edge over other developers.

A suggestion for improvement: the native json stringify and parse methods are very limited and do not scale. If you will try to parse or stringify a json file that is larger than 500 megabytes in size, it will fail. I suggest finding a scalable solution or implementing your own.

Collapse
 
rizmyabdulla profile image
Rizmy Abdulla 🎖️

Thank you for your suggestion, Lev. I'll look into it soon.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas • Edited

Hello, my 2 cents would be to move away from CommonJS and re-write it to be ES modules. This is particularly important when working with async/await syntax, as CommonJS only allows this in functions. ES modules allow it everywhere. Every modern package should just move to ESM and never CJS.

Also, since you're entering this area, you might be intersted in this article:

Collapse
 
rizmyabdulla profile image
Rizmy Abdulla 🎖️

Yeah, that sounds like a good plan! I'm all for rewriting it as an ES Module. Thanks for bringing it up. I wasn't even aware of the differences between CJS and ESM before.😅

Collapse
 
sehgalspandan profile image
Spandan Sehgal

Hi @rizmyabdulla ,
Congratulations for your Achievements, but it would be better if explain what it does and how it does in your post too!

Overall, gg, keep up the good work!

Collapse
 
rizmyabdulla profile image
Rizmy Abdulla 🎖️

Thanks 💫 I edited the Post !

Collapse
 
sehgalspandan profile image
Spandan Sehgal

👀 nice work @rizmyabdulla, quick response, really appreciate itA

Collapse
 
ronakjain2012 profile image
Ronak Bokaria

Congratulations and as a lightweight package it's really great and ppl already mentioned the improvement opportunities but overall it's Good

I have used it for POC and worked awesome.

Collapse
 
rizmyabdulla profile image
Rizmy Abdulla 🎖️

Thank you for using my package😊. I'm still working on implementing the awesome improvements that ppl have mentioned.🚀

Don't forget to star my GitHub repository!😅

Some comments have been hidden by the post's author - find out more