from Hacker News

Show HN: InstantDB – A Modern Firebase

by nezaj on 8/22/24, 5:08 PM with 297 comments

    function Chat() {
      // 1. Read
      const { isLoading, error, data } = useQuery({
        messages: {},
      });
    
      // 2. Write
      const addMessage = (message) => {
        transact(tx.messages[id()].update(message));
      }
    
      // 3. Render!
      return <UI data={data} onAdd={addMessage} />
    }

• by jamest on 8/22/24, 6:00 PM

  [Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story).

  Good luck, Joe, Stopa and team!

• by sibeliuss on 8/22/24, 10:58 PM

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

• by codersfocus on 8/22/24, 8:15 PM

  For those looking for alternatives to the offline first model, I settled on PowerSync. Runner up was WatermelonDB (don't let the name fool you.) ElectricSQL is still too immature, they announced a rewrite this month. CouchDB / PocketDB aren't really up to date anymore.

  Unfortunately this area is still immature, and there aren't really great options but PowerSync was the least bad. I'll probably pair it with Supabase for the backend.

• by swalsh on 8/23/24, 12:30 PM

  I'm wary of stuff like this, probably really useful to rapidly iterate.... but what a maintence nightmare after 10 years and your schema has evolved 100 times, but you have existing customers in various state of completeness. I avoided firebase when it came out for this reason. I had a few bad experiences with maintaining applications built on top of Mongo that made it to production. It was a nightmare.

• by blixt on 8/23/24, 5:15 AM

  I saw the reference to “apps like Figma” and as one of the people that worked on Framer’s (also a canvas based app) database which is also local+multiplayer I find it hard to imagine how to effectively synchronize canvas data with a relational database like Postgres effectively. Users will frequently work on thousands of nodes in parallel and perform dragging updates that occur at 60 FPS and should at least be propagated to other clients frequently.

  Does Instant have a way to merge many frequent updates into fewer Postgres transactions while maintaining high frequency for multiplayer?

  Regardless this is super cool for so many other things where you’re modifying more regular app data. Apps often have bugs when attempting to synchronize data across multiple endpoints and tend to drift over time when data mutation logic is spread across the code base. Just being able to treat the data as one big object usually helps even if it seems to go against some principles (like microservices but don’t get me started on why that fails more often than not due to the discipline it requires).

• by lewisl9029 on 8/23/24, 12:45 AM

  Congrats on the launch! :)

  Apparently I signed up for Instant previously but completely forgot about it. Only realized I had an account when I went to the dashboard to find myself still logged in. I dug up the sign up email and apparently I signed up back in 2022, so some kind of default invalidation period on your auth tokens would definitely make me a bit more comfortable.

  Regardless, I'm still as excited about the idea of a client-side, offline-first, realtime syncing db as ever, especially now that the space has really been picking up steam with new entrants showing up every few weeks.

  One thing I was curious about is how well the system currently supports users with multiple emails? GitHub popularized this pattern, and these days it's pretty much table stakes in the dev tools space to be able to sign in once and use the same account across personal accounts and orgs associated with different emails.

  Looking at the docs I'm getting the sense that there might be an assumption of 1 email per user in the user model currently. Is that correct? If so, any plans to evolve the model to become more flexible?

• by coffeemug on 8/22/24, 8:32 PM

  Congrats on the launch! I think Firebase was started in 2011, and it's incredible that 13 years later the problem is still unsolved in an open way. We took a shot at this at RethinkDB but fell short. If I were doing this again today, Instant is how I would build it. Rooting for you!

• by antidnan on 8/22/24, 6:59 PM

  I've been using Instant for about 6 months and have been very happy. Realtime, relational, and offline were the most important things for us, building out a relatively simple schema (users, files, projects, teams) that also is local first. Tried a few others unsuccessfully and after Instant, haven't looked back.

  Congrats team!

• by breatheoften on 8/22/24, 6:47 PM

  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't leaking data between users or allowing them to change something they shouldn't be able to. Although you do need to keep the way this system works in mind as you build and I have found that developers often don't really grasp the shape of these mechanisms at first

  From what I can tell -- the instant system is different in that the permission logic is evaluated on the results of queries -- vs firebase which enforces whether the query is safe to run prior to it even being executed ...

• by the_duke on 8/22/24, 8:53 PM

  I've found triple stores to have pretty poor performance when most of your queries fetch full objects, or many fields of the same object, which in the real world seems to be very common.

  Postgres also isn't terrible, but also not brilliant for that use case.

  How has your experience been in that regard?

