
Show HN: Firestorm – An ORM for Firestore - lmcq
https://github.com/lmcq/firebase-firestorm
======
beders
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 ;)

~~~
nine_k
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.

------
gitgud
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.

~~~
lmcq
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.

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

~~~
ken
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.

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

------
somada141
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-...](https://stackoverflow.com/questions/40636292/get-properties-
of-a-class)

------
tony
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](https://firebase.google.com/docs/firestore)

------
gvkhna
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.

------
sjroot
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](https://github.com/sejr/firegraph)

~~~
latchkey
No transactions.
[https://github.com/sejr/firegraph/search?q=transaction](https://github.com/sejr/firegraph/search?q=transaction)

------
latchkey
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](https://github.com/firebase/firebase-js-sdk/issues/2112)

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

------
gvkhna
Sorry graphQL+DB* (typed on mobile)

~~~
mkl
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.

~~~
gvkhna
Thank you!

------
xmonkee
That's a GREAT name!

