Thanks, the "Top Comments" is sourced from the "kids" field of the "items" endpoint. As the API docs (https://github.com/HackerNews/API?tab=readme-ov-file#items) says, it is "in ranked display order" so I just used it to sort the top comments.
yes, the keywords search is using full-text searching and it is not efficient so I hardcoded them. Will consider switch to use embedding, that will be more efficient and accurate, also can support custom keywords search. Thanks for your advice.
| At the end of the day, are these just FDWs that run on top of any Postgres instance?
Yes, the FDWs developed by Wrappers can be used on any Postgres db.
| Do I have to run Supabase to take advantage of the FDWs created through this framework?
No, you don't need to. Those are just normal FDWs can be used on any Postgres db.
| Is there a generic JDBC/SQL/etc FDW for any SQL based database like Snowflake, Oracle, etc?
The Snowflake FDW isn't developed yet, the example is just for concept demo. It has ClickHouse and BigQuery FDWs although they are not JDBC based. Generic JDBC FDW will need JVM embedded so it is not in plan at this moment.
Our price model based on database usage which includes db egress, so we use it to monitor db egress traffic just for now. We are all db fans and we like put things into db, so all the following processes, like searching, tracking, analysis and etc., are a lot easier.
Yes, you need root to grant capture permission to Postgres, but Postgres doesn't need to run as root. The main purpose is to easily ingest network traffic data into Postgres for further process. Yes we can use tcpdump to do the same thing, but that needs another tool to load data into Postgres.
I have spent some time to search for a tool that can ingest realtime network traffic data to Postgres but have no luck, so I developed this extension and used it internally in our team. Thanks Rust, pgx and libpcap, the development journey is easy and enjoyable.
Would like to hear more feedbacks. Any contributions, feature requests, bug report or ideas are welcomed.
I am building an encrypted file system that runs inside application (https://github.com/zboxfs/zbox). It focus on security, privacy and reliability. The interesting part is it can utilize different storage, such as memory, OS file system, RDBMS and object store. I learned a lot and enjoyed working on this project.
Totally agree. To make file system crash-proof you really need an ACID compatible underlying storage layer or implement it inside the file system itself. In fact, file system and database are quite similar in case of atomicity and consistency. If an embedded ACID component is too heavy, utilizing a reliable database as storage, for example sqlite, might be a good idea. That’s exactly what I did in ZboxFS (https://github.com/zboxfs/zbox) which can use sqlite as a underlying storage to achieve ACID compatible behaviours.
I am using Rust building a privacy focused in-app file system ZboxFS(https://github.com/zboxfs/zbox). The fun part is not only joyfulness Rust bring to me, but also learned a lot about cryptography, file system, transaction control and many more interesting areas.
Database and filesystem share a lot similarity, but still have their own characteristics. To use database as a back-end for filesystem has some benefits, such as reliable persistence, ACID transaction and etc. It reduces complexity to achieve durable storage which filesystem should deal with.
Many filesystems are able to use DB as back-end, I also made a filesystem ZboxFS (https://github.com/zboxfs/zbox) which can also use sqlite as underlying storage.