v3 Discussion about goyave

[MShoaei]

Can we move from GORM? I have had many difficulties using it in the past and the documentation seems to miss a lot of use case scenarios. I think we can use sql-migrate to handle the migrations and use sqlboiler to auto generate database structs from SQL. Also it is possible to offer this as an option in the gyv CLI #39 whenever it's ready.

[System-Glitch]

@MShoaei Thank you very much for the suggestion! I will look into it.
I don't think that having multiple ORMs living together would be a good thing. Some internal features, such as authentication, use GORM. Migrating to a new solution would require the latter to let me change the code without changing the behavior of the feature. This is definitely possible and I'm not entirely against it, but it's not a small change, especially if a developer wants to migrate from v2 to v3. The new solution would have to have many advantages over GORM to make it worthwhile.

[Wulfheart]

@System-Glitch What about a diy-ORM? I think this would be a nice task. 😁

[Wulfheart]

@MShoaei sqlboiler looks promising in my eyes as I'm personally not a big fan of the reflect package. But that's just because I haven't read no good about it.
However we should take a step and consider that an additional tool will add overhead to the application. Is there maybe a way between GORM and sqlboiler?

[System-Glitch]

@Wulfheart I like the idea of a DIY ORM! That's a huge task though, but that would open some great possibilities for a better integration in the framework.

I think it could be considered for v4 instead of v3. Moving away from GORM now is not a good idea if I ever decide to go full DIY. Trusted, well tested and wide-spread solutions are preferred for now.

[MShoaei]

@Wulfheart

But that's just because I haven't read no good about it.

I don't think there is any good about it when you can do without! :D

Is there maybe a way between GORM and sqlboiler

I wouldn't try that. In my opinion it's not worth the trouble even if possible.

What about a diy-ORM? I think this would be a nice task.

Now that you mention it I guess the better approach is to make the auth package to not depend on a certain framework. I have no idea how we can do this but i think it's worth the try.

@System-Glitch

I don't think that having multiple ORMs living together would be a good thing. Some internal features, such as authentication, use GORM.

In my opinion this framework is doing a lot to ease the process of making APIs, but leaves little to no room for customization. (I know the user can customize but that's not easy, and sometimes discouraging)
So, I think forcing GORM upon users doesn't look promising. Maybe this is a good place to use the power of interfaces and leave database to the user?

This is definitely possible and I'm not entirely against it, but it's not a small change, especially if a developer wants to migrate from v2 to v3. The new solution would have to have many advantages over GORM to make it worthwhile.

I haven't done this my self but if the concern is about recreating models, the process seems fairly easy; since sql-boiler generates code from schema already in database, the migrations made by GORM are quite useful and will be used to generate the new database models. the heavy part in my opinion would be to change old codes to use the new models. But still I guess it's better to leave the DB part for the user to decide.

[System-Glitch]

@MShoaei

So, I think forcing GORM upon users doesn't look promising. Maybe this is a good place to use the power of interfaces and leave database to the user?

I agree. That would probably be a bit challenging for internal features to support a wide variety of dialects though. This is a point worth digging.

[Wulfheart]

I haven't done this my self but if the concern is about recreating models, the process seems fairly easy; since sql-boiler generates code from schema already in database, the migrations made by GORM are quite useful and will be used to generate the new database models. the heavy part in my opinion would be to change old codes to use the new models. But still I guess it's better to leave the DB part for the user to decide.

There should be provided a goyave-ish way to handle this so that users can get started quickly.

[Wulfheart]

@System-Glitch Even though you primarily targeted goyave for api development: What do you think about moving goyave slightly into a "Laravel/Ruby on Rails for Go"?

[System-Glitch]

@Wulfheart What do you mean exactly? Adding more front-end features, templating, etc? I prefer to keep Goyave focused on API development. I strongly believe that this is the better way to go now and that front-end frameworks will prevail in the near future.

Although pretty basic, front-end development is still possible thanks to Go's standard templating package and the response.RenderHTML() method.

[Wulfheart]

@System-Glitch honestly I disagree with you. But it is your project. 😉
In that case I'm going to do a little template for myself for a classic monolith. 🤷‍♂️

[anacanm]

The removal of native handlers worries me a bit. Sacrificing interconnectedness for performance may be beneficial for small projects, but not having the ability to smoothly integrate outside packages grows to be more and more of a problem as a project, and its requirements, grows.

[System-Glitch]

@anacanm Can give give me a list of examples of packages you use or you may use and that you would like to plug into Goyave? Studying their similarities can help finding a balanced solution.

At any rate, it is impossible to guarantee that native handlers will work properly, and as such, I considered the idea of removing them. Troubleshooting why a native handler is not working may take more time than simply re-implementing one that fits into Goyave directly. The framework is still very young, but if it grows in popularity, we will probably see more and more packages made for Goyave directly.

[System-Glitch]

@anacanm There may be a way to optimize with a non-breaking change:

• Clear the Formdata anyway
• Reset the body reader so native handlers can call ParseForm themselves

That would just add a bit more overhead to native handlers that would need to parse the form again. But for the vast majority of cases, this will be an improvement. Compatibility would probably be increased a lot too.

If this change sounds good to you, it will be part of v2.10.1, and native handlers won't be removed in v3.

Edit: check the following commit 0e4deb6

[anacanm]

@System-Glitch I didn't have any specific packages in mind, I merely wanted to emphasize the importance of compatibility in a framework. I think that your idea regarding v2.10.1 is a good compromise.

[System-Glitch]

v3 development has started. If you want to contribute, please fork on the branch named v3, create a new branch from there, then make your pull requests target the v3 branch. Email me if you need guidance or anything else.

You can track the progress in the dedicated Github Project.