• by remolacha on 8/22/24, 8:00 PM

  I really want an ActiveRecord-like experience.

  In ActiveRecord, I can do this:

  ```rb

  post = Post.find_by(author: "John Smith")

  post.author.email = "john@example.com"

  post.save

  ```

  In React/Vue/Solid, I want to express things like this:

  ```jsx

  function BlogPostDetailComponent(...) {

    // `subscribe` or `useSnapshot` or whatever would be the hook that gives me a reactive post object
  
    const post = subscribe(Posts.find(props.id));
  
    function updateAuthorName(newName) {
      // This should handle the join between posts and authors, optimistically update the UI
  
      post.author.name = newName;
  
      // This should attempt to persist any pending changes to browser storage, then
      // sync to remote db, rolling back changes if there's a failure, and
      // giving me an easy way to show an error toast if the update failed. 
  
      post.save();
    } 
  
    return (
      <>
        ...
      </>
    )

  }

  ```

  I don't want to think about joining up-front, and I want the ORM to give me an object-graph-like API, not a SQL-like API.

  In ActiveRecord, I can fall back to SQL or build my ORM query with the join specified to avoid N+1s, but in most cases I can just act as if my whole object graph is in memory, which is the ideal DX.

• by w10-1 on 8/22/24, 8:22 PM

  Is the datalog engine exposed? Is there any way to cache parsed queries?

  Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? Or is it on the roadmap?

  I have fairly large and overlapping rules/queries. Is there any way to store parsed queries and combine them?

  Also, why the same name as the (Lutris) Enhydra java database? Your domain is currently listed as a "failed company" from 1997-2000 (actual usage of the Java InstantDB was much longer)

     https://dbdb.io/db/instantdb
  

  Given that it's implemented clojure and some other datalog engines are in clojure, can you say anything about antecedents?

  Some other Clojure datalog implementations, most in open source

  - Datomic is the long-standing market leader

  - XTDB (MPL): https://github.com/xtdb/xtdb

  - Datascript (EPL): https://github.com/tonsky/datascript

  - Datalevin ((forking datascript, EPL): https://github.com/juji-io/datalevin

  - datahike (forking datascript, EPL): https://github.com/replikativ/datahike

  - Naga (EPL): https://github.com/quoll/naga

• by webdevladder on 8/22/24, 6:00 PM

  As a potential dev user this looks really intriguing, hitting all of the main points I was looking for. I build apps in this space, and the open source alternatives I've evaluated are lacking specifically in "live queries" or don't use Postgres. The docs look great too.

  In the docs[1]:

  > Instant uses a declarative syntax for querying. It's like GraphQL without the configuration.

  Would you be interested in elaborating more about this decision/design?

  [1] https://www.instantdb.com/docs/instaql

• by remolacha on 8/22/24, 6:02 PM

  This is awesome. I know that a lot of people are looking for something like the Linear sync engine.

  I appreciate that you're thinking about relational data and about permissions. I've seen a bunch of sync engine projects that don't have a good story for those things.

  imo, the more that you can make the ORM feel like ActiveRecord, the better.

• by TeeWEE on 8/23/24, 4:45 AM

  Very nice!

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

• by RoboTeddy on 8/24/24, 6:18 PM

  (1) This is awesome. Feels like this wraps enough complexity that it won't just be a toy / for prototyping.

  (2) When a schema is provided, is it fully enforced? Is there a way to do migrations?

  Migrations are the only remaining challenge I can think of that could screw up this tool long-term unless a good approach gets baked in early. (They're critically important + very often done poorly or not supported.) When you're dealing with a lot of data in a production app, definitely want some means of making schema changes in a safe way. Also important for devex when working on a project with multiple people — need a way to sync migrations across developers.

  Stuff like scalability — not worried about that — this tool seems fundamentally possible to scale and your team is smart :) Migrations though... hope you focus on it early if you haven't yet!

• by taw1285 on 8/22/24, 6:46 PM

  This looks fantastic. I want to recommend this to my team. We are a small consulting team building apps for clients. I have a few questions to help me pitch my team and clients better: 1. the usual "vendor locked in". Is there a recommended escape hatch? 2. any big clients on this yet or at what scale do you expect people to start rolling their in house product

• by projektfu on 8/22/24, 6:52 PM

  It reminds me of the data half of Meteor, but it looks better thought-out and, obv., not based on Mongo. Nice work.

• by monomers on 8/23/24, 8:30 AM

  I'm missing clarity about how do I escape Instant DB when I need to, and how to make it part of a larger system.

  Say I have an InstantDB app, can I stream events from the instant backend to somewhere else?

• by IanCal on 8/22/24, 5:58 PM

  I've just used this to start a bouldering app, so far has been extremely simple, great work.

  I'm not sure about how things grow from here in terms of larger aggregates and more complex queries though so am slightly worried I'm painting myself into a corner. Do you have any guides or pointers here? Or key areas people shouldn't use your db?

• by the_king on 8/23/24, 3:47 AM

  This 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 "Don't Make Me Think" API.

  (written with aqua)

• by cheema33 on 8/23/24, 4:07 PM

  Is it correct to assume that if your existing application has lots of data stored in standard PostgreSQL tables, you can't have InstantDB sync with it?

  In other words it primarily targets brand new projects or projects that can completely migrate away from their current database?

• by kabes on 8/23/24, 11:53 AM

  From skimming through the site, it's not clear to me how the BE looks like. Obviously, the BE part is the hard/interesting part. Is that open-source and/or self deployable? Or is this fixed to a backend-as-a-service you guys provide?

• by ochiba on 8/22/24, 8:32 PM

  Sounds conceptually similar to Zero: https://zerosync.dev/

  I haven't looked in detail yet — what are the main differences relative to Zero?

• by jeromechoo on 8/22/24, 6:46 PM

  This is awesome. I built a real time whiteboarding app for teachers over 10 years ago on the backbone of the original Firebase service.

  It was so fast I was able to build basic collision physics of letter tiles and have their positions sync to multiple clients at once. What a shame to be killed by Google.

  I haven't had a need for real time databasing since, but this is inspiring me to build another collaborative app.

• by mattfrommars on 8/23/24, 12:15 AM

  I read the whole thing but I fail to understand how does this help or fit into picture of CRUD app. Most app I interact and work for a living are essentially a CRUD, SQL Server and a DOA layer by Spring.

  How do I need to start thinking conceptually for this, InstantDB or Firebase concept to kick in?

  Say for a collaborative text editor, I'd use off the shelf CRDT Javascript implementation.

• by jgeurts on 8/25/24, 12:34 AM

  This looks great! Is there a way to sync with an api? For instance, my site currently has a rest based api with a non-Postgres backed db but I’d like to add offline, sync, real-time capabilities. Is there an option to sync the updates outside of the Postgres store?

• by p2hari on 8/22/24, 8:00 PM

  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.

• by DandyDev on 8/22/24, 5:56 PM

  What isn’t modern about Firebase and what makes this modern in comparison?

• by piyushtechsavy on 8/23/24, 7:40 AM

  This seems like a game changer for real time applications. We have been using Firebase mostly for it RTDB and websocket kind of implementation without actually maintaining websocket at the backend. This takes things a step ahead.

• by koito17 on 8/22/24, 8:17 PM

  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 this syntax over a syntax used in other Datalog engines (and predating Datomic itself).

• by h4ny on 8/23/24, 3:02 PM

  This is super exciting! I was literally just wondering if something like this existed a few days ago (seriously)!

  Some super minor feedback appended. All the best with InstantDB!

  There is a missing word in the message that appears after clicking on the "Create an app" button:

  > With that one-click you’ve claimed an id that you can use for storing your data. Now we'll show you [how] to wire up your db to an app and start adding data. Check out the walkthrough below on your left with the full code and preview on the right.

  Also on smaller screen sizes there is no left and right. :)

