Live data from Hacker News

Show HN: Drop-in SQS replacement based on SQLite

github.com

111–120 of 171 posts

Re: Show HN: Drop-in SQS replacement based on SQLite

#111

Earlier quoted context omitted.

Just from IP/legal point of view AGPL and AGPL adjacent licensing that imposes control over how you use the code is a non-starter for many companies especially ones that are "backed by YC" proudly displayed on their website because that signals money will be exchanged in the future by design. MIT/BSD license that imposes no control over the how the code is used is the only FOSS we are allowed to use and we do donate…

I actually have no beef with either “money will change hands in the future” or “AGPL because we want to advance FOSS.” The problem is that AGPL is a total no starter at “day job,” and even at “side gig,” I'm obviously not going to release the source code of the entire service because of a message queue dependency. I mean, if I was trying to switch clouds for whatever reason, I might want this, and could even be persu…

my issue with money being mixed up with FOSS via AGPL is because it inevitably leads to a fork where the paid version has features and performance superior to the open source "community" version.

i much rather ppl just release closed source proprietary software that i can pay for and the value proposition is clear not be lead to surprises down the road where the community version is neglected

Re: Show HN: Drop-in SQS replacement based on SQLite

#112

Earlier quoted context omitted.

Ugh I didn't see that. My enthusiasm has instantly waned. Why is AGPL needed? Just be MIT and make it easy for people, espefcially if you're not planning on monetising it. I won't use AGPL code just on principle.

Why? Does AGPL really matter if you're not planning on monetising whatever it is you're using it for? Not trying to be snarky, I'm genuinely curious why you'd be so vehemently opposed to it.

I think the crux of the argument is that if you are not planning to monetize it, why stop other people from doing so?

Re: Show HN: Drop-in SQS replacement based on SQLite

#113
post #103
post #102

Correct me if I’m wrong but: SQLite sounds like: runs on one server. While that will work most of the time, it won’t work 100% of the time. I don’t know the specifics, but I’m fairly sure if a queue server crashes, SQS will keep working, as stuff is redundant. So while it can work in a best case, this (probably) won’t have the same reliability as SQS has..

I break it down two ways. First, the project does not yet have a distributed implementation, you’re correct. Stay tuned! Second, SQLite is incidental. Data is still stored on disk, just as SQS must be, but I’ve chosen SQLite as the file format for now.

Strictly speaking, SQS does not necessarily store data on disk and being highly available and fault tolerant does not exclude one from operating a completely volatile data store. Indeed, SQLite itself has an in-memory option which, when appropriately architected, could be used as the primary data store for a highly available and fault tolerant queue.

Having said that, I think it is safe to assume that SQS probably stores information to non-volatile storage.

Nice work on the project!

Re: Show HN: Drop-in SQS replacement based on SQLite

#114
Tangential but I looked at the codebase - because I like to imagine I can code (I can’t) - and for a laymen, I could follow the code.

Makes me think quite positively of go lang and of the dev for designing in such a way. Can understand why teams like it because of easier maintenance

Quite elegant from my uneducated pov.

Re: Show HN: Drop-in SQS replacement based on SQLite

#115

Congratulations! I also love writing AWS API-compatible services. That's why I did Dyna53 [1] ;P (I know, unrelated, but hopefully funny) [1] https://dyna53.io

It is fun, indeed. Could be a candidate for the best technology abuse of the year.

Re: Show HN: Drop-in SQS replacement based on SQLite

#116
post #114

Tangential but I looked at the codebase - because I like to imagine I can code (I can’t) - and for a laymen, I could follow the code. Makes me think quite positively of go lang and of the dev for designing in such a way. Can understand why teams like it because of easier maintenance Quite elegant from my uneducated pov.

Thank you for the kind words! I'll be sure to work on making it as complicated as I can :)

Re: Show HN: Drop-in SQS replacement based on SQLite

#117
post #112

Earlier quoted context omitted.

Why? Does AGPL really matter if you're not planning on monetising whatever it is you're using it for? Not trying to be snarky, I'm genuinely curious why you'd be so vehemently opposed to it.

I think the crux of the argument is that if you are not planning to monetize it, why stop other people from doing so?

Also, is there really any money left in message queues?

Every man and his dog has made a message queue with Postgres. Message queues are everywhere on github and often posted on HN.

Re: Show HN: Drop-in SQS replacement based on SQLite

#118
post #112

Earlier quoted context omitted.

Why? Does AGPL really matter if you're not planning on monetising whatever it is you're using it for? Not trying to be snarky, I'm genuinely curious why you'd be so vehemently opposed to it.

I think the crux of the argument is that if you are not planning to monetize it, why stop other people from doing so?

AGPL don't stop nobody from monetizing anything, they just gotta make their modifications public.

Re: Show HN: Drop-in SQS replacement based on SQLite

#119
post #114

Tangential but I looked at the codebase - because I like to imagine I can code (I can’t) - and for a laymen, I could follow the code. Makes me think quite positively of go lang and of the dev for designing in such a way. Can understand why teams like it because of easier maintenance Quite elegant from my uneducated pov.

[deleted]

Re: Show HN: Drop-in SQS replacement based on SQLite

#120
post #102

Correct me if I’m wrong but: SQLite sounds like: runs on one server. While that will work most of the time, it won’t work 100% of the time. I don’t know the specifics, but I’m fairly sure if a queue server crashes, SQS will keep working, as stuff is redundant. So while it can work in a best case, this (probably) won’t have the same reliability as SQS has..

The choice of SQLite is a great one as the distributed sqlite space is also growing. You have things like rqlite (raft+sqlite), and you have cloudservices like CloudFlare D1 which is basically distributed/HA sqlite. Plus you can swap it for basically any other sql database.
Post reply on HN