[HN Gopher] Manifest: A 1-file micro-back end
___________________________________________________________________
Manifest: A 1-file micro-back end
Author : andrewshadura
Score : 77 points
Date : 2025-03-18 10:15 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mubou wrote:
| 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.
| oliwary wrote:
| 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.
| SwiftyBug wrote:
| 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.
| stosssik wrote:
| Hi, Manifest founder here.
|
| PocketBase is great too. Manifest brings something
| different: it's fully code-based, so you can stay in your
| IDE, use AI tools like Copilot or Cursor to build your
| backend, and keep everything versioned in Git. It fits
| naturally into dev workflows, and we've got more coming
| soon on the AI side, both around AI and new features.
| shagrath wrote:
| Looks like there is an admin panel demo, but can't find the
| login/password
| d11z wrote:
| For the first example I had the same issue, but when I tried
| on another example it auto-populated the correct credentials.
| brunaxLorax wrote:
| Fixed ! thank you
| madduci wrote:
| Nice one, but it's really a pity that npm delivers so many
| deprecated warnings for such a new project
| darccio wrote:
| 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.
| brunaxLorax wrote:
| 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 !
| Joker_vD wrote:
| Do I have to use emojis when introducing the entities? Are they
| used for anything?
| finghin wrote:
| This was also my first thought, in perhaps more confused
| language than snarky, though.
| Joker_vD wrote:
| 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.
| mananaysiempre wrote:
| > SINGLE_EMOJI_COMMENT
|
| Bwahahaha. Sorry, I've just imagined the poor sod who has
| to implement this grammar and has to decide whether
| presentation selectors or (potentially unknown) ZWJ
| sequences or (potentially unknown) letter-pairs denoting
| flags count parts of as single emoji (in theory they do[1],
| but good luck figuring out what tables you need).
|
| > 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
|
| Side note: Swift's style likely comes from Objective-C,
| which in turn comes from Smalltalk.
|
| [1] https://www.unicode.org/reports/tr51/
| Joker_vD wrote:
| Yeah, I also have stopped for a second to consider what
| "SINGLE" should mean here but then realized I was
| thinking about Unicode grapheme clusters, and emoji
| sequences, and I should probably not do that before the
| dinner (or ever, really).
| WorldMaker wrote:
| > 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.
| balamatom wrote:
| NixOS, GNOME 47, Firefox, Ctrl+Shift+E opens devtools,
| Super+E does nothing. I have a flatpak app called "Smile"
| for entering emojis which always starts up very slowly -
| faster to open some webchat client and copy from its
| emoji picker...
| carlos-menezes wrote:
| fn + E also works on macOS.
| lexicality wrote:
| it appears not:
| https://github.com/mnfst/manifest/blob/master/packages/core/...
|
| It would be nice if the point of the emoji was explained
| anywhere in the docs but I couldn't find it anywhere
| joeblubaugh wrote:
| This is nifty - anybody seen examples of writing a server-side
| view layer with this?
| ludicrousdispla wrote:
| For a 1-file micro-backend this sure does have a lot of files and
| dependencies.
| brunaxLorax wrote:
| correct :)
| o1o1o1 wrote:
| Has anyone tested if this works on Cloudflare pages/workers?
|
| Just interested as I like the ease of use and free entry level,
| especially for small projects.
|
| Also: interesting idea, will have a look at it some time.
| lexicality wrote:
| 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!
| crooked-v wrote:
| That default by itself makes me want to run away from this
| project, fast, because it implies there are similar business-
| destroying footguns elsewhere.
| yakshaving_jgt wrote:
| If I need a 1-file backend, I can pretty easily do this in
| Haskell. I have more trust in this still working next year also.
| {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE
| QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-}
| {-# LANGUAGE TypeFamilies #-} import Yesod
| data App = App mkYesod "App" [parseRoutes| /
| HomeR GET |] instance Yesod App
| getHomeR :: Handler Html getHomeR = defaultLayout
| [whamlet|Look at me. Just one file.|] main :: IO ()
| main = warp 3000 App
| TheRealPomax wrote:
| Ah yes. But let's make sure form posts actually work eh? How
| hard could it be to add CSRF to our pa- oh no
| https://github.com/yesodweb/yesod-cookbook/blob/master/cookb...
| yakshaving_jgt wrote:
| Right. Add the middleware and use the yesod-form library.
| Pretty easy.
| pjerem wrote:
| I tried to search for "migration" in the docs but found nothing ?
| What do you do if you want to modify your schema?
| brunaxLorax wrote:
| Hello ! Manifest dev here, they are on the way ! There is a DB
| sync at the moment that does the job but we are going to
| implement the migrations soon :)
| pjerem wrote:
| Nice. Manifest looks really cool :)
| kevmo314 wrote:
| Seems like Prisma + PostgREST but more tightly coupled. Neat
| idea, certainly seems useful for some small-scale projects.
| treve wrote:
| 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!
| oulipo wrote:
| 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...
| ```
| rpier001 wrote:
| 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?
| crooked-v wrote:
| 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.
| m3kw9 wrote:
| Feature creep is gonna be the main issue
| ur-whale wrote:
| 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)
| elysianfields wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-21 23:01 UTC)