• by cheema33 on 8/22/24, 10:17 PM

  I have been eyeing Electric SQL lately for developing a local-first app. How does InstantDB compare with Electric SQL?

  Side note: Electric SQL is currently going through a rewrite, so things are a bit up in the air.

• by deepsun on 8/23/24, 1:39 AM

  > ... we would need a schema. But it turns out triple stores don’t need one.

  Data always needs a schema (unless it's random bits aka max entropy). The question is just where it's managed and enforced.

• by Kiro on 8/22/24, 7:41 PM

  How do I handle server-side logic? Let's say I want moderation or rate limiting in the chat app example.

• by robinpdx on 8/22/24, 6:49 PM

  This looks awesome and like something I could leverage on my team. I’m trying to modernize the back end of our chat service (at a large company you’ve heard about), to support real-time instead of polling and modern affordances like typing indicators, read receipts, and reactions.

  I’ve built a prototype of a full stack using Flask + SocketIO + SQLite as well as an iOS client to prove the concept to the VPs.

  How well do you think this can scale? Any plans to make native SDKs for iOS and Android?

• by agambrahma on 8/22/24, 8:37 PM

  Interesting that this is Clojure :-)

  Clojure + TS seems to be a good way to go, without being hung up on CLJS.

• by kachapopopow on 8/23/24, 4:56 PM

  Why clojure (and by proxy Java?). I don't have a problem with either, but it puzzles me quite a bit.

  Why not the standard node.js with shared module? Assuming performance is not the primary goal.

  Why not generated rust structures from model file and a rust server? Assuming performance is the primary goal.

  Why not a jvm with a lightweight runtime? (Assuming instancing is used for scale here, a lot of wasted ram usage here)

