As you can clearly see from the other posts on my page, I’ve made a lot of things in the last few years. And I’m proud of having accomplished all those things… but particularly, of making Enmap.

The idea behind Enmap was fairly simple: add persistent storage to a Map object, and add methods to it that were useful, pulled from Array methods. The idea for the additional methods came straight from Discord.js’ “Collections” structures, but the persistence was something new. So back in June last year, I released a first version of djs-collection-persistent, in an effort to bring those two awesome features, together, for anyone using node. After a few months I have to admit, typing in djs-collection-persistent just got really annoying so I started thinking about a new name… for Enhanced Maps. So naturally, this became Enmap because why not! But why did I even make Enmap? What was the thought behind it? I pay attention to the recurring questions and problems that appear on programming servers I’m part of on Discord and one thing that popped up often was how to store various key/value pairs. User points, Guild settings, Tags, etc. Because most of the users that were asking these questions had very little experience with JavaScript and had never even touched SQL - asking them to install and use a database module and make their own queries was a pretty big ask. On the other hand, with my experience making Guidebot, then Komada, then Guidebot again, and a few bots inbetween, I’d gathered some basic idea of the structure needed to store, retrieve, and cache data in a meaningful, simple way. I knew that for the best performance, I could retrieve all the data on bootup and only modify it when it changed, reducing the database overhead while retaining the beauty of the Collections I was basing myself on. I wanted people to simply load up a database by name then use common, simple methods to interact with it without worrying about what was happening with the database behind. At the same time, I realized that in some circumstances, the persistent database I was using at the time (leveldb, which is a very performant key/value pair storage) wasn’t appropriate for all situations: indeed, it did not support being opened from multiple processes so anything using sharding or child processes couldn’t use it. I went to work separating the actual Enmap layer (the cache itself) from the storage layer (which I call providers) so I could easily produce multiple providers that people could use to connect to existing database back-ends. And now we’re at the point where Enmap is fairly stable, solid, and has 5 different providers: LevelDB, SQLite, RethinkDB, PostgreSQL and MongoDB, with more on the way. Most of these (except of course LevelDB) support sharding and child processes, and they’ve been tested for stability and performance. And I’m proud. Very proud. For the first time I feel like I’ve accomplished something useful above “some bot stuff”, something that I myself have and will continue to use in different projects. To the contrary of Guidebot and Komada, I have no intention of giving this away for someone else to keep maintaining. It’ll be around for a while, lemme tell you!