Manifest: A 1-file micro-back end

#1

Post by andrewshadura » Tue, Mar 18, 2025, 10:15 AM UTC

Manifest: A 1-file micro-back end
github.com

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

#2

Post by mubou » Tue, Mar 18, 2025, 10:28 AM UTC

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.

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

#3

Post by madduci » Tue, Mar 18, 2025, 1:51 PM UTC

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

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

#4

Post by [deleted] » Fri, Mar 21, 2025, 10:10 AM UTC

[deleted]

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

#5

Post by oliwary » Fri, Mar 21, 2025, 10:52 AM UTC

mubou wrote: post #2

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). Bei…

Are you aware of pocketbase? https://pocketbase.io/ I think it could work for your usecase, even though its generally focused on being a backend. I have had a very nice experience.

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

#6

Post by darccio » Fri, Mar 21, 2025, 11:31 AM UTC

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.

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

#7

Post by SwiftyBug » Fri, Mar 21, 2025, 12:10 PM UTC

oliwary wrote: post #5

mubou wrote: post #2

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). Bei…

Are you aware of pocketbase? https://pocketbase.io/ I think it could work for your usecase, even though its generally focused on being a backend. I have had a very nice experience.

I love Pocketbase! In particular using it as framework. I use it as CMS and auth system and add my custom application routes to the server. It's very easy to seamlessly leverage all its infrastructure.

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

#8

Post by Joker_vD » Fri, Mar 21, 2025, 12:13 PM UTC

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

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

#9

Post by finghin » Fri, Mar 21, 2025, 12:43 PM UTC

Joker_vD wrote: post #8

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

This was also my first thought, in perhaps more confused language than snarky, though.

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

#10

Post by Joker_vD » Fri, Mar 21, 2025, 1:12 PM UTC

finghin wrote: post #9

Joker_vD wrote: post #8

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

This was also my first thought, in perhaps more confused language than snarky, though.

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 parameter/argument labels are introduced in Swift: in the function signature, you use two names (separated by a space) before the colon, instead of one. So, is this second part a shorthand alternative name, or just a visual comment, or?..

    ENTITY_DECLARATION  ::=  NAME [SPACE COMMENT] COLON ...

    ENTITY_DECLARATION  ::=  NAME [SPACE SINGLE_EMOJI_COMMENT] COLON ...

    ENTITY_DECLARATION  ::=  NAME1 [SPACE NAME2] COLON ...

    ENTITY_DECLARATION  ::=  REGULAR_NAME [SPACE EMOJI_NAME] COLON ...

What is it?

Don't get me wrong, I am not opposed to emojis on principle, they are just 1) a tad too outstanding in the text for my taste, 2) a tad too difficult to enter unless you're on a mobile keyboard, 3) I personally would rather not edit program source code/configs on mobile.