What would you guys think of SST stepped a bit more towards offering a backend framework. Nothing crazy and it would be totally modular but basically providing more application level structure instead of just being on the infrastructure side? Is this useful or are you here because you specifically want to handroll everything in the application?

Isn’t this what constructs are supposed to do. How would this fit into that?

I have appreciated the lack of rules, letting me build things out how i like. Though maybe this is a different project SST-Framework that is very opinionated and focused on repeatable scenarios for a dev team could be valuable. As always, its gonna be hard to please everyone 🙂

Right now we mostly offer infrastructure primitives. We'll continue to do that and let people assemble those into apps however they want. But if we also primitives for your application (eg for permissioning, loading config, middleware for API reqs, etc) is this appealing or do you already have other libraries you glue together for this kind of thing

I took a look at middy, but eneded up rolling my own handler middleware to deal with auth, errors, etc. Might be cool if ya have one, but its gonna be tough as mine does seem to be custom built to our needs...

Make it a separate project which builds upon SST, kind of how prisma has multiple projects. This would be crazy good, I’m high lol!

Yeah it would be a separate project, we're kinda already starting to do it but now I'm thinking about how far we should take it

The model / db part is a no brainer. If you could pair that with an implementation like prisma and ddb then it’ll just fly. Single table design is still quite foreign to most people.

Yeah exactly, lots of common areas between apps we can solve if people are following an opinionated structure. File uploads is one thing we're already working on. And we have our console to make debugging these features easier

data persistence done right would be the best thing though, it sounds easy but doing it right is difficult. I understand it is the most difficult of asks but it’ll be the game changer I believe.

Yeah that's probably the last thing we'd do haha. It's difficult to make something there that works universally, right now we're actually building with serverless RDS + kysely

Yep, planetscale / cockroachdb support for kysely would be great as well.

I think a lot of vendors will try this kind of thing. There are a lot of opportunities to move appdev away from the "big blob of compute and a database" approach and many folks will see advantages to being able to write an app that just intrinsically includes native services. I would make sure you're thinking about how to enable hybrid approaches for folks who need to extend your framework or use services you aren't covering. A black box approach would probably be tough to get right. We've seen grief from amplify users who can't implement single-table design as an example of this approach being too restrictive.

@Matt Morgan very aptly said, extensibility would be a key factor in adoption and retention. That’s how ruby on rails became big compared to something like zend / laravel.

Yeah exactly, I personally am someone that is afraid of stuff like amplify, I prefer offering primitives rather than frameworks. I think serverless cloud is also building a fullstack framework like this

Maybe you're thinking something somewhere between middy and amplify/serverless cloud.

Yeah just smooth out the rough edges in the day to day experience

that makes sense, either structure or metaprogramming by using base classes to define what a class does those are probably the only ways to build such functionality.

I’d love this, serverless is crying out for some patterns that help people be productive and write great code! Looking forward to seeing what you come up with