Show HN: InstantDB – A Modern Firebase
141–150 of 308 posts
Re: Show HN: InstantDB – A Modern Firebase
#142Re: Show HN: InstantDB – A Modern Firebase
#143Earlier quoted context omitted.
Thanks for creating Firebase! It's really the definition of an managed database/datastore. Do you see InstantDB as a drop in replacement ? To be honest I don't want to have to worry about my backend. I want a place to effectively drop JSON docs and retract them later. This is more than enough for a hobbyist project, though I imagine at scale things get might not work as well.
If you only need simple dropping and collecting back, maybe you should consider about AWS S3 or Supabase storage.
Re: Show HN: InstantDB – A Modern Firebase
#144Re: Show HN: InstantDB – A Modern Firebase
#145One bit of feedback: Its always appreciated when code examples on websites are complete. Your example isn't complete -- where's the `transact` import coming from, or `useQuery`? Little minor details that go far as your product scales out to a wider user base.
Yes. This gives users the vibe of “ this is obvious, if you don’t know it , you are dumb “ .
Re: Show HN: InstantDB – A Modern Firebase
#146This is really cool. Curious to see more about how the database can be queried. I don't write much SQL these days, and I have no dedication to Postgres, but it does integrate with pretty much everything. Also curious how I'd go about the basics in Instant. For example, creating a user table and ensuring that emails are unique - I've done it 50 times with Postgres. Is that part built out yet? Very cool. Appreciate the…
Yes. Auth comes out of the box with Instant. You get support magic code-based auth, Google OAuth, and have an option to extend it using your own backend if you prefer.
P.S Aqua seems very cool; I broke my thumb 6 months ago, and would have definitely appreciated a tool like that.
Re: Show HN: InstantDB – A Modern Firebase
#147Re: Show HN: InstantDB – A Modern Firebase
#148However for our use case we want total control over the server database. And wanted to store it in normalized tables.
The solution we went for us is streaming the mutation stream (basically the WAL) from/to client and server. And use table stream duality to store them in a table.
Permissions are handled on a table level.
When a client writes it sends a mutation to the servers. Or queues it locally if offline. Writes never conflict: we employ a CRDT “last write wins” policy.
Queries are represented by objects and need to be implemented both in Postgres as wel as SQLLite (if you want offline querying, often we don’t). A query we implement for small tables is: “SELECT *”.
Note that the result set being queried is updated realtime for any mutation coming in.
It’s by default not enforcing relational constraints on the clientside so no rollbacks needed.
However you can set a table in different modes: - online synchronous writes only: allows us to have relational constraints. And to validate the creation against other server only business rules.
The tech stack is Kotlin on client (KMM) and server, websocket for streaming. Kafka for all mutations messaging. And vanilla Postgres for storing.
The nice thing is that we now have a Kafka topic that contains all mutations that we can listen to. For example to send emails or handle other use cases.
For every table you: - create a serializable Kotlin data class - create a Postgres table on the server - implement reading and writing that data, and custom queries
Done: the apps have offline support for reading a single entity and upserts. Querying require to be online if not implemented on the client.
Re: Show HN: InstantDB – A Modern Firebase
#149I saw the `db.useQuery` function, quite good for people who are familiar with react-query, but is there a `useMutation` equivlent? It seems that `db.transact` does not return anything stateful.