[HN Gopher] Show HN: I built a backend so simple that it fits in...
___________________________________________________________________
Show HN: I built a backend so simple that it fits in a YAML file
Author : brunaxLorax
Score : 41 points
Date : 2024-06-01 11:24 UTC (11 hours ago)
(HTM) web link (manifest.build)
(TXT) w3m dump (manifest.build)
| tomrod wrote:
| Neat.
| pavel_lishin wrote:
| > _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 wrote:
| those other 10 people don't know what they are talking about!
| kayodelycaon wrote:
| 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.
| tomhallett wrote:
| 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?
| brunaxLorax wrote:
| 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.
| pluc wrote:
| These abstractions are great but are contributing to brutal de-
| skilling.
| mike-the-brain wrote:
| What do you mean?
| ghusto wrote:
| My guess is the lowering of the bar. It's a good and bad
| thing, but mostly bad in my opinion.
| isoprophlex wrote:
| Javascript YAML warriors not understanding what a computer
| actually is.
|
| Also https://noyaml.com/
| kreeben wrote:
| Out of spite and because I could, I deleted all the text in
| the noyaml site and then clicked "save". Sorry if you were
| too slow to read it. Might find it in the waybackmachine?
| davidmurdoch wrote:
| I don't understand the joke
| IshKebab wrote:
| If you don't allow anyone to stop at a certain level of
| abstraction then nobody knows "what a computer actually
| is". I'd wager you don't know all the details of your
| computer's branch predictor and reorder buffer and
| whatnot... and if you do do you know about rebuffering and
| setup times and ...
|
| Don't gatekeep.
| isoprophlex wrote:
| Even though I immediately see how my comment could be
| considered to be gatekeeping, I won't apologize for it,
| as I mostly mean to explain what I think was the meaning
| of the grandparent: that writing YAML for a living means
| you're a business user, not a software engineer. Just as
| you'd have to squint real hard to label a pro excel user
| as a software engineer. If everything is easy, you're not
| learning transferable skills.
|
| And I hate YAML with a passion, too, an opinion which I
| feel I'm entitled to.
| pavel_lishin wrote:
| 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.
| TheRoque wrote:
| 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 wrote:
| Said the assembly programmer to the C programmer.
| SahAssar wrote:
| Do you mean simple or easy? It seems like you actually mean to
| say easy.
| brunaxLorax wrote:
| What is the difference between a simple backend and an easy
| backend ? Not sure that I pickup the nuance
| meiraleal wrote:
| Easy to use is difficult to extend beyond the framework
| capability. Simple is easier to.
| sodapopcan wrote:
| "It can be very difficult to come up with a simple solution."
| drewcoo wrote:
| > Not sure that I pickup the nuance
|
| If the use of "pickup" instead of "pick up" was intentional,
| that's hilarious.
| SahAssar wrote:
| 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
| TheRoque wrote:
| > 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.
| brunaxLorax wrote:
| 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 ?
| mariopt wrote:
| 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.
| brunaxLorax wrote:
| 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.
| mariopt wrote:
| 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 wrote:
| 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.
| brunaxLorax wrote:
| 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 wrote:
| 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?
| brunaxLorax wrote:
| Thank you! We want to make it faster for devs to go from
| idea to production.
| perrygeo wrote:
| 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 wrote:
| 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.
| brunaxLorax wrote:
| 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 wrote:
| 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.
| brunaxLorax wrote:
| Stay tuned :)
| lionkor wrote:
| Developer discovers he can type emojis on his PC
| sigmonsays wrote:
| do we really need more yaml?
|
| This is insane to me.
| meiraleal wrote:
| There's a typo in "Define your data structure, get a business-
| ready backend will essential features"
|
| I guess you meant with not will?
| brunaxLorax wrote:
| Oops... Thanks !
| gedy wrote:
| Dev: this is cool and thanks for sharing, don't let the
| complainers discourage you. They mostly share nothing themselves.
| alextheterrible wrote:
| 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.
| brunaxLorax wrote:
| 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 wrote:
| '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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| robbiejs wrote:
| 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?
| dhuan_ wrote:
| 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'
| slooonz wrote:
| 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 ?
| slooonz wrote:
| 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.
| jslakro wrote:
| This seems JSONServer https://github.com/typicode/json-server but
| in YAML
___________________________________________________________________
(page generated 2024-06-01 23:02 UTC)