Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goravel: A Go framework inspired by Laravel

goravel.dev

Post reply on HN
Print view View original

121–130 of 170 posts

Re: Goravel: A Go framework inspired by Laravel

#121

Post by liampulles »

At my last job I wrote web services using Spring (Java enterprise stuff). That was how I and a lot of my colleagues first learned how to write enterprise code: via lots of annotations.

Then I discovered Go and learned a different way to make systems. At first it was strange - where was the IoC framework? How do I build up my db entities?

And then I got into the philosophy of Go: how its better to make things that are clear rather than clever, and how its better to do things with an obvious control flow. In my current Go job, we wire singletons manually, build up our http server manually, and write raw SQL. It works gangbusters.

Please lets keep Go raw and simple.

Re: Goravel: A Go framework inspired by Laravel

#122

Post by liampulles »

Daril wrote: post #20

I'm not a fan of the complexity added by this and other similar frameworks. PHP and Go are very different languages, so trying to replicate the same concepts for one language to another I don't think it is a good idea. One of the things I would discard would be the use of an ORM library : every library adds another level of complexity and doesn't allow to see what is happening when the SQL statements are built. In my…

I totally agree with you. Writing raw SQL, and really just thinking of usecases in a more data-orieted way I think leads to clearer and more maintainable code, even if it takes a little more time initially. Although even then, I have to say ChatGPT can spit out such good SQL and accompanying Go models now that its not even that slow to do.

We've taken over a rails codebase at work, and the number of O(n) queries that are being done instead of bulk queries is rather shocking. I'm sure that one can write efficient queries using the Rails ORM, but it does seem to me that the presence of it allows for more misuse.

Re: Goravel: A Go framework inspired by Laravel

#123

Post by gf000 »

bborud wrote: post #102
gf000 wrote: post #78

Earlier quoted context omitted.

But CRUD is a solved problem, and don't forget about essential complexity, which can never be avoided. Reinventing that basic logic takes a lot of code and time for a bug-ridden, worse, half-implementation. And on top it will be completely home-grown, any new hire will have to learn it from the barely existing internal "documentation" that wasn't touched in years - making not only initial development multiple times m…

If your problem can be solved with CRUD alone, sure. However, that is usually only a starting point. And if you optimize for the smallest and simplest part of a problem just because it comes first, you may not be looking ahead. It isn't like writing a basic CRUD-application in Go is a lot of code.

We are talking about Laravel. The primary way to interact with your app is either via HTTP requests or not, there is not much in-between, so I don't really get your point.

There is a very well defined architecture for the CRUD part that gives itself to "frameworkification". That part is free to call out to any other business code you deem necessary, this is such a surface you can trivially build on. Your software does complex route planning? Sure, have an endpoint that specifies a config and call out to however complex logic you need, and return the result (or just that you are working on it, and another endpoint will later be available for the results or whatever). But not everything gives rise to such stable surfaces.

> writing a basic CRUD in Go

Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization, CSRF, preventing injections, session cookies, authN/authZ, easy database CRUD operations?

Re: Goravel: A Go framework inspired by Laravel

#125

Post by whstl »

ljm wrote: post #91
bborud wrote: post #35

Earlier quoted context omitted.

Go has a simpler approach that encourages you to express yourself more directly, does away with heavy frameworks that take longer to learn than the language itself, and it encourages you to structure solutions in mechanical sympathy with the problem rather than start with a solution and then try to adapt the problem to a given solution. Big frameworks are extremely limiting. They also make escape harder when you real…

Ultimately, you’re going to end up with a framework anyway as your internal hand-rolled solutions congeal into some sort of standard. Only it’ll be all novel and unique, maybe lacking effective documentation, and it’ll take even the most seasoned engineers time to settle in to it. Many good frameworks actually started that way, with the open source community stepping in to support. Suddenly loads more people know it…

I agree with the sibling poster.

This post underestimates how much custom code and structure ends up in larger projects that use a framework, or even game engines.

Every single medium-to-big project I worked on for the last 25 years had a different structure and code style, regardless of using a framework or not. Other than the folder structure for the basic structures (often the M, the V and the C), everything would be different. There would be folders for different new "things", but these "things" are always different. Plus with multiple modules for encapsulating business logic that rarely had anything from the framework itself (except as leaky abstractions), different libraries for managing the business logic, etc.

Sure, trivial CRUD apps will always gonna look similar. But at this scale it doesn't matter much

And Go is actually refreshing in this regard, because people actually try to avoid those crazy abstractions. Rails is possibly the worst of the bunch, because it requires way too many third-party libraries for basic stuff (authentication and authorization), and I once even had to order a paid book to get documentation on a specific framework that the previous team who built the app used but didn't provide any documentation online whatsoever (Trailblazer, for the curious).

Re: Goravel: A Go framework inspired by Laravel

#126

Post by whstl »

gf000 wrote: post #123
bborud wrote: post #102

Earlier quoted context omitted.

