Live data from Hacker News

Manifest: A 1-file micro-back end

github.com

41–49 of 49 posts

Re: Manifest: A 1-file micro-back end

#41

I wonder if anybody has used PostgREST ( https://docs.postgrest.org/en/v12/ ) and explored this could provide a comparison. They seem largely similar with PostgREST having some feature advantages associated with being built on Postgres. Where does Manifest have an advantage?

The most obvious point of comparison is that this project doesn't actually use a real database engine, so you're basically guaranteed poor performance with large data sets and have no way to do fine-tuned indexing/joins/filtering.

Re: Manifest: A 1-file micro-back end

#42
I want to like this, but there are a couple of red flags. One is using SHA-3 to hash and store the passwords.

You shouldn't use such a hashing function for password storage. Calculating password hashes should be computationally expensive, not cheap.

Nuff said, overall it looks like a cool project to toy around with, but not something you should be using to build a product with yet.

Re: Manifest: A 1-file micro-back end

#43

Earlier quoted context omitted.

Um, "snarky"? How do I ask "is this last element optional, and does it have to be an emoji?" without snark? And it's the most egregious (in the "glaring" sense, not "outlandishly awful") things about the example, you don't often see emojis being a part config/programming languages outside of embedded strings, everything else is pretty self-explanatory dialect of YAML. The use of emojis looks quite similar to the way…

> 2) a tad too difficult to enter unless you're on a mobile keyboard Windows and macOS both have great on-screen keyboards (OSK)/input method editor (IME) for emoji. Many (most?) Linux desktop environments also provide one. On Windows it is Win+. or Win+; and on macOS it is Ctrl+Cmd+Space and on Gnome it is Ctrl+Shift+E,Space or Super+E.

fn + E also works on macOS.

Re: Manifest: A 1-file micro-back end

#44

I want to like this, but there are a couple of red flags. One is using SHA-3 to hash and store the passwords. You shouldn't use such a hashing function for password storage. Calculating password hashes should be computationally expensive, not cheap. Nuff said, overall it looks like a cool project to toy around with, but not something you should be using to build a product with yet.

I think the docs haven't been updated - there was a commit made 3 weeks ago where they replace SHA3 with bcrypt

Re: Manifest: A 1-file micro-back end

#45

The lack of object level permissions is a really spectacular footgun and the fact that it's not even on the roadmap is concerning. Want to allow users to set their own name? I hope you're OK with any user being able to update any field of any other user too! Added a new entry and didn't specify a policy for every single available action? They default to unauthenticated access! > If no policy is specified for a rule,…

Something that follows this pattern of a single file backend is PocketBase. I’ve used it on personal projects and, while not being 1.0 yet, it’s growing quickly

Re: Manifest: A 1-file micro-back end

#46

I want to like this, but there are a couple of red flags. One is using SHA-3 to hash and store the passwords. You shouldn't use such a hashing function for password storage. Calculating password hashes should be computationally expensive, not cheap. Nuff said, overall it looks like a cool project to toy around with, but not something you should be using to build a product with yet.

I think the docs haven't been updated - there was a commit made 3 weeks ago where they replace SHA3 with bcrypt

Good catch! You're absolutely right. We switched from SHA3 to bcrypt a few weeks ago, but forgot to update the docs.

Thanks a lot for pointing it out. I just created an issue to track this, and we’ll fix it shortly: https://github.com/mnfst/manifest/issues/361

Re: Manifest: A 1-file micro-back end

#47

The lack of object level permissions is a really spectacular footgun and the fact that it's not even on the roadmap is concerning. Want to allow users to set their own name? I hope you're OK with any user being able to update any field of any other user too! Added a new entry and didn't specify a policy for every single available action? They default to unauthenticated access! > If no policy is specified for a rule,…

Something that follows this pattern of a single file backend is PocketBase. I’ve used it on personal projects and, while not being 1.0 yet, it’s growing quickly

Pocketbase is amazing! Going through Manifest's docs, I kept thinking, "but I'd rather use PocketBase"

pocketbase has helped me get a few boutique websites and systems out so far with incredible speed and a joy that I rarely feel near web these days.

Though I should remain open-minded. An even simpler backend would be nicer (maybe). Also the AI-friendly approach looks promising.

Re: Manifest: A 1-file micro-back end

#49
post #6

The idea is interesting. I wonder what makes it AI-friendly. It isn't explained on the repository or the website, but I can imagine that the YAML-based DSL could be the reason.

Hello, Manifest dev here, most backend-as-a-services rely on an UI and it's harder for AIs. In comparison, Manifest high-level DSL is really understandable by gen AIs. It's also very easy to validate in comparison to bootstrap frameworks that come with a lot of files. But you are right we should explain it somewhere !

Thanks for the reply! It makes sense.
Post reply on HN