51–60 of 80 posts
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.
[flagged]
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.
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.
Another bit worth adding to the yaml config on a collection basis: seed data
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 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 ?
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.
do we really need more yaml? This is insane to me.
Earlier quoted context omitted.
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 stru…
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…