-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3 Discussion #94
Comments
Can we move from |
@MShoaei Thank you very much for the suggestion! I will look into it. |
@System-Glitch What about a diy-ORM? I think this would be a nice task. 😁 |
@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. |
@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. |
I don't think there is any good about it when you can do without! :D
I wouldn't try that. In my opinion it's not worth the trouble even if possible.
Now that you mention it I guess the better approach is to make the
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)
I haven't done this my self but if the concern is about recreating models, the process seems fairly easy; since |
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. |
There should be provided a goyave-ish way to handle this so that users can get started quickly. |
@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"? |
@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 |
@System-Glitch honestly I disagree with you. But it is your project. 😉 |
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. |
@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. |
@anacanm There may be a way to optimize with a non-breaking change:
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 |
@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. |
You can track the progress in the dedicated Github Project. |
v2.10.1 is expected to be the last release before v3, unless critical issues have to be addressed while developing this new major version.
v3 will contain a number of breaking changes. To avoid moving to a new major version too often, required breaking changes are pushed back as much as possible and grouped into a single release.
For the moment, v3 will contain the following changes:
init()
functionRemove native handlers. I understand that it would make it harder to plug well known go http modules to Goyave and isolate it a bit from the rest of the environment, but this change would be beneficial in many ways:Performance improvements: no need to duplicate the request bodyConsistency: plugged modules may not work well with Goyave and there is no way to guarantee it. They probably don't follow the same design choices and principles, which can make programs inconsistent and sometimes unreliable.request
package and move rule sets to arequests.go
file inside the controller packages. This change would make route definition cleaner and easier, and the directory structure lighter. The requests package naming was inconvenient too.Before the development of v3 starts, please let me know if you think of any breaking or major change that you think would be good for the framework, and feel free to discuss the points above.
The text was updated successfully, but these errors were encountered: