Show HN: JavaScript as a Database – Serverless Platform (javascriptdb.com)
I’d like to share with you my project: JSDB.
Two months ago I had this thought while reviewing a PR on a web application. What if I didn’t have to write code to communicate with my backend or database?
It would be fun to just use arrays and objects like you normally do in javascript and have things magically save.
That weekend I hacked together something that used proxies and classes to ‘magically’ send data to your backend when you assign or access properties in an object or array. Using the same API you already know.
This means you can save data like this: items[x] = {a:2,b:false} and read data like this: console.log(await items[x].a) or console.log(await items.find(o => o.a === 2))
While sharing it with some devs I started to get comments like this? “Wow that’s super simple. Is it secure?”
So I started building a platform around this idea. A platform that allows javascript developers to write full stack applications, with the least overhead possible and just writing javascript.
Security Rules are JS functions, files are simply assigned to an object property, triggers are JS functions etc. Everything is javascript! Check the docs: https://javascriptdb.com/docs
Why?
Because there are developers that can write code using arrays and objects but are not confident with backend code.
I would like to lower that barrier and empower every developer that knows JS to be full stack with the least effort possible.
For experienced developers, less boilerplate means less bugs and faster product cycles. I like to think that JSDB is positively influenced by this post from Rich Harris: https://svelte.dev/blog/write-less-code
Aren’t there other platforms that solve this problem?
Yes, there’s some great efforts. Supabase recently had a killer launch week and I have tons of respect for what they’ve accomplished.
JSDB targets the javascript lovers, the devs that rather just write javascript and would like to avoid sql if possible. By design it will only work on javascript codebases.
Is this production ready?
No! It’s still an MVP, designed to show the idea and where I’m going. That's also why there are limited spots for the hosted preview alpha (you can always self host).
If this sounds interesting check this demo: https://youtu.be/xs30II7HNBQ
Docs: https://javascriptdb.com/docs
Website: https://javascriptdb.com
Github: https://github.com/javascriptdb
Looking forward to getting candid feedback :)
14 comments
[ 3.2 ms ] story [ 40.1 ms ] threadAt least that's the plan to enable indexes. Parse callback functions passed to .filter and convert that into native DB queries.
About ES modules, I decided to start with esm because it looks like everything is moving in that direction. That being said I will support both cjs and esm soon.
Congratulations for the release! Excited to see how this project evolves.
The main problem with firebase is that you can't self host it, this means you can't easily test or replicate environments.
The emulators are limited: indexes are not enforced, copying the production database (no more than 50k documents) to my macbook pro crashes the emulator.
Also the DSL used to define security rules is not flexible enough. I've seen developers skip defining rules because they don't get it to work.
Appwrite is great and you can self host it, but it introduces concepts/APIs to query data and secure it that you have to learn. They also try to solve the problem for all platforms and languages.
JSDB tries to extremely simplify things and just use plain javascript for everything.
You should use JSDB if you love javascript.
That being said, firebase & appwrite are both production ready and JSDB is not there (yet!!)
I remember using typicode/lowdb in a past life and wondering why it had to have an ad-hoc ORM-like API when good ol' data structures would do just fine?
Nothing against Svelte (actually the opposite), but maybe showcasing a simplified code snippet in the landing page and make it more framework-agnostic might draw more brains
On the other hand, there might be a chance to showcase specific examples of more trending SSR frameworks such as Remix and Next.js. As far as I can tell direct DB access might make more sense on the server-side (LoaderFunction & getServerSideProps respectively)
Great craft!
The DB access works fine on both places, I use it from svelte kit load function without problems. I haven't played with authenticated SSR, I'll make sure to include that in the samples.