Show HN: Firestorm – An ORM for Firestore | Hacker News Reader

Show HN: Firestorm – An ORM for Firestore

github.com

59 pointslmcq21 comments

In the last few months I'm observing TypeScript being pulled into the a direction that Java developers know very well: Complexity.

All that was missing was an ORM. Annotation-based, no less. Java devs have made very painful experiences with those. For good reasons (that are easy to google)

What you gained was giving a type name to a collection of attributes and describing relationships between them. What you lost was the ability to treat the data coming from the database as - well - data. You just put it into a straight jacket (classes).

Your saving grace is a `toData()` function ;)

I would say that ORM, as presented by ActiveRecord and similar approaches, is an anti-pattern. Serviceable in simple circumstances, though.

Such ORMs pretend that data are objects in OOP sense, with internal mutable state stored in their fields. This leads to endless bugs with dirty vs clean state, complicated and bug-prone logic in `.save` methods, hard to debug performance problems with transparent lazy-loading of related objects, and inevitable performance loss on hydration / dehydration of all fields. (I saw and fought this all in practice.)

Better approaches, such as the one available in SQL Alchemy, do not hide the relational nature of the data. They allow to `select` arbitrary tuples, and, most importantly, to build queries from composable, reusable parts.

ORM is not the best interface to an RDBMS. But a good, ergonomic interface to an RDBMS is a very important and useful thing.

It is already here in the form of TypeORM:

https://typeorm.io/

IMO it fits realy well into the whole TypeScript cosmos and to be honest I'm quite happy with my straight jacket.

This looks like a great idea, and good work in implementing it and developing clear documentation.

There is a huge downside though, this ORM doesn't implement any of the real-time features which makes Firestore so appealing in the first place. Snapshot changes is one of the best things about Firestore, allowing realtime database updates to appear on the client. By not using this feature this becomes indistinguishable from any other database backend...

There's also a major limitation without using Batched transactions. As Firestore limits you to 500 updates per request, which comes up pretty fast in a lot of systems.

Sorry to be so critical, genuinely like the efforts made, just thought I'd mention why those features are important.

Thanks for your feedback!

Realtime updates have been implemented in the latest version. Unfortunately no work has done on batched transactions, but I plan to add the feature when I have some spare time.

Do people sometimes come up with project names that are so good, they are compelled to implement the project?

It really is a great name, I'd feel compelled to write it if I had come up with it.

It's certainly clever, but I anticipate plenty of confusion (written, spoken, typed, search engine, etc) due to the Hamming distance between "firestorm" and "firestore". I really wish people would stop trying to use overly cute names.

This is the nomenclatural equivalent of code golf. If someone bragged that they overlapped two constants to save 3 bytes, I would not consider that an improvement. Whatever happened to the belief that communication was more important than brevity?

Some teams even test their user interfaces with users. Names are part of the user interface, yet I've never heard of anyone in software testing a name.

Our engineering team has a #naming slack channel. It actually gets a pretty good amount of use and it's been pretty helpful.

It's not like they were first, and will probably have to change their name:

https://www.firestormviewer.org/

First off: love the name!

I love me a good ORM, though I know many people are not fans. However, having to annotate every member with what almost seems like a duplicate statement seems like a painful way to define an ORM. Before seeing this project I had been under the erroneous assumption that Typescript would somehow provide class introspection, e.g., allow one to 'collect' all defined member variables of a class, but it seems [0] that it does not. I think I've been spoiled by Python.

[0] https://stackoverflow.com/questions/40636292/get-properties-...

Starred.

If I ever try Firebase it will be nice to have this.

Code looks nice! Except like sibling commenter I'm not sure what good typing/programming would look like if doing an ORM in TS.

It's my first time hearing about Firestore by the way. My understanding is Firebase has a real time store, but Firestore is a different tool, similar to MongoDB?

Link to Firestore: https://firebase.google.com/docs/firestore

Although very cool I would’ve liked to see almost the opposite direction away from Firestore and closer to something like a graph would+DB with protobufs, that’s really well aligned with typescript and an ORM that handles migrations/scheme well.

A lot to ask for but where is that? Protobuf is a great great technology for data transmission, something google uses heavily especially for firestore but it would be great to bring more visibility into that versus hiding it away.

Also for consideration for those who use Firestore: Firegraph, enabling you to run GraphQL queries against your store [1]. Not as far along as this project though.

I think this is actually pretty cool. I will probably give it a go next time I work with Firestore.

[1] https://github.com/sejr/firegraph

No transactions. https://github.com/sejr/firegraph/search?q=transaction

omg, I literally just yesterday started working on a project of the same name. I had written a small ORM for my own firestore usage that I planned on open sourcing.

I just looked at this and the fact that it doesn't support transactions is a major dealbreaker. So you do an update on two entities and one fails because of some random network error, now your database is left in an inconsistent state. Not good. Any ORM should, from the start, be written around transactions.

The other issue here is how the tests are written. I appreciate tests, but in this case, they are written agains the client sdk, not the admin sdk. I discovered a huge inconsistency between the two API's that I just filed an issue for... which this project doesn't hit, because it doesn't use transactions...

https://github.com/firebase/firebase-js-sdk/issues/2112

Ugh. You had my interest until the annotations everywhere. They are only Stage 2...

Sorry graphQL+DB* (typed on mobile)

You can edit your comments within 2 hours of first posting them by clicking "edit" above the comment. If it's too late for that, attach your correction to the comment as a reply.

Thank you!

That's a GREAT name!

Reply on news.ycombinator.com