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

by brunaxLorax • 2 years ago

102 73 2 years ago

tomrod• 2 years ago

Neat.

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!

lyu07282• 2 years ago

those other 10 people don't know what they are talking about!

kayodelycaon• 2 years ago

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.

erhaetherth• 2 years ago

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.

oschvr• 2 years ago

Obligatory xkcd https://xkcd.com/927

tomhallett• 2 years ago

Thoughts:

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?

brunaxLorax17• 2 years ago

Hello, dev here, thanks for your feedback.

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.

marziply• 2 years ago

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.

pluc• 2 years ago

These abstractions are great but are contributing to brutal de-skilling.

mike-the-brain• 2 years ago

What do you mean?

ghusto• 2 years ago

My guess is the lowering of the bar. It's a good and bad thing, but mostly bad in my opinion.

isoprophlex2• 2 years ago

Javascript YAML warriors not understanding what a computer actually is.

Also https://noyaml.com/

pavel_lishin2• 2 years ago

Maybe, but they're selling a backend-as-a-service - it's like arguing that taxis are contributing to de-skilling because using them doesn't teach you how to change a brake pad.

TheRoque2• 2 years ago

Seems like a weird take. To me it's just another abstraction level, could be useful for quick PoC or hobby website, could be unusable for a backend that wants larger features. Either way, where do you draw the line between useful abstraction and "de-skilling" ? Like, should I craft by hand all my docker containers, and is the quick config file "deskilling" me ?

philipwhiuk• 2 years ago

Said the assembly programmer to the C programmer.

SahAssar2• 2 years ago

Do you mean simple or easy? It seems like you actually mean to say easy.

brunaxLorax17• 2 years ago

What is the difference between a simple backend and an easy backend ? Not sure that I pickup the nuance

meiraleal2• 2 years ago

Easy to use is difficult to extend beyond the framework capability. Simple is easier to.

sodapopcan• 2 years ago

“It can be very difficult to come up with a simple solution.”

drewcoo• 2 years ago

Not sure that I pickup the nuance

If the use of "pickup" instead of "pick up" was intentional, that's hilarious.

SahAssar2• 2 years ago

A simple system is built so that not many parts are intertwined and hard to understand how it is built.

A easy system might be very complexly built, but presents and easy interface for you to use. If complex it would be hard to understand how it is built and how to modify.

Basically simple describes how the system is built, while easy describes how much you need to know to use it.

They are orthogonal, so a system can be both complex and easy, both simple and hard.

See https://www.youtube.com/watch?v=SxdOUGdseq4

TheRoque2• 2 years ago

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.

brunaxLorax17• 2 years ago

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 ?

kiwicopple• 2 years ago

(Supabase team member)

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

mariopt2• 2 years ago

Any plan to plug this into an LLM and generate a backend in virtually any stack/platform?

The idea seems cool, provided it supports more features like authentication type, generic middlewares, rate limiting, etc.

brunaxLorax17• 2 years ago

Definitely in my mind! Actually with Copilot you already have pretty good suggestions on autocomplete or with a prompt. But I am not sure of what would be an appropriate UI for a full-AI backend generator.

mariopt2• 2 years ago

Even a "direct" mapping between yaml and PocketBase/SupaBase/Firebase would be helpful, LLMs currently hallucinate too much.

Another bit worth adding to the yaml config on a collection basis: seed data

joneholland• 2 years ago

I can’t think of a single time where my backend was literally just a crud api over entities. These toys fall apart beyond a hello world app.

No validation, no authorization, no authentication, no property level permission, no events, no auditing… the list of what is actually needed for a real application goes on.

brunaxLorax17• 2 years ago

Hello ! Manifest dev here

This is a proof of concept only so it sticks to a simple CRUD set of endpoints.

Some of the features that you evoke are already on the pipe (Auth, permissions ABAC/RBAC...) but obviously it will still have limitations for more complex use cases...

I am thinking about a nice hook system to add this kind of logic somewhere else like on edge functions or external APIs. The point is to keep things simple and allow more use-cases without too much trade-off. Hard choices.

chrsig• 2 years ago

I really appreciate the simplicity of the DSL presented.

I'm curious how you see the project evolving as you add those things. How do you see it differentiating itself from rails or django?

perrygeo• 2 years ago

This is absolutely true. The magical "write a model, get an app" approach is so tempting. But it's focusing on the wrong problem - optimizing for the initial tutorial experience, not the lifecycle of a production app.

That initial scaffolding takes, what, an hour or two? Getting that down to a minute or two is not a high priority, considering 99.9% of the lifecycle of the app is dominated afterwards by what that structure allows. Coding yourself into a corner on purpose, just to save a few minutes on launch, is a strange tradeoff.

