SapphireDb – Open-Source Alternative to Firebase • Hacker News Board

Re: SapphireDb – Open-Source Alternative to Firebase

#61

Post by em-bee » Fri, Jan 17, 2020, 4:35 PM UTC

tluyben2 wrote: post #16

marknadal wrote: post #10

I'm a competitor, and I want to applaud this work! - SapphireDB is truly Open Source, MIT! - There demo worked like a charm! We could really use more projects like this out there. Here is a criticism though: - It seems currently to only support Angular (?), which is gonna harm its adoption. My recommendation would be to commit to Svelte, it seems like it will be the "next big thing" in the JS world, and could help dr…

Offtopic: > to commit to Svelte, it seems like it will be the "next big thing" in the JS world How long does it usually take? In the JS world? Serious question as I am not in the JS world but reading HN/Reddit I would believe that things change quite fast. Someone told me over 1 year ago Svelte would be the next big thing and I see ‘no-one’ using it besides some hardcore enthusiasts; it is even hardly ever mentioned…

the next best thing is hard to predict, as thre sister comment says. it's also not an important measure. the measure that matters is wheter a framework is going to stick around and be supported for the next few years.

to choose a framework look at all that are being used and recommended.

for every recommended framework there are a dozen that remain in obscurity.

that should narrow it down to a dozen or so. look at each and pick on you like the most by whatever metric you prefer. it does't matter.

keep using that same framework as long as you are happy with it.

if you are able to stick with the same framework for a few years you made good choice.

as for svelte, one metric is the stateofjs survey, which lists svelte as one of the top 6 frameworks.

it was added to the survey last year which shows a significant amount of interest. let's see if that is still true next year.

https://2019.stateofjs.com/front-end-frameworks/

my own choice, aurelia, which i picked a few years ago, is the 3rd most write-in choice. it has a healthy community and active development. and i see no need to change for the forseeable future. it doesn't need to be the next big thing.

Re: SapphireDb – Open-Source Alternative to Firebase

#62

Post by _frkl » Sat, Jan 18, 2020, 9:34 PM UTC

kiwicopple wrote: post #60

_frkl wrote: post #55

Earlier quoted context omitted.

Neat. Did you have a look at Hasura before you implemented this, or does your solution have other features you needed? Edit: also, Debezium might be a good backend for this, that way you would be able to support other databases than Postgres.

I took a lot of inspiration from Hasura and Debezium. At the time they used triggers to send events via NOTIFY (not sure if they still do) The issue with NOTIFY is that it has an 8000 byte limit. Some of our updates are large (JSONB columns) so we need more than 8000 bytes, or we would have to notify just the row identifier, then fetch the data (inefficient). Supabase hooks in to Postgres' replication stream so there…

That makes a lot of sense. Tempted to try this out now. If people would just stop coming up with all those really interesting projects, that'd be great. At some point I should probably get some actual work done...

Re: SapphireDb – Open-Source Alternative to Firebase

#63

Post by gunnarmorling » Thu, Jan 30, 2020, 7:58 PM UTC

kiwicopple wrote: post #60

_frkl wrote: post #55

Earlier quoted context omitted.

Neat. Did you have a look at Hasura before you implemented this, or does your solution have other features you needed? Edit: also, Debezium might be a good backend for this, that way you would be able to support other databases than Postgres.

I took a lot of inspiration from Hasura and Debezium. At the time they used triggers to send events via NOTIFY (not sure if they still do) The issue with NOTIFY is that it has an 8000 byte limit. Some of our updates are large (JSONB columns) so we need more than 8000 bytes, or we would have to notify just the row identifier, then fetch the data (inefficient). Supabase hooks in to Postgres' replication stream so there…

Debezium uses neither triggers nor NOTIFY. For Postgres, it uses one of several supported logical decoding plug-ins (pgoutput, decoderbufs, wal2json), which doesn't have any size limit and also allow to capture changes occuring while it isn't running by catching up with changes from the WAL from the point where it left off before.

Disclaimer: Debezium lead here