Live data from Hacker News

Show HN: InstantDB – A Modern Firebase

github.com

241–250 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#241
post #194

Earlier quoted context omitted.

I’m not quite seeing what you mean. What you mind redoing the example above for my benefit? We have controllers that all the users actions are funnelled through. The top level functions in there are wrapped in transactions so in practice it’s not something you manually wrangle.

I was thinking about something like: author.save() .then(() => { const article = new Article(db); article.name = "New name"; article.author = author; return article.save(); // could be used to chain the next save }) .then(() => { console.log("Both author and article saved successfully."); }) .catch((error) => { console.error("rollback, no changes"); }); but I confess I might have said that without having the same und…

Gotcha, thanks for the clarification. I’m not sure what that would buy me here.

I have a rule that I only async if it’s a requirement. In my case I can carry out all the steps in a single (simple) sync action. Our updates are optimistic so we update all the models immediately and mobx reflects that in the react components on the next frame.

The network request for the mutation is the only thing that’s running async. If that fails we crash the app immediately rather than trying to rollback bits in the frontend. I know that approach isn’t for everyone but it works well for us.

Re: Show HN: InstantDB – A Modern Firebase

#242
post #52

I saw the mention of Google's CEL for authorisation and permission, however would like to know a little about security. Apart from the appId, can I restrict call to db by domain etc. Firebase has protection on such things . somebody should not just take the appId and start calling db.

[deleted]

Re: Show HN: InstantDB – A Modern Firebase

#243
post #52

I saw the mention of Google's CEL for authorisation and permission, however would like to know a little about security. Apart from the appId, can I restrict call to db by domain etc. Firebase has protection on such things . somebody should not just take the appId and start calling db.

We don't currently expose the `domain` a request comes from in permissions, but we'd be happy to add that in. I've opened up a ticket here [1].

[1] https://github.com/instantdb/instant/issues/18

Re: Show HN: InstantDB – A Modern Firebase

#244

I'm using Hasura connected to a postgres DB at the moment. What you have built sounds great. Hasura offer a self hosted solution so that I know if they decide to close shop for whatever reason, I'm not stuck in the lurch and have to reengineer my entire solution. Do you offer this now or are you planning to?

Thank you!

And yes you can self host today. We have instructions on standing up a server on our github [1]

[1] https://github.com/instantdb/instant/tree/main/server

Re: Show HN: InstantDB – A Modern Firebase

#246

Is this a drop-in, same-client-sdk alternative to firebase? It seems like that’s what would do best in the marketplace… people seem to be fine with the API of firebase and just want it to be cheaper

We love the small API and fast getting started experience of Firebase. We take a lot of inspiration from them for our write api. Hand-rolling joins was often a pain point though and we thought a graphql-like interface was a better experience.

Re: Show HN: InstantDB – A Modern Firebase

#247
post #199
post #187

Earlier quoted context omitted.

Yes that is a deal breaker if not possible

Exactly. I would really like an answer to this. I don't understand how you can even build something without support for this. They have a "Instant on the server" section in the docs but that's just about querying and writing to the database from an external server. Nothing about middlewares or whatever the solution would be.

Our permission system [1] can work like middleware.

> Let's say I want moderation

I am not 100% sure what you mean by moderation. There could be two ideas:

Moderation 1: 'some people can see all posts, or delete other people's posts'

You can write a rule that allows 'moderators' full access to chat, while, 'users' can only see the channels they blog too, and crud their own messages

Moderation 2: 'I want to validate that some field passes a test -- like 'messages must be under 140 chars''.

You could write a permission rule like `size(data.message) > rate limiting

We don't have built in support for rate limiting, but CEL [2] could handle it. If you have a specific need, let us know and we'd be happy to prioritize it: founders@instantdb.com

[1] https://www.instantdb.com/docs/permissions [2] https://guides.rubyonrails.org/active_record_validations.htm...

Re: Show HN: InstantDB – A Modern Firebase

#248
post #60

The datalog syntax has me curious. It looks like a JavaScript "port" of Datomic's Datalog syntax. Have you considered using other forms of Datalog that are seemingly more compatible with JavaScript? See https://en.wikipedia.org/wiki/Datalog?useskin=vector#Syntax I wouldn't mind using the Datalog syntax as-is since I have some experience using Clojure with Datomic, but it did surprise that someone would decide to use…

> but it did surprise that someone would decide to use this syntax over a syntax used in other Datalog engines (and predating Datomic itself).

We are clojure programmers, so our introduction to Datalog was actually though Datomic in 2014. We are fans of other query syntaxes (SparQL looks cool too), but we find Datomic's flavor the most ergonomic for us, and it's an added win for us that we can express queries as plain data structures

Re: Show HN: InstantDB – A Modern Firebase

#249
post #145

Earlier quoted context omitted.

Yes. This gives users the vibe of “ this is obvious, if you don’t know it , you are dumb “ .

Or that the writers were oblivious, and the documentation shouldn’t be relied upon.

I usually read: you have so few users / care so little that I shouldn’t trust you because you’d have heard this complaint and fixed it. But in this case it was fixed up quickly. Which is great

Re: Show HN: InstantDB – A Modern Firebase

#250

What's the short summary of how the authorization system works for this? One of the things I find quite nice about firebase is the quite powerful separation between the logic of data retrieval / update and the enforcement of access policy -- if you understand it you can build the prototype on a happy path with barely any authorization enforcement and then add it later and have quite complete confidence that you aren'…

> What's the short summary of how the authorization system works for this? We built a permission system on top of Google's CEL [1]. Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule. The docs: https://www.instantdb.com/docs/permissions The experience is similar to Firebase in three ways: 1. Both languages are based on C…

> Firebase Realtime can be more efficient, as it can tell if a permission check has passed statically. I am not sure if Firestore works this way.

Firestore's rules are also able to prove before the query runs if the query will only return data that the user has access to according to the rules. That's a pretty important property that "rules aren't filters" because it prevents bad actors from DDOSing your system. My former colleague wrote about this: https://medium.com/firebase-developers/what-does-it-mean-tha...

Post reply on HN