4 ms·

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

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 2y 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 2y 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?
  - brunaxLorax 2y ago
    Thank you! We want to make it faster for devs to go from idea to production.
perrygeo 2y 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 2y 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.
- brunaxLorax 2y 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.
  - deleted 2y ago
    [deleted]
jt2190 2y 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.
- brunaxLorax 2y ago
  Stay tuned :)
deleted 2y ago
[deleted]

brunaxLorax 2y 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 2y 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?
- brunaxLorax 2y ago
  Thank you! We want to make it faster for devs to go from idea to production.

perrygeo 2y 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 2y 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.
brunaxLorax 2y 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.
- deleted 2y ago
  [deleted]

jt2190 2y 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.

brunaxLorax 2y ago
Stay tuned :)

deleted 2y ago

[deleted]