1) put the “# Short syntax for string type.” comment in your docs on your homepage example. When I first saw the “price” element I thought it was a jsonb field or something
2) why the emojis? So confused. Are those an alternative to a “dash” for entities? Do I need todo those? Do they set the favicon for that rest page? Note: it looks like it messes up indentation alignment. If it’s trying to be cute, I would deprioritize it
3) a “curl” command example on the homepage would make it a bit easier to grok the value of how simple your backend is
4) where does the data get stored? SQLite? Duckdb?
Emojis caused a lot of ink to flow. I am a very visual person so I think emojis can help me when working (like icons of every app) but I noticed too that it changes the indentations, it can be disturbing. As of today they are just stripped from the title because it is just a PoC but they can be integrated in the admin panel later on.
Good guess the DB is SQLite! Fastest way to go up and running for users. It was a good choice for the proof-of-concept but we may need to change later.
I think you should apply this feedback because I agree that the emojis are pointless and pandering. You're creating a tool for (hopefully) technically minded folk, not children.
I’ve got at least that many. There are a lot of flat file formats I know as well as various databases. You can even do what I did in the first program I ever
wrote and use php code as a storage format. But obviously you should use Postgres.
Buddy and I are currently building an app on Pocketbase and are thoroughly enjoying it. I like your idea of starting from a config file rather than a UI.
Tip: it didn't take us long to need to tap into PB's hooks and "use as a framework" concept. Probably good to keep that front of mind.
Hey very useful app, I'll be watching this. I once wanted to set up backend apps during automated CI jobs in order to facilitate e2e tests and ended up making an utility kind of similar - but yours truly goes beyond.
With mock you can set up backend APIs completely from configuration files or even from command-line parameters - such as
$ mock serve --port 3000
--route 'say_hi/{name}'
--method GET
--response 'Hello world! My name is ${name}.'
--route "what_time_is_it"
--method GET
--exec 'printf "Now it is %s" $(date +"%H:%M") > $MOCK_RESPONSE_BODY'
I am a huge fan of the "Backend as a Service" segment (Supabase, Pocketbase, Appwrite, ...)
One of the big benefits that they all share is that they use a mainstream DB in the back (Supabase -> Postgres, Pocketbase -> SQLite) so you have a possible upgrade path if you need it - Is this the case here? I can't even easily tell what it uses as a DB, SQLite?
Also Authentication and more importantly Authorization are so prominent in the other BaaS I mentioned - completely missing here.
Not to disregard what this project is doing, but it might be better suited as a CMS that has some backend features... like for forms or appointment booking. Nevertheless, if I find a need for it in the future, I'll surely try it out.
(dev here) Backend-as-a-service products are very popular right now because they remove or simplify a lot of the backend complexity. It comes super handy for some projects.
Yes, the DB is SQLite. We chose it among others as it is file based and thus you get get up and running in seconds.
Authentication and authorization are key features, I agree. They were not integrated in the POC but they will come very soon. There actually is auth for the admin panel, I just need to standardize it for other entities.
I got it for the CMS use case, Manifest's aim is not to be a competitor of large frameworks that gives you the control of everything. We rather think that it will fit for another typology of projects. You can use it as a headless CMS, but there already is products like Strapi or Directus that get the job done. I am thinking more about projects with more "app" logic, but the next step is adding custom logic to it.
'your backend is just files' seems like an idea that is due
in the oss self-host world, countless things that are just file servers (with some sugar) are far more difficult to host than they should be: immich, nextcloud are examples. standard notes is an extreme example, its compose.yml is like the vhs tape from the ring
same in closed in-house backends; at best people store some static files in s3, but we use databases way too much
'your files contain entities' vs 'your files are entities' is a split; this project is the former but I kind of want the latter
also permissions is kind of the hard part as other posts have mentioned here
> However, their no-code approach generates awful code difficult to follow, making apps less reliable. Moreover, using a UI is slower than coding, especially now that AI assistants are here to help you.
I don't get this one, the sentence "their no-code approach generates awful code". If it's no-code, why do you care about code ?
Also, in what way are you relying on "coding" ? No information on this on the front page, to me it seems just like a config file only. Are you saying that the config only generates the boilerplate that the user will modify afterwards ? If that's the case, it's really not obvious.
Hi there ! Dev here, thanks for the feedback. Yes the example in the homepage (https://manifest.build/) generates the DB, Admin panel and REST API, we will adapt if it is not clear.
You asked an interesting question: "should you care about code quality if you use no-code tools?": As a developer, I would say definitely say yes because not understanding your own code (or your team's code) will soon or late lead to issues. If you work on a team with PR validations or similar, how can you validate your teammates' code if the code is unreadable ?
Congrats on shipping, this looks nice and well thought-out
One possible correction: the only code we generate for a user is either SQL migrations or TS types (if devs want to use the TS client). I’m not sure many would classify Supabase as NoCode, and we strongly recommend users use CI/CD development with our CLI and database migrations
Readit News
1) put the “# Short syntax for string type.” comment in your docs on your homepage example. When I first saw the “price” element I thought it was a jsonb field or something
2) why the emojis? So confused. Are those an alternative to a “dash” for entities? Do I need todo those? Do they set the favicon for that rest page? Note: it looks like it messes up indentation alignment. If it’s trying to be cute, I would deprioritize it
3) a “curl” command example on the homepage would make it a bit easier to grok the value of how simple your backend is
4) where does the data get stored? SQLite? Duckdb?
Emojis caused a lot of ink to flow. I am a very visual person so I think emojis can help me when working (like icons of every app) but I noticed too that it changes the indentations, it can be disturbing. As of today they are just stripped from the title because it is just a PoC but they can be integrated in the admin panel later on.
Good guess the DB is SQLite! Fastest way to go up and running for users. It was a good choice for the proof-of-concept but we may need to change later.
It's primarily headless CMS but it produces solid db schema and sensible rest API.
Entities can be defined in json or in UI.
You get OAuth, admin panel, plugin ecosystem.
Dead Comment
And now they can come up with 11!
__halt_compiler() is fantastic for this (mixing code + data). I've done it a few times.
Dead Comment
Buddy and I are currently building an app on Pocketbase and are thoroughly enjoying it. I like your idea of starting from a config file rather than a UI.
Tip: it didn't take us long to need to tap into PB's hooks and "use as a framework" concept. Probably good to keep that front of mind.
I love pocketbase it is a really enjoyable product, very neat. Manifest can be seen as a different approach, using code rather than UI.
Yes the "hook part" is tricky to consider as I am scared that I will have to trade-off some simplicity in order to cover more features/use cases.
https://dhuan.github.io/mock/
With mock you can set up backend APIs completely from configuration files or even from command-line parameters - such as
$ mock serve --port 3000 --route 'say_hi/{name}' --method GET --response 'Hello world! My name is ${name}.' --route "what_time_is_it" --method GET --exec 'printf "Now it is %s" $(date +"%H:%M") > $MOCK_RESPONSE_BODY'
One of the big benefits that they all share is that they use a mainstream DB in the back (Supabase -> Postgres, Pocketbase -> SQLite) so you have a possible upgrade path if you need it - Is this the case here? I can't even easily tell what it uses as a DB, SQLite?
Also Authentication and more importantly Authorization are so prominent in the other BaaS I mentioned - completely missing here.
Not to disregard what this project is doing, but it might be better suited as a CMS that has some backend features... like for forms or appointment booking. Nevertheless, if I find a need for it in the future, I'll surely try it out.
Yes, the DB is SQLite. We chose it among others as it is file based and thus you get get up and running in seconds.
Authentication and authorization are key features, I agree. They were not integrated in the POC but they will come very soon. There actually is auth for the admin panel, I just need to standardize it for other entities.
I got it for the CMS use case, Manifest's aim is not to be a competitor of large frameworks that gives you the control of everything. We rather think that it will fit for another typology of projects. You can use it as a headless CMS, but there already is products like Strapi or Directus that get the job done. I am thinking more about projects with more "app" logic, but the next step is adding custom logic to it.
in the oss self-host world, countless things that are just file servers (with some sugar) are far more difficult to host than they should be: immich, nextcloud are examples. standard notes is an extreme example, its compose.yml is like the vhs tape from the ring
same in closed in-house backends; at best people store some static files in s3, but we use databases way too much
'your files contain entities' vs 'your files are entities' is a split; this project is the former but I kind of want the latter
also permissions is kind of the hard part as other posts have mentioned here
but hope to see more stuff in this area
I don't get this one, the sentence "their no-code approach generates awful code". If it's no-code, why do you care about code ?
Also, in what way are you relying on "coding" ? No information on this on the front page, to me it seems just like a config file only. Are you saying that the config only generates the boilerplate that the user will modify afterwards ? If that's the case, it's really not obvious.
You asked an interesting question: "should you care about code quality if you use no-code tools?": As a developer, I would say definitely say yes because not understanding your own code (or your team's code) will soon or late lead to issues. If you work on a team with PR validations or similar, how can you validate your teammates' code if the code is unreadable ?
Congrats on shipping, this looks nice and well thought-out
One possible correction: the only code we generate for a user is either SQL migrations or TS types (if devs want to use the TS client). I’m not sure many would classify Supabase as NoCode, and we strongly recommend users use CI/CD development with our CLI and database migrations
https://supabase.com/docs/guides/cli/local-development#datab...