• by techn00 on 8/22/24, 8:29 PM

  How do you prevent the user from uploading a 5gb string to one of the fields?

• by mizzao on 8/23/24, 2:32 PM

  A really exciting product from many years ago was Meteor, which included a realtime database layer on top of Mongo that facilitated many very novel realtime apps.

  However, it didn't scale well in terms of performance to large numbers of users.

  Would anyone have thoughts on comparisons to Meteor?

• by j_san on 8/23/24, 9:55 AM

  Is there a plan to make it self-hostable?

• by TripleChecker on 8/22/24, 10:16 PM

  Congrats! BTW, we found a few typos on the site that you might want to fix: https://triplechecker.com/s/yyNfc1/instantdb.com?v=wh8Jr

• by terpimost on 8/23/24, 12:31 AM

  If it's offline where the data is stored? IndexDB?

• by aidos on 8/22/24, 8:10 PM

  This looks great. We use our own version of something much more naive which allows for the various benefits you have (but yours does more). Ours is also based on Linear but we go all in on mobx like they do too. It’s a great model where we have optimistic updates and a natural object graph to work with in typescript. I’ll have a play with this to see if it could eventually be used as a replacement.

  Noticed in your docs you say that Hasura uses RLS for permissions but that’s not true. They have their own language for effectively specifying the filters to apply on a query. It’s a design decisions that allows them to execute the same query for all connected clients at the same time using different parameters for each one.

• by punnerud on 8/23/24, 6:30 AM

  Intro on X: https://x.com/stopachka/status/1826674372175900724?s=46&t=mn...

• by k__ on 8/22/24, 7:54 PM

  Is this similar to CouchDB/PouchDB?

  Can the backend be replaced?

• by legohorizons on 8/22/24, 6:29 PM

  what would you say are pros/cons vs. supabase?

• by samstave on 8/22/24, 11:02 PM

  How about (inspired by another HN post) - a rebuild of a TUI for email, given how its built:

  https://blog.sergeantbiggs.net/posts/aerc-a-well-crafted-tui...

  https://aerc-mail.org/

  It seems that building a version of this Aerc Email TUi with Instant is a completely doable?

  Might be an interesting tutorial to build out an Instant FroBenDB (Instant is an instant Front-BackendDB :-) --- btu the txtual nature of aerc and its configs seem ripe for just bolting it to Instant.

• by gr4vityWall on 8/23/24, 2:49 AM

  That strongly reminds me of Meteor. It's crazy to think how many modern problems were solved by design there years ago.

  I wish you the best of luck, having a real-time database on the client does make things much easier.

• by ripped_britches on 8/23/24, 12:10 AM

  Please make a flutter SDK

• by chrysoprace on 8/23/24, 12:25 AM

  Is it fully self-hostable? A lot of the time you have to hunt down small clauses in tools like these that state that some essential part of it can't be self-hosted.

• by wheelerwj on 8/22/24, 6:02 PM

  Is Firebase not modern anymore?

  I think this looks like, a backend-end-in-box type of product? So that you just have to focus on front end mostly?

  Could be cool for early stage projects.

• by thruflo on 8/22/24, 8:31 PM

  Congrats to the Instant team. It’s a fantastic project. The DX is great and the engineering behind the datalog engine is really impressive.

• by notsahil on 8/22/24, 6:14 PM

  Is it different than CRDTs?

• by avinassh on 8/22/24, 6:10 PM

  > we tail postgres’ WAL to detect novelty and use last-write-win semantics to handle conflicts

  can you elaborate more on how you achieve this

• by xnx on 8/22/24, 5:46 PM

  Seems comparable to https://pocketbase.io/

• by sgonz on 8/22/24, 6:32 PM

  Very cool! How does this compare to Supabase?

• by truetraveller on 8/23/24, 4:38 AM

  Why would I use this over Yjs or Automerge?

• by dsmurrell on 8/23/24, 8:15 AM

  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?

• by superfunguy_94 on 8/23/24, 7:33 AM

  this could be very useful for real-time, collaborative apps. Looking forward to trying in out on my next project

