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

151–160 of 170 posts

Re: Goravel: A Go framework inspired by Laravel

#151

Post by someothherguyy »

christophilus wrote: post #130
someothherguyy wrote: post #66

Earlier quoted context omitted.

> 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.

Laravel is a gigantic memory hog as far as PHP apps go. I don't think it makes for a great shared hosting go to, unless you completely ignore PHP's common concurrency models and feel like you need to serve a few requests per second.

There are some ways around this these days, but these seem unlikely to bolt in to common shared hosting providers.

Re: Goravel: A Go framework inspired by Laravel

#152

Post by robertlagrant »

bdcravens wrote: post #115
7bit wrote: post #84

Earlier quoted context omitted.

> used to be the norm. People also "used to" invest radioactive water and used radioactive cremes and toothpastes for health benefits in the 20's and 30's. So what's your point?

That any discussion around systems that uses some arbitrary size of tables/rows/etc is empirically disproven. Moreover, any exaggerated example of a bygone time is unrelated, as many SQL-driven systems still exist today. I work on one such system which is much larger than the example given, and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. (No hate against A…

> I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. (No hate against ActiveRecord, I use it regularly. It just takes a lot of discipline once you hit queries of a certain complexity.)

ActiveRecord is the problem there, though. Or any active record-style ORM. That's why Hybernate/SQLAlchemy-style ORMs are so useful: they don't suffer from the same issues as ActiveRecord-style ORMs.

Re: Goravel: A Go framework inspired by Laravel

#153

Post by whstl »

bborud wrote: post #150
whstl wrote: post #126

Earlier quoted context omitted.

> 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 Availa…

ORMs tend to make things more complicated and usually slower. I'd recommend using SQLX. It is a nice half-way point. It eliminates most boilerplate, is going to be sufficiently performant for 99% of cases, and it reduces a lot of cases down to between 1 and 5 lines of code for simple CRUD operations. (Where it isn't fast enough you can easily fall back to using the SQL drivers directly.

I agree 100% with you, and this is how I build my stuff too!

I was just pointing out that framework-less Go projects can have SQLX, ORM, etc, if you want to!

Re: Goravel: A Go framework inspired by Laravel

#154

Post by ahtihn »

bdcravens wrote: post #60
movedx wrote: post #21

Earlier quoted context omitted.

> One of the things I would discard would be the use of an ORM library ... In my opinion, it is better to create some simple methods for each object that implement the CRUD operations and build the SQL statements directly. Have you done this for any complex system? I'd love to see you do this for the AzerothCore: it has 298 tables, 3,010,875 rows across those tables, and one table (quest_template) has 105 columns. In…

Writing SQL against systems much larger than that used to be the norm. You are correct that "using the right tool at the right time" is important, and often, that right tool is SQL. Other times it's not. Unfortunately there are many developers who don't really know SQL, so every problem is ORM-shaped.

> Writing SQL against systems much larger than that used to be the norm.

Doing things the hard way was the norm until a better way was found.

Saying something was the norm in the past doesn't imply it was good

Re: Goravel: A Go framework inspired by Laravel

#155

Post by 9dev »

ayuhito wrote: post #127
tredre3 wrote: post #89

Earlier quoted context omitted.

> 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…

It’s like you’re saying, „get a Raspberry Pi instead of an iPhone, it can do the same things!“

Go is Turing complete, sure it can do all things Laravel can. But the whole point is that with a proper full-Stack framework, you’ll get everything in a single, maintained, tested, streamlined, coherent, and documented bundle.

Re: Goravel: A Go framework inspired by Laravel

#156

Post by desumeku »

9dev wrote: post #43
ayuhito wrote: post #28

Earlier quoted context omitted.

The standard library. It’s honestly feature rich enough to do most things that the only other dependencies we really need to pull in is some third-party SDKs (e.g. AWS) and our database driver.

I assume you have never used Django or Rails or Laravel then. With these, you get a web application with routing, middleware, schema validation, database connections, an ORM, authentication, sessions, job queues, email sending, distributed caching, dependency injection, logging,secret handling, view template rendering, websockets, metrics, and much more—right after the installation, set up with conventions allowing o…

>job queues

In Go, these are called "channels".

Re: Goravel: A Go framework inspired by Laravel

#157

Post by desumeku »

9dev wrote: post #110
tgv wrote: post #98

Earlier quoted context omitted.

> email sending It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)

It’s not. One thing is sending batches of transactional mail to thousands of recipients in a production web application running on a bunch of replicated containers on ephemeral machines, the other is proof that SMTP theoretically works in your programming language.

It does not take more than 10 lines of code to launch a goroutine (or two, or more, due to how easy worker pools are in Go) that receives email requests and sends them in batches.

Re: Goravel: A Go framework inspired by Laravel

#158

Post by desumeku »

weatherlite wrote: post #51
kflgkans wrote: post #18

Earlier quoted context omitted.

> If I want an all inclusive MVC (or similar) web development framework with all batteries included I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just…

> It's quite easy to do most things you would want by just writing some code OK, I want a similar thing to ActiveRecord - with all the features, is that quite simple to build? Now you'll tell me I probably don't want an ORM at all. But lets say I do, lets say many people find value in these things.

> I want a similar thing to ActiveRecord

First of all, you shouldn't be using Go, because it's not the language where you do those kinds of things.

Re: Goravel: A Go framework inspired by Laravel

#159

Post by Pooge »

homebrewer wrote: post #64
kflgkans wrote: post #45

Earlier quoted context omitted.

Could you give a few examples what such frameworks provide that you need, that Go plus a few simple libraries doesn't provide?

Same reason IDEs — when you really know them — allow for quicker development compared to using primitive text editors with a bunch of third-party plugins duck-taped together. When you understand the framework, everything is written to the same standard, behaves in similar ways, and is where you expect it to be. Adding things like background job processing requires changing one line of config. Also, one major thing I'…

> automatically generated OpenAPI specifications + API documentation

I'd much rather have engineers write OpenAPI specification files by hand and then generate their server code from that file. Way easier to maintain and actually forces devs to have good documentation for their APIs.

Re: Goravel: A Go framework inspired by Laravel

#160

Post by movedx »

bdcravens wrote: post #138
movedx wrote: post #133

Earlier quoted context omitted.

> ... and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. But it was ActiveRecord that got you there in the first place, as a business, and enabled you to even build anything quickly enough to meet market demand and therefore make money. Moving to a few raw SQL statements today to improve performance is called optimising and everyone in every industry does tha…

Sure, both tools are great options to have in your toolbox. My bigger issue was with the claim that you can't build an application bigger than arbitrary size X without an ORM, which is empirically untrue. I will say that there are queries that take 2-3 minutes to write in SQL where you have to bang your head into the wall to make the problem fit into an ORM-shaped box. (and vice versa) A bigger problem are developers…

> My bigger issue was with the claim that you can't build an application bigger than arbitrary size X without an ORM, which is empirically untrue.

I never said that. I said that it's harder to do and there's no reason not to use an ORM to make it easier.

Post reply on HN