I know because I've made that tradeoff dozens of times and cursed myself every time. I built a web framework that did auto UI based on Django models, postgres and jquery. It was active 2010-2014 and I built dozens of production apps with it. That initial "wow" factor of going from a model in your head to a full user interface is very compelling! I did live demos with clients where we'd code up a model and launch a site in real time. Cool, right! The problem was the structure only fit certain types of applications and as we stretched it into adjacent domains, we had to break it down and effectively "eject" from the framework, making each instance a custom app - which is what we should have started anyways.

razodactyl• 2 years ago

The "eject" paradigm never sat well with me.

If it's there as an option it means eventually it will be used and there's usually no easy way to go back...

The unsettling part is wondering if you made the right choice at that point which usually is a non-problem but the point of a framework is to establish convention and order.

brunaxLorax17• 2 years ago

Hi perrygeo, Manifest dev here, I totally agree with you: quick starts can be harmful in the middle/long term so most of the times I would probably accept to invest more time in the beginning building something flexible.

However, you are talking here as a senior/expert developer - as you were already coding in 2010 ;) - but junior devs OR frontend devs may not be able to create that Django+DB+API app so easily. That is an important point to consider.

jt2190• 2 years ago

Rather that dismiss this Proof-of-Concept as a “toy”, I think it’s useful to step back and ask whether all of those things (validation, authorization, authentication, auditing) require lots and lots of code to express, or if they could also fit into a single YAML file approach.

brunaxLorax17• 2 years ago

Stay tuned :)

lionkor• 2 years ago

Developer discovers he can type emojis on his PC

sigmonsays• 2 years ago

do we really need more yaml?

This is insane to me.

typpo• 2 years ago

Care to explain why you think so?

Zenzero• 2 years ago

It's a horribly restrictive syntax. Instead of allowing modularity and flexibility in how I structure parts of the config, I'm instead locked into this indentation-obsessed and sparse file that forces me to learn the exact mental model of whoever designed the yaml.

Almost nobody uses explicit typing in yaml.

The fact you need features like folding strings or chomp characters is a symptom that yaml is trying to work around limitations that shouldn't be there to begin with.

meiraleal2• 2 years ago

There's a typo in "Define your data structure, get a business-ready backend will essential features"

I guess you meant with not will?

brunaxLorax17• 2 years ago

Oops... Thanks !

gedy• 2 years ago

Dev: this is cool and thanks for sharing, don't let the complainers discourage you. They mostly share nothing themselves.

alextheterrible• 2 years ago

Nice. I'll be watching this.

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.

brunaxLorax17• 2 years ago

Thank you !

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.

awinter-py• 2 years ago

'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

but hope to see more stuff in this area

skinner927• 2 years ago

Properties should be an object instead of an array. It makes key collisions more obvious, makes it easier to find keys, and IMO ends up looking cleaner.

65• 2 years ago

Cool. But how would this be advantageous over a traditional ORM like Prisma?

I use Prisma and I like that I can define my tables in a simple file, and also use it with Express to add some middleware or auth or various backend things if I want. This API seems pretty similar to Prisma as well.

flessner• 2 years ago

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.

brunaxLorax17• 2 years ago

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

robbiejs• 2 years ago

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?

morbicer2• 2 years ago

Looks exactly like https://knexjs.org/ but I bet there are query builders / ORMs with same syntax

brunaxLorax17• 2 years ago

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.

dhuan_• 2 years ago

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.

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'

brunaxLorax17• 2 years ago

Looks really nice !

slooonz2• 2 years ago

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 ?

slooonz2• 2 years ago

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 also generate migrations (in our case, knex migrations). It’s harder and less reliable to go the other way, starting from current database schema + current description to migration.

brunaxLorax17• 2 years ago

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 ?

jslakro• 2 years ago

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

brunaxLorax17• 2 years ago

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.

emrah• 2 years ago

Example healthcare-app shows only the data(base) structure. How does one define the business logic?

brunaxLorax17• 2 years ago

This is a key question for real-life use cases. YAML is a markup language so you cannot program and add logic in it.

I think about having a set of hooks that trigger the code logic hosted somewhere. Language-agnostic / serverless, that kind of stuff maybe... Any ideas ?

morbicer2• 2 years ago

https://strapi.io/ does this and much more.

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.

Edd1CC2• 2 years ago

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

brunaxLorax17• 2 years ago

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

Edd1CC2• 2 years ago

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.

jaredliu233• 2 years ago

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.

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

Related Stories