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
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.
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.
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.
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.
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.
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?..
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.
> 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.
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...
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.
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).
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...
```
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 :)
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=
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 !
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
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!
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.
That default by itself makes me want to run away from this project, fast, because it implies there are similar business-destroying footguns elsewhere.
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.
correct :)
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.
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.
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.
Looks like there is an admin panel demo, but can't find the login/password
For the first example I had the same issue, but when I tried on another example it auto-populated the correct credentials.
Fixed ! thank you
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?
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.
Do I have to use emojis when introducing the entities? Are they used for anything?
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
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?..
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.
> 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.
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...
fn + E also works on macOS.
> 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/
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).
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
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
I tried to search for "migration" in the docs but found nothing ? What do you do if you want to modify your schema?
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 :)
Nice. Manifest looks really cool :)
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)
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.
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.
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.
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...
Right. Add the middleware and use the yesod-form library. Pretty easy.
This is nifty - anybody seen examples of writing a server-side view layer with this?
Is there anything like this or pocketbase for MongoDB?
Feature creep is gonna be the main issue