Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I built a backend so simple that it fits in a YAML file

manifest.build

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Show HN: I built a backend so simple that it fits in a YAML file

#71

Post by brunaxLorax »

robbiejs wrote: post #50

Cool project, it speaks to me! And I dig the emojis. I like the chain able queries, like: ``` const cats = await manifest .from('cats') .where('breed = siamese') .andWhere('active = true') .andWhere('birthDate > 2020-01-01') .find() ``` What is it inspired by?

Mmmm... It comes from ORMs in general I guess. I appreciate the effort of some ORMs to get a nice syntax, making it feel like natural language. I guess Laravel Eloquent was my first crush in my PHP days. Then modern ORMs like TypeORM and Prisma do an excellent job IMO.

I also like the idea of transposing ORM-style queries in the browser to abstract the whole API response-request part.

Re: Show HN: I built a backend so simple that it fits in a YAML file

#72

Post by erhaetherth »

kayodelycaon wrote: post #25
pavel_lishin wrote: post #3

> If you ask 10 backend developers what you should use for your app’s backend, they will probably come up with 10 different stacks. And now they can come up with 11!

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.

> You can even do what I did in the first program I ever wrote and use php code as a storage format.

__halt_compiler() is fantastic for this (mixing code + data). I've done it a few times.

Re: Show HN: I built a backend so simple that it fits in a YAML file

#73

Post by brunaxLorax »

jslakro wrote: post #57

This seems JSONServer https://github.com/typicode/json-server but in YAML

Yes there is a lot of similarities in the foundation and the syntax. The end goal is different though as Manifest aims to be a production-ready product: it already comes with the admin panel and will soon include features like authentication, authorization and so on.

Re: Show HN: I built a backend so simple that it fits in a YAML file

#74

Post by jaredliu233 »

This project looks very interesting, especially the idea of fitting the entire backend into a YAML file. However, I'm concerned that the lack of support for complex business logic might limit its practicality. Perhaps you could consider adding some extensible hook mechanisms to handle more complex requirements.

Re: Show HN: I built a backend so simple that it fits in a YAML file

#75

Post by brunaxLorax »

Edd1CC wrote: post #68

How will you add rules? For example a doctor can only have 100 active patients

I am thinking about having some hooks for the custom logic. I like the entity listeners/subscribers from typeORM: https://orkhan.gitbook.io/typeorm/docs/listeners-and-subscri... but I the end I guess we would probably need some functions stored somewhere. Not sure how to implement that though

Re: Show HN: I built a backend so simple that it fits in a YAML file

#78

Post by brunaxLorax »

slooonz wrote: post #56
slooonz wrote: post #55

I have made a similar solution in-house. I kinda agree with the YAML nay-sayers. I settled on KDL instead as the description language ( https://kdl.dev/ ) ; maybe give it a try ?

Also, you should consider migrations to be the first-class citizen and entities to be derived on it. On our system, we have migration "create-users-table" { create-table "users" { column "id" "number" dbtype="increments" } } migration "add-user-last-device" { alter-table "users" { column "last_device" "string" } } This implicitly defines an "User" entity which has two fields, "id" and "lastDevice". But now we can als…

Migrations are a tricky point I agree. In your system, do you keep your original model files as they were at the beginning or do you change them too ?

Re: Show HN: I built a backend so simple that it fits in a YAML file

#79

Post by brunaxLorax »

flessner wrote: post #48

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 p…

(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.

Re: Show HN: I built a backend so simple that it fits in a YAML file

#80

Post by Edd1CC »

brunaxLorax wrote: post #75
Edd1CC wrote: post #68

How will you add rules? For example a doctor can only have 100 active patients

I am thinking about having some hooks for the custom logic. I like the entity listeners/subscribers from typeORM: https://orkhan.gitbook.io/typeorm/docs/listeners-and-subscri... but I the end I guess we would probably need some functions stored somewhere. Not sure how to implement that though

There's probably some low-hanging concepts of rules, like A can have X of B. I guess if you work out what four or five of the most common rules are you could build just for them and have the rules in the YAML, as they'll be enough for the tools using backends like this.

Limits would be a good name I think for that rule.

Post reply on HN