xyheme

directory tree is not as easy to view and edit as JSON.

One big JSON file is harder.

I am not fancy, and the aim is to simply use file system as database.

Not fancy stuff like "database as file system as database".

Me and a lot of linux user friends are using btrfs.

I should thought about that.

Isn't WinFS the reverse of "file system as database"?

Which is "database as file system".

That all can be achieved by using file system as database.

Not even complicated to implement.

See couchDB for how to handle "what if two people are editing a file at once".

JSON is there for human to read a record of data by group.

I think it is only good to use directory as data table to store JSON data files, but not for JSON data properties.

Inode limits depends on the file system you use.

I am using Btrfs.

Btrfs inode limits is in a whole different league (whereas ext4's inodes are allocated at filesystem creation time and cannot be resized after creation, typically at 1-2 million, with a hard limit of 4 billion, btrfs's inodes are dynamically allocated as needed, and the hard limit is 2^64, around 18.4 quintillion.

> -- https://unix.stackexchange.com/questions/18388/what-are-the-...

> The main reason is that I can use a variety of tools to view and manipulate files.

This is also the reason I am researching this old "What if" problem.

Because I think comparing to some version of MySQL or PostgreSQL, files are stable, open and timeless.

Thanks for the reminder about meaningful pathnames :)

Thanks for the link.

I read it, and I think it describes bad ways of using file system, but there are also good ways.

Just like there are bad ways of using SQL databases, and there are also NoSQL, and bad ways of using NoSQL databases.

So that I can use subdirectory to model "has many" relationship, like "a user has many projects".

I think, unless column-oriented database is used, "one file per row" is similar to normal row-oriented database.

Maybe there are some benchmarks in the past.

Why not use one JSON file as one record of data, and use pathname as primary ID?

@jqpabc123

I agree.

We (developers) should also design tools to address the need of small scale web apps.

Maybe, we do not even need some general tools to use file system as database, just speak this method more often.

Thanks, I now learn double content s have this effect on SEO :)

Sorry about the mis-deleting. It was not due to the criticism here. I can learn a lot from the feedback.

I was migrating all my websites and repo out of vercel (to use this tool), during which I mis-deleted this repo. It is back now.

Some background story here.

I am a little frontend programmer. Years ago, I worked in a company where the team built a complicated CI system. If a frontend programmers want to share some internal demo projects, he/she must go through this complicated CI pipeline, and get a internal subdomain at the end of the console log output of the last page of the CI building stages.

It sucks.

In my team, we all know vercel and netlify, but the internal demo projects can not use them.

Thus, my aim is to build a open-source mini vercel and netlify alternative.

I will build some command line tools like `vercel deploy`.

For my personal use, and for my future teams (where everyone is both Dev and Ops).

This `x-server` is a starting point.

More Show HNs will come :)

------

Some of my projects will feel stupid to you, please criticize them hard.

I will learn.

Hi, it's you again :)

My aim is to build a open-source mini vercel and netlify alternative.

`x-server` is just a starting point.

I have even more "evil" projects, like "using file system as database", I will leave that for another Show HN :) :) :)

I enjoy the criticism, I think I can learn things from them.

So far, feedback here are helpful to me.

Sorry about the mis-deleting.

Sorry about that, I was migrating my websites and repo out of vercel (to use this tool), during which I deleted a lot of outdated github repos.

I thinks I accidently deleted this repo.

Now it is back: https://github.com/xieyuheng/x-server

> ... when it comes to node rearranges, which, frankly, I didn't quite get.

I removed the syntax of rearrange, and added a new builtin `@spread`, I hope it is less confusing now :)

Caddy looks very complicated.

At that time, feel free to open issue at: https://github.com/cicada-lang/inet/issues

I will not miss an issue there :)

If you use telegram, welcome to join https://t.me/CicadaLanguage