Show HN: JavaScript as a Database – Serverless Platform (javascriptdb.com)

20 points by jpcapdevila ↗ HN
Hi HN!

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 ] thread
I think this makes working with data seamless and easy. I know there's a lot to tackle here, but having something like this will be great to simplify and shorten development/reviewing.
Agreed, there are fun technical challenges to tackle. I think the project will eventually take a compiler approach.

At least that's the plan to enable indexes. Parse callback functions passed to .filter and convert that into native DB queries.

Looking at the code noticed that is made as an ES Module but the minimum nodejs version is not present on the package.json I think adding the min node version will be great, some apps like serverless on aws don't support es (by default) so having it will make it easy for compatibility.
Thanks for the feedback. I'll add the supported engines to the package.json

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.

Love the idea and execution. Docs are pretty straightforward. After years of working with shifting paradigms, db & backend trends, the prospect of just writing "await items.find(o => o.a === 2)" to query a db really resonates with me
Thank you. Out of curiosity, what language do you usually use to develop your backend?
Having the same language on both front and backend makes total sense to me and it will bring down the learning curve for engineers to become full stack. Congratulations on this project and great idea!!
Nice!! I needed a tool to build prototypes super fast and I think I just found it.

Congratulations for the release! Excited to see how this project evolves.

I see that https://github.com/javascriptdb/jsdb-server is licensed SSPL instead of something more permissive like MIT. Could you explain the reasoning behind this? How does this affect my ability of self host?
Sure. You can host it yourself for commercial purposes and you don't have to open source anything in your product, just like you can with MIT. The only difference is that if you want to create a service that offers JSDB as a service (compete with javascriptdb.com) you have to open source it. The idea is to make big cloud companies contribute back.
Why should I use this instead of appwrite or firebase?
Both firebase and appwrite are amazing platforms. I use firebase extensively at work, it works great and it scales.

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!!)

Kudos! Sounds like a novel concept for newer trends gravitating back again towards SSR at "The Edge"©

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!

Thanks Ben. I appreciate the feedback, I will add vanilla samples but also samples for each framework, including SSR.

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.