Thanks! Right now we do have an "expected" structure that differentiates between client/server/shared code. But as a former Rails person myself, I can say everyone on the team appreciates how "convention over configuration" plus best practices can really help devs and it is something we try to do as well. So I think we will continue to make improvements in this area. Feel free to give it a go and drop into Discord and let us know what you think!
For now it's pretty flexible, we only enforce top-level dirs - client/, server/ and shared/ and then everything else is referenced through imports in .wasp file.
But I agree providing some best practices on the structure would be helpful - I personally prefer top-level grouping-by-feature (e.g. "billing/" and "reports/") over grouping-by-type (e.g. "controllers/", "components/"), but I know some folks prefer by-type, especially in the smaller projects.
We plan to add more starter projects and templates so that might be a good start. Is there anything specific you'd like to se enforced/suggested, based on how you like to structure your projects?
I think something around structuring business logic in easily testable mutations and having good ways of creating factories without too much boilerplate code are the main things on my mind!
It feels like the JS ecosystem is missing framework that helped define layers of an app much like Rails/Django