Live data from Hacker News

Goravel: A Go framework inspired by Laravel

goravel.dev

141–150 of 170 posts

Re: Goravel: A Go framework inspired by Laravel

#141

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…

This works in Java too. Wire up classes yourself and eschew the IoC framework.

That sounds nice. Except find a company today that doesn't perceive spring framework and java as synonymous.

Tbh, its not a whole lot different than where PHP is going where php is becoming synonymous with Laravel. Wordpress is probably one of the last few bastions keeping that framework from fully owning the language.

Re: Goravel: A Go framework inspired by Laravel

#142

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…

You're missing the entire point of frameworks like Spring and Laravel. They are there to remove the power of choice and thereby actually create clarity and maintain speed over a long period of time. What happens with the "I'll build everything from scratch" apps is they are oftentimes not easy to understand, different patterns end up being used, 3rd party packages get slapped on ad-hoc and over time it just becomes a…

Yeah this is the positive side of the double-edged sword of frameworks.

Without Spring, you would have every team rebuilding the database layer in 100 different ways. With 100 shoddy attempts at documentation.

So for better or worse, having one framework-standard way to interact with the database, modify headers, or do any number of standard tasks makes life easier even if it enshrouds the underlying system in abstraction and layering.

Re: Goravel: A Go framework inspired by Laravel

#143
post #69
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…

This whole comment has strong C language “we don’t need a package manager, we write everything ourselves” vibes. The benefit of something like Django is it provides strong convention, loosely enforced. Everyone on your team needs to know one thing. Everyone can understand the convention, understand each other’s code, new features get added the same way. But it’s also loosely enforced, it’s just Python. So when you ne…

My work has 50 eng teams. We started on django and our internal standards team have depreciated it - no further projects in django. We are applying the strangler pattern the best we can, everything new in Go if we can.

The django code is so intertwined and full of circular imports. Custom db managers to handle our multiple dbs with read-replica routing, custom caching solutions, and everything inherits from something and base classes have insane child-type checks and methods that are only used in one child class. And due to the ease of passing query sets around, we have complex and slow joins and n+1 queries everywhere. And object properties that are actually methods that call and cache from the db, so sneaky n+1.

The unlimited escape hatches in python has turned into welded spaghetti making development and organizational velocity slow.

Re: Goravel: A Go framework inspired by Laravel

#145

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…

You're missing the entire point of frameworks like Spring and Laravel. They are there to remove the power of choice and thereby actually create clarity and maintain speed over a long period of time. What happens with the "I'll build everything from scratch" apps is they are oftentimes not easy to understand, different patterns end up being used, 3rd party packages get slapped on ad-hoc and over time it just becomes a…

Keeping dependencies and standards in check to keep apps maintainable is important, and I agree that if you don't start with a big framework then there is more potential for it.

I have to say it's not something I've experienced in practice, mainly because the teams I'm on take such things seriously, but YMMV.

Re: Goravel: A Go framework inspired by Laravel

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

No, sorry, the vice versa is not true.

You can write any possible SQL query in SQL, but you can't write all of them in an ORM (without falling back to native SQL queries)

SQL is strictly more powerful.

Sometimes it's also way more verbose.

So I agree that you should be able to leverage both tools, but they are not even remotely as powerful.

I every project we used ORM for, at some point we had to jump through hoops and write plain old SQL (depending on the language and framework that's simple or terribly complex), because we had to fix the n+1 query problem.

In every project, since more than 18 years!

Re: Goravel: A Go framework inspired by Laravel

#148
post #36

Earlier quoted context omitted.

Can you go into a bit more detail about what became challenging and what Astro helped you solve?

At first, my goal was to go pure with vanilla JavaScript and CSS, hand-coding Echo routing, authentication, secure cookies, etc., using Go libraries—and I did just that. But as a solo developer managing both backend (Go + SQLC) and frontend (vanilla JS + CSS), it became overwhelming. My co-founders had no concrete feature roadmap, throwing in whatever they thought was good, and our UI/UX designer was stuck with a bug…

The frontend is always going to be a pain since you have to deal with JS in some form, and a culture of ever increasing complexity until people give up and rewrite everything and throw away years of work.

When you have Go, I don't see how switching to JS/TS comes with any benefit on the backend.

At some point I would have liked to meet people who struggle using Go on the backend and learn what their process is and how they structure things. I've written quite a few backend systems in Go for a variety of domains (anything from PKI systems to industrial automation and various real-time streaming systems). Surely people who struggle must either do something that is very different from what I do, or be sensitive to entirely different issues than I am.

Re: Goravel: A Go framework inspired by Laravel

#149
post #123
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, CSRF, preventing > injections, session cookies, authN/authZ, easy database CRUD operations?

So you are saying this is only possible if you use a large framework? You cannot do this with libraries? That's a very odd position.

JSON has never been a problem as it is part of the standard library. And there are lots of libraries to extend the functionality if you need something the standard library doesn't offer.

Heck, Go even has ASN.1 in the standard library so I can write custom serialization of certificates to satisfy fiddly crypto components that only work with certain representations. And it was surprisingly easy to do. If it is one thing Go is really good for, it is writing robust code for transforming data.

Learn to do things using the standard library first. Then learn what libraries to add and keep a collection of snippets and notes on how to use them so you can apply them quickly when you need them. Learn once, take notes, use again.

Re: Goravel: A Go framework inspired by Laravel

#150
post #126
post #123

Earlier quoted context omitted.

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 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.
Post reply on HN