Manifest: A 1-file micro-back end

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, the access is public for the related action, thus anyone can manage records.

Aaaaaa!

Looks like it doesn't use locking, so running two instances will corrupt your 'database': https://github.com/mnfst/manifest/blob/master/packages/core/...

It feels a bit mean to write this, but whenever someone reinvents a database this is the first thing I look to gain some confidence the authors understood what they were getting into.

Probably best to stick to sqlite instead!

For a 1-file micro-backend this sure does have a lot of files and dependencies.

I'd love to see a frontend for this. Most CMSs are either tailored specifically for blogs or are complicated to set up. I've often wanted something like I guess Access or Filemaker Pro (if anyone remembers that) but with a modern UI and database.

Not for production use, mind you, just like, say I have a library of books or blu-rays and want to create a catalogue of them (with images, so a spreadsheet is a no-go). Being able to just bang out a single-file config and have an impromptu CRUD admin would be awesome.

Nice one, but it's really a pity that npm delivers so many deprecated warnings for such a new project

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?

Do I have to use emojis when introducing the entities? Are they used for anything?

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.

Could go all the way, and instead of a YAML, just do a literate Markdown, so you can embed the code and documentation, something like

    # My Pokemon backend
    
    ## Entities
    
    Let's start by defining my entities, I want to model Pokemons, so I'll just add this:
    ```yaml
    Entities:
    - Pokemons:
      - Bulbasaur...
    ```

I tried to search for "migration" in the docs but found nothing ? What do you do if you want to modify your schema?

Seems like Prisma + PostgREST but more tightly coupled. Neat idea, certainly seems useful for some small-scale projects.

Whenever I look at a new project on github, the first thing I do is try to get to the "core" of the source code, where the actual code that implements the basic feature actually lives.

One quality metric that I've noticed my brain has developed over the years is how deep in the directory hierarchy I have to dive to finally find some actual code amidst the mess of config files, readmes, yaml things, json metadata and various other crap that carry essentially no semantic.

It's been surprising how accurately this metric measures the overall quality of the project.

Large Java codebases are one of the worst offenders in that regard.

Unfortunately by this metric, and independent of anything else, this project does not fare well at all ... I give you my first attempt at actually finding the code, depth=

https://github.com/mnfst/manifest/blob/master/packages/core/...

depth=6 below project top dir (ignoring github-added crap)