Comments (16)
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.
from goyave.
@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.
from goyave.
@System-Glitch What about a diy-ORM? I think this would be a nice task. 😁
from goyave.
@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
?
from goyave.
@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.
from goyave.
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.
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.
from goyave.
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.
from goyave.
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 byGORM
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.
from goyave.
@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"?
from goyave.
@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.
from goyave.
@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. 🤷♂️
from goyave.
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.
from goyave.
@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.
from goyave.
@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
from goyave.
@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.
from goyave.
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.
from goyave.
Related Issues (20)
- Validation context: access to request object
- Http Client for goyave HOT 6
- response.Error() doesn't take response status into account in debug mode
- Validation made for autocomplete HOT 3
- Exists/Unique validation rule panics when input type doesn't match database column type HOT 1
- Panic when parsing multipart form with an empty file HOT 1
- Clickhouse database dialect HOT 2
- Bigquery database dialect
- Deflate compression encoder HOT 1
- LZW compression encoder
- Brotli compression encoder
- Zstd compression encoder
- New validator: KeysIn
- New validator: DoesntStartWith
- New validator: DoesntEndWith
- Language variant priority is not deterministic
- walk.Path escape character
- Validation of config struct and slice HOT 1
- Validation: use default language if not provided HOT 1
- http.Flusher implementation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from goyave.