Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Soul: A SQLite REST and Realtime Server

thevahidal.github.io

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Soul: A SQLite REST and Realtime Server

#31

Post by mekoka »

ThinkBeat wrote: post #28

I am not sure what Realtime means here. But if it means something close to what I used to [1], then REST is a horrible idea. Javascript is not a good idea either. [1] " Real-time computing (RTC) is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system response.[1] Real-time programs must guarantee response within specified time constraints, o…

Firebase gives this definition:

> The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Re: Soul: A SQLite REST and Realtime Server

#32

Post by geenat »

SQLite wrote: post #26
brigadier132 wrote: post #6

Earlier quoted context omitted.

Frankly, you thought wrong. The whole point of sqlite was to build a database for naval vessels. Aside from that, given it's open source, the "point" of it doesn't really matter anymore.

That is inaccurate. Ginko's statement is closer to truth. I was inspired to write SQLite while working with Informix on DDG-79 and I saw how useful an embedded database would be in some situations, compared to a client/server solution. So I went off and wrote SQLite on my own, while the development contract was on hiatus. There was never a request for SQLite or anything like it coming from the the navy (or more preci…

Thank you for your work on SQLite and Fossil !! They are amazing.

Any chance of WAL2 being included as a standard journal_mode option in the near future? ..or BEGIN CONCURRENT ? :)

Re: Soul: A SQLite REST and Realtime Server

#33

Post by diggan »

geenat wrote: post #17

No benchmark = no download. Plenty of these SQLite web front ends exist, including more enticing single static binaries in go, and they are always far too slow to use in anything but toy projects. Should be standard to bench against a standard SQLite integration (on modern cpu with nvme). Even PocketBase, for as nice as the UI is, an order of magnitude slower than SQLite directly. Here's some rough numbers I've found…

> and they are always far too slow to use in anything but toy projects

Or, not every project need the absolute best performance, sometimes good enough is simply good enough?

Re: Soul: A SQLite REST and Realtime Server

#34

Post by diggan »

ThinkBeat wrote: post #28

I am not sure what Realtime means here. But if it means something close to what I used to [1], then REST is a horrible idea. Javascript is not a good idea either. [1] " Real-time computing (RTC) is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system response.[1] Real-time programs must guarantee response within specified time constraints, o…

According to that definition, if your specific time constraints are "between 10ms and 1000ms", wouldn't HTTP be sufficient?

Seems like your argument for if this is "realtime" or not depends on parameters not specific by either you or the project.

Re: Soul: A SQLite REST and Realtime Server

#35

Post by diggan »

brodo wrote: post #27

REST mentioned! https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

You can either play along with words changing meaning, or you can die on this almost meaningless hills.

Signed, with my crypto keys while hacking on side-projects.

(I'm also in the camp of "I don't love it when words change literal meaning" but I've also realized there is literally nothing I can do to stop it)

Re: Soul: A SQLite REST and Realtime Server

#38

Post by hultner »

thinkxl wrote: post #37

it feels more like postgrest [1] than pocketbase [2]. -- 1: https://postgrest.org/ 2: https://pocketbase.io/

From what I can see this doesn't contain any kind of permission model, or authentication. At least what I could see in the documentation. I would say that RLS is one of the big killer features for postgrest which makes it so great for rapid prototyping something that's actually useful when exposed to the open internet.

Re: Soul: A SQLite REST and Realtime Server

#39

Post by hultner »

twsted wrote: post #22

Nice and a possible alternative to the very polished PocketBase. I'm working on something similar for PostgreSQL [0], with an API compatible with the excellent PostgREST [1]. I believe these tools can be of great utility in many projects and represent a generalization compared to the dedicated middleware that was popular a few years ago. Companies like Supabase are demonstrating this. [0] https://github.com/sted/smoo…

Cool! Are you doing this mostly as a fun exercise or do you have a plan to provide something postgrest does not in the future?

Re: Soul: A SQLite REST and Realtime Server

#40

Post by b-lee »

randomwebdev wrote: post #25
geenat wrote: post #17

No benchmark = no download. Plenty of these SQLite web front ends exist, including more enticing single static binaries in go, and they are always far too slow to use in anything but toy projects. Should be standard to bench against a standard SQLite integration (on modern cpu with nvme). Even PocketBase, for as nice as the UI is, an order of magnitude slower than SQLite directly. Here's some rough numbers I've found…

Hi, PocketBase author here. Keep in mind that PocketBase do a lot more than just executing a raw DB query. We perform data validation, normalization, serialization, enriching, auto fail-retry to handle additional SQLITE_BUSY errors, etc. All of this comes with some cost and will always have an effect when doing microbenchmarks like this. The performance would also depend on what version of PocketBase did you try (bef…

Man, thanks for building PocketBase. It's very pleasant to use!
Post reply on HN