It says full-stack but I only see Front End

[jmaister]

I saw the demo video and it's fantastic! Something that I was dreaming about but always postponing.

My question is, as it is a full-stack framework, will it include easy or managed database access, in the sense that I declare a Go struct and the database gets created and/or updated?

Also, other common parts that are needed in an application like authentication, internationalization, etc...

[thepudds]

Hi @jmaister, as I understand it, that is not yet part of what was publicly launched.

Elsewhere, @matthewmueller wrote:

What are your plans for models and persistence?

I haven't worked out all the details, but it's going to be some blend of https://github.com/xo/xo and https://sqlc.dev/.

Design goals:

1. High-level, type-safe "ORM" that's generated from your database schema.

2. sqlc as a fallback to cover the more complex SQL queries in a type-safe way.

The hard part is going to figuring out how to support extending the ORM with your own custom methods, hooks, computed fields etc.

What do you think?

[matthewmueller]

Thanks @jmaister for opening this discussion and for the kind words! @thepudds is correct, but to add a bit more flavor.

Many of the features you mentioned are planned, but to get a sense of where the framework is heading, I'd have a look at the reserved directories: https://www.notion.so/Hey-Bud-4d81622cc49942f9917c5033e5205c69#e6351d67adb143ceaa45e957caa5bdff

It's a bit cryptic, but those are all features I'm currently planning to add to the framework. This will no doubt take at least another year or two.

The first step was to see if there was genuine interest in a full-stack Go framework. Thanks to developers like yourself, I've answered this question. I implemented the bare minimum to be able to record a demo and put up a website. This required views and controllers.

I have a bit more foundational work to do to shore up the compiler and simplify deployments, then I'll wrap up website, get the documentation in better shape and then start working on these code generators.

I'm hoping others can start to contributing to the roadmap too. Anything I can do to onramp more contributors, please let me know.

Thanks for mentioning internationalization by the way. I hadn't considered it and don't yet have experience with i18n but it seems like Buffalo could be a good inspiration.

[jmaister]

@matthewmueller Definitely, this is a good start. And I would like to contribute.

To help to get contributors for the project I would create scenarios on how bud would be useful for a developer and how it is your vision in the future to work with it. For example:

A developer wants to create a CRUD for a list of cars:
Step 1: create a vehicle.model in the models folder (with whatever model definition language is decided)
Step 2: bud create cars --model vehicle
Result: Full REST API for cars in /vehicle + Automatic UI generation for CRUD on /cars

Then with all these use scenarios, it can be created a list of modules needed for the final product. With those defined modules, then people can contribute knowing how that module fits in the whole picture.

[matthewmueller]

Hey @jmaister, I appreciate you taking initiative! I agree with your suggestion to use scenarios to drive feature development. I mentioned something similar in the Roadmap about using demos to mark milestones.

So models are going to be one of the most important but also hardest solutions to get right. If you have some ideas, feel free to open a new discussion in the Ideas category. I'd love to hear your ideas, but please don't be disappointed if I go in a different direction. I've thought a lot about the ORM already, so that might not be the best place to start. I'll try to start the conversation in an RFC soon.

The design goals for Model support:

1. High-level, type-safe ORM that's generated from your database schema.
2. Ability to extend the ORM with your own custom methods, hooks and computed fields.
3. sqlc as a fallback to cover the more complex SQL queries in a type-safe way.

One sub-solution to models that I haven't thought much about is how sqlc will integrate with Bud. As a public API, I was thinking you'd have something like:

model/
  user/
    ComputeBillables.sql

And then usage would be: user.ComputeBillables(), but beyond that, I haven't thought much further.

One last suggestion: think about ideal usage. If the constraints that sqlc bring make the solution more cumbersome, we'll use sqlc's components for Bud, rather than the sqlc full stock.