• by manx on 8/23/24, 7:39 AM

  Looks great! How is the migration story when schema changes are needed? How do you deal with old clients?

• by warden_2003 on 8/22/24, 5:10 PM

  Cute commit message...

• by h_tbob on 8/22/24, 6:14 PM

  These ideas are cool but I wonder how security works. Do you do like rate limiting and stuff like that?

• by kentor on 8/29/24, 7:02 AM

  Just replaced Firebase with this in my personal notes app. Also removed redux along the way :) This is great!!

• by eashish93 on 8/23/24, 1:18 PM

  Hey this is great. But this should be pay per pricing model instead of $30/month upfront. I don't think with this pricing model it can be compete with cloudflare suite of products like durable objects, kv etc.

• by reichertjalex on 8/23/24, 3:28 PM

  In case it's helpful for anyone, I did a little write-up of my experience using Instant a couple months ago to hack together a simple weekend project: https://www.alexreichert.com/blog/ceramics-with-instantdb

  tl;dr -- I'm a big fan :)

• by aipro778 on 8/26/24, 5:11 PM

  Tailing the WAL is an interesting approach. How do you handle the potential increased load on the database from constant WAL reads?

• by unsupp0rted on 8/25/24, 9:41 AM

  Congrats on the launch! It looks like all your examples are React (or Vanilla JS with a minimal implementation of reactivity).

  Would you be able to add examples for Vue JS?

• by novoreorx on 8/23/24, 4:44 AM

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

• by yblu on 8/25/24, 5:39 AM

  This looks awesome. Maybe a stupid question: appID is public, does it mean anyone can query everyone else's database if they know the appID?

• by hardwaresofton on 8/23/24, 5:15 AM

  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

• by bigblind on 8/22/24, 7:37 PM

  This looks very cool!

  I'm slightly worried about permissions evaluating to "true" if they're not specified. I think this will lead to a lot of actions being accidentally allowed.

• by Chipshuffle on 8/24/24, 5:55 AM

  I‘m wondering how this compares to convex (https://www.convex.dev/)

• by buf on 8/23/24, 2:07 PM

  Any plans to support other backends besides javascript?

• by serial_dev on 8/22/24, 7:13 PM

  Do you have clients for Android, iOS, Mac apps, Flutter, Rust? If not, how hard do you think it is to implement a client for an additional language?

• by _kidlike on 8/22/24, 8:38 PM

  This is awesome, and in a way the reverse of HTMX :)

• by jakubmazanec on 8/23/24, 8:21 PM

  Maybe they're aiming for different use cases, but for modern web app development I still prefer EdgeDB.

• by Alifatisk on 8/22/24, 10:04 PM

  Their icon looks like fig.io but inverted

• by Hadriel on 8/23/24, 6:15 AM

  I'm curious if something like this would be good for multiplayer games?

• by intellix on 8/23/24, 8:48 AM

  Kind of like Horizon + RethinkDB? which sadly disappeared out of nowhere

• by ibash on 8/22/24, 7:26 PM

  This looks awesome! Do you have any numbers around end-to-end latency?

• by charlie0 on 8/22/24, 6:51 PM

  A "modern" Firebase? Firebase is only ~10 years old...

• by android521 on 8/22/24, 6:53 PM

  How is it better than firebase or Superbase ?

• by maninblackv2 on 8/23/24, 5:13 AM

  How is async storage limit is handled ?

• by softlylove on 8/23/24, 1:39 AM

  How does it compare with Liveblocks?

• by thomasfl on 8/23/24, 9:10 AM

  Databases accessed directly from javascript in the browser, may change yet again how multi user webapps is being written. Looking forward to playing with InstantDb.

• by mr-pink on 8/22/24, 11:06 PM

  you could call it freebase, because this is very stimulating

• by bpiroman on 8/23/24, 4:31 AM

  best thing I ever did was move away from firebase

• by Lionga on 8/23/24, 11:06 AM

  Would like to try this out if it had a Flutter/Dart SDK

• by patrickaljord on 8/23/24, 2:06 PM

  is the server side open source too?

• by otteromkram on 8/23/24, 3:22 AM

  > “Facebook and Airbnb“

  I know it's "just a paycheck," but I despise both of these companies, so I'll probably pass on this.

  The usage of "schlep" so freely is also a bit unsettling.

  Good luck!

• by pyryt on 8/22/24, 6:56 PM

  This looks promising! Does any LLM understand Instantdb yet?

• by bnormative on 8/22/24, 7:26 PM

  Thanks but no thanks. Firebase is already modern.