If your problem can be solved with CRUD alone, sure. However, that is usually only a starting point. And if you optimize for the smallest and simplest part of a problem just because it comes first, you may not be looking ahead. It isn't like writing a basic CRUD-application in Go is a lot of code.

We are talking about Laravel. The primary way to interact with your app is either via HTTP requests or not, there is not much in-between, so I don't really get your point. There is a very well defined architecture for the CRUD part that gives itself to "frameworkification". That part is free to call out to any other business code you deem necessary, this is such a surface you can trivially build on. Your software doe…

> Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization

Those are solved problems in Go's standard library. And let's be fair: while some frameworks do a lot of stuff, the majority is very bare bones and just automate serialization, so compare with the average. And some even cause even more problems than they solve (Rails mass-assignment).

> CSRF

Available in several routers, if you choose to use a custom one, or in the form of middleware if necessary.

> preventing injections

Which kind? For SQL, database/sql provides the tools necessary for avoiding SQLi, and requires the same care/discipline you'd need on a big-framework app. For XSS just use the builtin facilities of html/template rather than reinventing the wheel.

> session cookies

Library, if it's not in the router of your choosing.

> authN/authZ

Once again, let's be fair. AuthN didn't exist on Rails for 20 years, for example (and is still quite bare bones compared to libraries). AuthZ still doesn't. In Spring and .NET both also require libraries. So just use a Library in Go?

> easy database CRUD operations?

What's that, ORMs? SQL Generators? They do exist in Go.

Re: Goravel: A Go framework inspired by Laravel

#127

Post by ayuhito »

tredre3 wrote: post #89
ayuhito wrote: post #73

Earlier quoted context omitted.

Almost everything you listed already exists in the standard library. And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary. There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.

> Almost everything you listed already exists in the standard library. That's a bold faced lie. In the list, the only things provided by Go are: - routing: http.ServeMux has a router but until recently it was usually not used in real applications due to very limited capabilities (they finally added proper patterns in 1.22 which, in my view, finally makes it good enough). - template: it's not even close to laravel's b…

> routing, middleware

net/http (even middlewares are just http.HandleFunc)

> database connections

We were using database/sql for the longest of times before switching to pgx since we wanted some convenience functions.

> email sending

net/mail gets you far enough unless you want to scale it.

> logging

log/slog (which is actually production grade compared to log/log)

> view template rendering

text/template, but I also think Laravel is a better choice if that’s your main focus.

Others either need an experimental standard library package (e.g. golang.org/x/crypto/argon2 for stuff like authentication) or finally need third party dependencies. DI is not enforced like other frameworks, but an extremely common pattern in Go.

At this point, do I really want to bring out a whole framework just for the last few requirements?

Re: Goravel: A Go framework inspired by Laravel

#128

Post by christophilus »

evantbyrne wrote: post #76
cshepher wrote: post #71

Earlier quoted context omitted.

Or it can mean that the engineer is tired of rewriting ORM generated queries into performant queries. Sometimes it is better to use 'explain plan' once rather than cleaning up a generated sql filled with outer joins, table scans, and difficult to understand variable names. The ORM code in this case can look more "pristine" but can cause the app to fail in production. If you are using createNativeQuery everywhere, wha…

The author presented their opinion as broadly stroked general advice and in that context it is poor. And, specifically regarding database/sql, creating a bunch of pointers to scan values into for every query you write is the definition of insanity in all but the most performance sensitive applications. We're talking microseconds (or even nanoseconds in some instances) on an operation typically measured in millisecond…

You don’t need an ORM for that, though. I’ve used Scany in the past, and it was great. Raw, parameterized SQL that is easy to reason about and easy to scan into your structs:

https://github.com/georgysavva/scany

Re: Goravel: A Go framework inspired by Laravel

#129

Post by brigandish »

liampulles wrote: post #122
Daril wrote: post #20

I'm not a fan of the complexity added by this and other similar frameworks. PHP and Go are very different languages, so trying to replicate the same concepts for one language to another I don't think it is a good idea. One of the things I would discard would be the use of an ORM library : every library adds another level of complexity and doesn't allow to see what is happening when the SQL statements are built. In my…

I totally agree with you. Writing raw SQL, and really just thinking of usecases in a more data-orieted way I think leads to clearer and more maintainable code, even if it takes a little more time initially. Although even then, I have to say ChatGPT can spit out such good SQL and accompanying Go models now that its not even that slow to do. We've taken over a rails codebase at work, and the number of O(n) queries that…

My experience is that if one has never thought in sets, only in iterations, then the proverbial "when you're a hammer, everything looks like a nail" kicks in and every database query become a for-loop or, if it's Rails, an each-loop.

Re: Goravel: A Go framework inspired by Laravel

#130

Post by christophilus »

someothherguyy wrote: post #66
mogaal wrote: post #55

One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it. At the same time, my daily work demands Golang 80% of the time. I keep having mix feelings when having this dichotomy

> One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it Why can't you do that with anything?

I think by share-hosting they mean the super cheap PHP hosting that really doesn’t have an equivalent in Go or really any other popular language I’m aware of.
Post reply on HN