31–40 of 80 posts
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.
Earlier quoted context omitted.
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 thin…
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?
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.
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.
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.
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.
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
Do you mean simple or easy? It seems like you actually mean to say easy.
What is the difference between a simple backend and an easy backend ? Not sure that I pickup the nuance
If the use of "pickup" instead of "pick up" was intentional, that's hilarious.
There's a typo in "Define your data structure, get a business-ready backend will essential features" I guess you meant with not will?
Do you mean simple or easy? It seems like you actually mean to say easy.
What is the difference between a simple backend and an easy backend ? Not sure that I pickup the nuance
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.
Earlier quoted context omitted.
Javascript YAML warriors not understanding what a computer actually is. Also https://noyaml.com/
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?