[HN Gopher] Goravel: A Go framework inspired by Laravel
___________________________________________________________________
Goravel: A Go framework inspired by Laravel
Author : cgg1
Score : 135 points
Date : 2025-03-09 06:35 UTC (15 hours ago)
(HTM) web link (www.goravel.dev)
(TXT) w3m dump (www.goravel.dev)
| DeathArrow wrote:
| For someone who doesn't know Laravel it's worth explaining it a
| bit further.
| martinsnow wrote:
| Google is a thing
| DeathArrow wrote:
| Interesting take. So you recommend to not give detailed info
| on a pruduct website and require people to Google?
|
| It's not about me not willing to use Google but about not
| having me to. I expect to find all relevant information on
| the website in an easy to find manner.
| hatefulmoron wrote:
| Theoretically, it's probably better to get information
| about Laravel from their respective website. I would expect
| as this is a framework made for Laravel users, you're not
| really in their target audience anyway.
|
| It would be helpful to explain a little bit about why they
| like Laravel though, to entice you to read more by
| yourself.
| DeathArrow wrote:
| That would perfectly made sense if the framework intended
| only for Laravel users willing to work in Go.
|
| But they use the term "Laravel inspired" which can be
| understood as well as them catering also to regular Go
| users without prior Laravel experience. If that is the
| case, it might be worth to explain the features and usage
| of their product.
| TiredOfLife wrote:
| Google hasn't been a thing that works for years.
| dalemhurley wrote:
| Batteries included very opinionated way of building amazing
| things.
|
| That said you can choose to go your completely own way and
| ignore the Laravel way. But good luck with hiring.
|
| I think Laravel is the best framework for getting an idea
| going, to MVP to MMP to scale. It just works.
|
| Purists hate it because it is PHP and they still think it is
| 1999. They also hate that there is the "Laravel way", even
| though you can completely ignore it.
|
| Laravel is what the non-cool kids use to ship.
| leetnewb wrote:
| Laravel seems to get a lot of hate from within the PHP
| community as well. I suppose every framework in use has its
| detractors.
| gjsman-1000 wrote:
| Who, the one guy pledging Trongate, or the people in the
| Symfony camp?
|
| I assure you React gets plenty of hate from the JavaScript
| community - enough to spawn over a dozen competitors. At
| some point, community love/hate is irrelevant.
| leetnewb wrote:
| People in the Symfony camp want less magic. There is also
| a lot of activity around Tempest.
| panstromek wrote:
| I wouldn't consider it that opinionated, there's many ways to
| do the same thing. I'd say there's implementation for most
| design patterns you'd want to use in this context, so you can
| choose the style pretty much within the boundaries of the
| framework.
| adamors wrote:
| Never got the point of porting X framework from Y language in
| order to
|
| > simplifying the learning curve for Y language developers
|
| You'll just end up writing the same old patterns in the new
| language as you did in the old one.
|
| Especially with Go, it's really easier to adopt the existing
| tooling (most of which is in the standard lib) than to port
| whatever concepts Laravel/PHP had.
| weatherlite wrote:
| Not sure there's a Go equivalent of Laravel, so not sure which
| tooling you suggest people adopt. If I want an all inclusive
| MVC (or similar) web development framework with all batteries
| included - why not build a Go Laravel?
|
| Python has Django
|
| Java has Spring (among others)
|
| C# has asp.net
|
| Ruby has Rails
|
| PHP has Laravel
|
| What does Go have?
| JodieBenitez wrote:
| We now have GO's equivalent of Rails and Go's equivalent of
| Laravel. Apparently Go's way is "start with the standard lib
| and glue whatever you need on top".
| kflgkans wrote:
| > 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 get in the way.
| weatherlite wrote:
| > 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.
| kflgkans wrote:
| I personally believe ActiveRecord is a gigantic anti-
| pattern and should be avoided at all costs (by anyone,
| ever). And I also happen to have had very bad experiences
| with ORM and feel like most of the time they are not
| needed at all. So yes. But even if you want an ORM,
| there's a few popular ORM libraries. You can just include
| one and start using it, no need to use a framework for
| that (for ActiveRecord I wouldn't know).
| todotask wrote:
| JavaScript (Too many to list)
|
| TypeScript has NestJS (among others)
|
| Elixir has Phoenix
| anta40 wrote:
| Even when using frameworks, typically Go devs, from what I
| see, prefer something simpler, like Fiber or Echo. Then they
| plug any libraries the like on top of it.
| ayuhito wrote:
| 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.
| 9dev wrote:
| 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 other developers to get productive
| immediately.
|
| Comparing that to the go standard library is apples to
| skyscrapers.
| ayuhito wrote:
| 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.
| tredre3 wrote:
| > 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 blade
| capabilities, but yes Go has good enough templating for
| most tasks.
| kgeist wrote:
| Just my two cents how we do it in most of our projects at
| this point (~70 services in Go):
|
| >routing, middleware
|
| ogen (OpenAPI code generator), or a similar library
|
| >database connections
|
| from Go's stdlib mostly
|
| >an ORM
|
| sqlx (a lightweight wrapper around Go's stdlib which
| allows to hydrate results into structs)
|
| >authentication, sessions
|
| homegrown stuff, due to existing complex legacy stuff
|
| >job queues
|
| RabbitMQ's official Go wrapper (rabbitmq/amqp091-go)
|
| >email sending
|
| we delegate to a few separate VMs which already have
| postfix installed (and have good reputation)
|
| >dependency injection
|
| manual construction, works fine if split correctly
|
| >logging
|
| sirupsen/logrus (structured logger)
|
| >view template rendering
|
| React
|
| >metrics
|
| official Go wrappers for Prometheus
|
| Some of this stuff is already IMHO industry-standard (the
| default libs people reach to). To streamline creation of
| new services, we have a tool which can scaffold your
| project with all these dependencies already set up.
| tgv wrote:
| > email sending
|
| It's as simple as calling smtp.SendMail("hostname:smtp",
| nil, from, to, message)
| 9dev wrote:
| 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.
| 9dev wrote:
| Im not saying all of this isn't possible in Go, or
| somehow worse. My point is that using eg. Laravel, you
| don't even need third-party libraries for these things,
| just the framework. And all of it is built on the same
| conventions, documented in the same place, with the same
| API. Scaffolding is built-in too.
|
| All of the time you spent on building your scaffolding
| tool, researching on the libraries, checking and updating
| their version regularly; all of that isn't necessary with
| a full-stack framework.
|
| Once more: I'm not dismissing Go, or your way to set up
| projects, I'm just surprised someone would make the
| comparison to the Go std lib, which is so obviously not
| on the same level of integration and battery inclusion.
| bborud wrote:
| 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 realize how limiting they are.
|
| I tried to like various frameworks during my time as a Java
| developer, but they always end up costing projects more than
| what they save. In terms of time, clarity, performance,
| adaptability and maintainability. Decades ago I too used to
| think they might help, but I was never able to observe any
| real positive effects over time.
|
| You can always do better when you start with the domain you
| are solving and work from there rather than trying to adapt
| your domain to some generic solution.
|
| The reason Go feels more productive than Java is because in
| Go the community seems to understand this fairly well. So the
| whole ecosystem is built around libraries that are easy to
| compose rather than frameworks that try to coerce you.
|
| Big frameworks are not really helpful. At best, they are
| occasionally fashionable, which tricks people into thinking
| they are better off solving problems the wrong way around.
| halfcat wrote:
| 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 need to split from the framework's convention,
| you have unlimited escape hatches.
|
| If you want a case study, see Instagram.
| bborud wrote:
| > "we don't need a package manager, we write everything
| ourselves" vibes
|
| Then I'm afraid you misunderstood.
|
| Frameworks is not the only way to build things
| efficiently. It is actually possible to build things
| using libraries and consistent ways of structuring
| things.
|
| Also, we're talking about Go, so please use Go examples.
| Django isn't interesting in this context. Have a look at
| how you'd leverage the standard library, and perhaps a
| couple of libraries in Go to do the same.
| capevace wrote:
| I'd encourage you to seriously give Laravel a shot.
|
| I'd fundamentally disagree on it being harder to learn than
| the language itself.
|
| > You can always do better when you start with the domain
| you are solving and work from there rather than trying to
| adapt your domain to some generic solution.
|
| I'd even agree! In my view this as a reason to go pro-
| Laravel and similar opinionated frameworks. They allow you
| to focus on what actually matters, which is your specific
| business logic.
|
| Define your data models and the rest follows automatically.
| Use API Platform to automatically generate a REST API from
| just your models. Need custom logic in there? Use
| middleware or define your own routes. You're really not
| being hindered by the framework in any way I can think of.
|
| Laravel is truly a beast and IMO not comparable to older
| Java frameworks.
|
| You don't have to use these features tho. You don't have to
| use the ORM and you could even write your own routing if
| you really wanted to. To me, this is what makes a good
| framework: providing everything out of the box for 80/20
| solutions and provide appropriate escape hatches if you
| ever need to do something entirely custom.
|
| Want a react frontend? Use Intertia and get started writing
| UI and interactivity instead of setting up data flows. Want
| automatic backends? Use Filament and get Schema-based forms
| and tables for free.
|
| But I have yet to encounter web app use-cases that go
| beyond of what Laravel could handle.
|
| Something like this in the Go world would make a great
| addition, provided there are alternatives and escape
| hatches present (idk if that's the case).
| gf000 wrote:
| 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 more costly, but every
| subsequent maintainance as well.
|
| Meanwhile I can just add 3 annotations in Spring/RoR/Django
| and have solved the problem in a way that a competent new
| hire will instantly be familiar with.
|
| Also, even the supposed benefits are questionable at best -
| mechanical sympathy? Like, most of these frameworks sit on
| top of a highly efficient C web server that just calls some
| business code for nanoseconds and that's all the
| "overhead". Python and ruby backends are all over the web
| and they perform completely fine, even though these are
| interpreted languages. Java/c# won't even have that
| problem. I have seen plenty terribly performaning home-
| grown solution which were designed by a "smart" software
| astronaut - it's almost like writing a proper web server is
| a different skill set than typical CRUD business apps.
|
| And lastly, Go feels more productive because it is chock-
| full of boilerplate. So you can type and type and feel you
| are so productive, meanwhile in another language you would
| have just added an annotation and 2 lines and called it a
| day - it's just a psychological "trick". And "libraries
| that are easy to compose"? Like, which language has an
| ecosystem with libraries that are hard to compose? What
| tools do Go have that would aid in that? I would argue that
| a more expressive language have way better tools to help
| with code composition, wouldn't it?
| tgv wrote:
| > Meanwhile I can just add 3 annotations in
| Spring/RoR/Django and have solved the problem in a way
| that a competent new hire will instantly be familiar
| with.
|
| If you're building apps that are understandable to new
| hires, you're right: it's all just boilerplate CRUD.
|
| > Python and ruby backends are all over the web and they
| perform completely fine
|
| Python certainly doesn't. I've got one inherited service
| running in Python/Django, and it quickly grows to 1GB per
| worker, and even then manages to be so slow larger
| queries time out. I've written two new services in go,
| they get more traffic, and they run in 20-60MB, with
| peaks over 200MB. I can run both services and multiple
| development versions on a 2 CPU, 4GB machine with room to
| spare.
|
| > in another language you would have just added an
| annotation and 2 lines and called it a day
|
| I sincerely doubt that. The only boilerplate in go is the
| error handling. The rest is comparable to Java/C#.
| bborud wrote:
| 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.
| ljm wrote:
| 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 and you can depend on that spread
| of knowledge.
|
| To that extent it's not that frameworks are unhelpful, they
| are in fact force multipliers for solutions in the same
| problem space (e.g saas web dev).
|
| In a similar vein, I think I'd much rather build a game in
| Godot or Unreal than start framework-free with SDL.
| bborud wrote:
| After 8-9 years of Go and having about 20 smaller and
| bigger backends under my belt: no, nothing that looks
| like a framework has emerged. Not in my code or in that
| of any of my colleagues. What has emerged is consistency
| in how we structure certain things. But there is no
| frameworks needed for that.
|
| And it is not for lack of asking myself if I wouldn't be
| more effective if I distilled the practices into some
| framework. I've had plenty of ideas for frameworks and I
| always end up throwing them away. The way I structure
| things is so minimal anyway that there really isn't that
| much you can gain by creating a framework.
|
| The closest I come is tooling to kickstart projects by
| using a template driven code generation approach. But
| that's mostly possible because the way I do things is
| consistent enough that I can generate the initial code
| for things like the model types and whatever crud and API
| I need.
|
| In my 35+ years as a professional developer I have yet to
| see frameworks actually being force multipliers over
| time. They tend to have a small window where they look
| attractive. Then they tend to become a liability at some
| point.
| 7bit wrote:
| I live Django, but you cant compare it to Latavel, which is
| much more extensive
| reactordev wrote:
| Go has go. You don't need a framework when http can do
| pattern routing and cookies, database/sql can do data, and
| json is baked in.
|
| It was literally designed to do away with this choice
| confusion and provide one path to servicedom.
| todotask wrote:
| In my experience building the site with Go (Echo) with Postgres
| and a vanilla frontend from scratch, I realised that
| maintaining my codebase as a solo developer for a medium-sized
| platform was challenging. At one point, it became
| unmaintainable, and I had to rewrite it three times. The third
| time? I switched to the Astro web framework, and it solved all
| my problems.
|
| Go is indeed easy to get started with, but it's different when
| dealing with server-side rendering and not a single-page
| application where Go is a backend.
| bborud wrote:
| Can you go into a bit more detail about what became
| challenging and what Astro helped you solve?
| todotask wrote:
| 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 buggy Marvelous app. Managing both sides while
| constantly adapting to shifting requirements became
| exhausting.
|
| To ease the burden, I introduced Alpine.js, which helped,
| but the real challenge was juggling Go and TypeScript for
| different parts of the stack. When the team decided to
| revamp the site with a new Figma design, I switched to
| Astro after the release of Astro 2.0--it simplified
| frontend development and allowed me to gradually move away
| from Go. This wasn't just about adopting a new language
| with old patterns; it was about making my workload
| sustainable while improving maintainability.
|
| A month later (after three years), bad news--they ran out
| of funding and had no time for marketing. On top of that, I
| have vision problems (genetic and post-cataract surgery),
| making job options limited. But one thing I've gained from
| this experience is a strong grasp of frontend performance
| optimisation--JavaScript, Tailwind CSS, HTML, and
| responsive images. There are millions of poorly optimised
| websites that Astro could improve. At least in Singapore,
| where we have great internet connectivity, I can keep
| refining my skills.
|
| Astro solved:
|
| - Same codebase: Both frontend and backend with TypeScript,
| meaning I no longer have to write routers whenever we add a
| new category.
|
| - Optimisations: Reducing JavaScript and loading JavaScript
| as a module for better security.
|
| - Maintainability: Go HTML templating was harder to
| maintain; I prefer Astro's JSX-like syntax.
|
| - Performance: If I need performance, Bun can be as
| performant as Go, which is a bonus.
|
| - Reusability: Lots of UI and Astro components can be
| reuse.
|
| - Productive (Future): I'm waiting for Vite (Rolldown) to
| speed up my build times. Evan You has lots of ideas for
| Rolldown plugins.
|
| - Community: Of course, an active community that is
| improving Astro so we don't have to reinvent the wheel,
| with lots of sensible features by default, including
| Starlight for docs. I proposed to the Echo maintainer to
| adopt it over Docusaurus, but I was turned down.
| tonyhb wrote:
| This is an LLM response if ever there was one.
| 7bit wrote:
| Wgats your Point?
| zsoltkacsandi wrote:
| IMO there is definitely a place and need for such a framework in
| the Go ecosystem, but that does not mean that the whole API,
| structure and terminology need to be copied from Laravel as is.
| This will definitely hinder adoption.
| dalemhurley wrote:
| All languages, but some people hate opinionated frameworks.
| voodooEntity wrote:
| Some time ago i wrote a short blog article about getting started
| with goravel - might be interresting:
|
| https://blog.laughingman.dev/article/Building_a_simple_demo_...
| mrbluecoat wrote:
| Very helpful to see a full working coding example. Thank you.
| ofrzeta wrote:
| While the API seems similar, the syntax of Laravel feels a bit
| lighter thanks to PHP.
| pknerd wrote:
| Wow, wow, wow!
|
| As someone who loves both Laravel and Go, this is a Godsend! I
| would get back to Go only for using this!
| Daril wrote:
| 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 opinion, it is better to create some simple
| methods for each object that implement the CRUD operations and
| build the SQL statements directly.
|
| It is possible to write a web application with GO using only some
| libraries, for example for routing and authentication.
|
| My favorite place to start is Autostrada :
| https://autostrada.dev/
| movedx wrote:
| > 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.
|
| Instead I've thrown SQLAlchemy in front of it and now I can
| query it without writing a single line of SQL.
|
| I think tools are tools, and using the right tool at the right
| time is an important skill I think you've yet to develop.
| skydhash wrote:
| If you're only doing CRUD, you can use any reputable query
| builder or ORM. But sometimes the best model for business
| logic and the database table differs, and the methods for
| persistence are Load, Save or Add, Remove instead. That's
| when you want custom SQL where the ORM/query builder is not
| great.
|
| Laravel is great, but that because they have nicely designed
| escape hatches and their architecture is very modular.
| movedx wrote:
| SQLAlchemy doesn't get in the way of anything you might
| want to do. In fact, you can do a "textual" query and then
| have the response mapped to classes for you :-)
| never_inline wrote:
| You can do that in every ORM including the infamous
| hibernate.
| Daril wrote:
| Yes, I understand your point of view, but in my experience
| these ORM libraries when you create a class or a structure
| and then the library build the SQL code behind the scenes can
| suffer from some relevant issues :
|
| 1. you have no control over the generated SQL and because it
| has to be generic and db agnostic, might not be the best
| option depending on the database you are currently using
|
| 2. when something doesn't work as expected, and it happens,
| they are difficult to debug (too many layers) and find the
| issue
|
| 3. they are extremely inefficient, because they have to
| dynamically build every time the code is run the
| corresponding SQL code : I'm sure most would implement some
| caching mechanism to prevent this , but in any case it's a
| waste of resources.
|
| This is just anecdotal, but I remember trying SQLAlchemy many
| years ago for a small Python program I was writing for a
| RaspberryPi 3 : it was extremely slow. So, I removed the
| library and used instead the native database binding for
| MariaDB instead, and the speed improved a lot.
|
| For PHP, the situation is the worst because there is no
| application server (they exist, but not very widely used),
| but the code is regenerated every time. This is the main
| problem in any large PHP project, such as Nextcloud. If they
| would adopt FrankenPHP or RoadRunner, they could improve the
| performance of the applications a lot.
| movedx wrote:
| I too used to believe those were valid points not to use an
| ORM back in the day. That was easily 2013/2014. Since then
| I've never found an ORM that gets in the way letting my
| just run raw SQL. And not just run raw SQL as complex as
| I'd like: it'll also still give you all the magic once the
| response comes back.
| KronisLV wrote:
| > 1. you have no control over the generated SQL
|
| Depending on the tech in use, there's usually some sort of
| an escape hatch, such as writing your own native SQL
| queries that take advantage of the exact functionality you
| need, while letting you keep the 90% of the rest CRUD based
| on the automatically generated stuff.
|
| Plus, nothing is preventing you from putting complex
| querying in a DB view and then have a read only mapping for
| the ORM against that, giving you the best of both worlds -
| using the DB for what it's good at, keeping things
| relatively simple and yet powerful on the app side.
| bdcravens wrote:
| 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.
| 7bit wrote:
| > 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?
| bdcravens wrote:
| 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 ActiveRecord, I use it
| regularly. It just takes a lot of discipline once you hit
| queries of a certain complexity.)
| anta40 wrote:
| What would you use if ORM is to be avoided?
|
| Perhaps something like https://github.com/sqlc-dev/sqlc ?
| Daril wrote:
| I'm using this at the moment :
| https://jmoiron.github.io/sqlx/
|
| Didnt' now about sqlc, it seems very interesting ! Thanks for
| sharing !
| sunaookami wrote:
| Seconding sqlx, it's wonderful, is not an ORM and doesn't
| need code gen.
| leetrout wrote:
| sqlc is _excellent_ if you are comfortable with its
| limitations. I love it even though I don't love optional
| fields query pattern with NULL.
| kflgkans wrote:
| My advice is to just use standard library `database/sql`.
| Every abstraction on top adds extra complexity and isn't
| really necessary. Just execute a query, map the results, and
| there you go.
| InsideOutSanta wrote:
| "Every abstraction on top adds extra complexity and isn't
| really necessary"
|
| This. In my experience, every project that has non-trivial
| query requirements starts out as "this ORM is nice, it
| takes away 90% of my work" and ends with "how do I get rid
| of that leaky abstraction layer that constantly makes my
| life harder."
| Taikonerd wrote:
| I would say: SQL is a DSL for interacting with DBs. If it's
| not doing what you want, consider a different DSL, like Gel,
| SurrealDB, or PRQL.
|
| These also have the advantage of being programming language-
| agnostic.
| JodieBenitez wrote:
| > My favorite place to start is Autostrada :
| https://autostrada.dev/
|
| It's nice but they could make it even nicer by adding succint
| descriptions and/or pros and cons to alternatives. Choosing a
| database probably needs no explaining, but choosing a http
| router is different.
|
| Also "Read configuration settings from env vars or command line
| switches". Both. Both is good.
| 9dev wrote:
| The ORM question is a very good example for the issue you
| describe. Laravel is great to get a CRUD app started _right
| now_ , iterate very quickly, and leave implementation
| complexity to the framework. This isn't the right tool for
| every job, but it shines at those where it is. For example, you
| can drop an engineer with Laravel experience in pretty much any
| Laravel codebase, since the conventions are so strong, they'll
| probably understand your business logic upfront.
|
| Additionally, Laravel ships with a huge swath of functionality
| out of the box. While you're still researching the best SQL
| library for a project, a Laravel developer has spun up the
| framework with a working Postgres connection and starts being
| productive. There is no value in inspecting the SQL underneath,
| because the queries never get complex enough to warrant that.
| And if they do, you drop out of the ORM and write SQL.
|
| As I said before: this isn't the best way to do something, but
| a very peculiar way that works well for a specific kind of
| application. Go is simply a tool for other kinds of
| applications, where Laravel cannot compete.
| kflgkans wrote:
| > While you're still researching the best SQL library for a
| project
|
| People do this? In every language I've worked with, there's
| practically just one SQL library to use. And you just write a
| query, execute it, and map some results. Very basic.
| 9dev wrote:
| Come on, that's not what you really do, but an
| oversimplification that skimps on the actually hard parts.
|
| You manage (as few as possible) connections to a DBMS,
| create prepared statements, cache and transform results,
| lazily iterate over large result sets, batch writes, manage
| schema migrations, and more. It's not very basic, unless
| you're cobbling up a prototype.
|
| > In every language I've worked with, there's practically
| just one SQL library to use.
|
| Curious which languages that were. In practically all
| ecosystems I know, there are 2-4 contenders.
| someothherguyy wrote:
| https://martinfowler.com/bliki/OrmHate.html
| evantbyrne wrote:
| Anti-ORM sentiment is a senior developer red flag. It indicates
| pretty clearly that an engineer views their work more as an art
| project, rather than valuing achieving the actual business
| goals in any reasonable time frame.
| cshepher wrote:
| 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, what is the point of an ORM?
| evantbyrne wrote:
| 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 milliseconds.
| tkiolp4 wrote:
| 80% of the time, the queries the ORM produces are just
| fine. For the rest 20% left, I code them myself (I think
| senior engineers now how to distinguish these two
| scenarios). Now, what I don't want to code myself is the
| transformation between rows and objects... that's what an
| ORM is for.
| 7bit wrote:
| "better" .... Only the Sith deal in absolutes.
| begueradj wrote:
| A similar path was taken in the Node.js world, but it seems the
| framework in question (AdonisJs) is far from being that
| successful.
|
| Given the standard batteries included in Go, I think there is
| even less chess for this to succeed.
|
| But still that is a good thing to try. Why not. All the best.
| mkl95 wrote:
| It seems like every middling company out there wants to bolt in
| popular architecture from other languages into Go, particularly
| Java enterprise patterns. Why not use the actual language or
| framework your engineers like instead?
| jbreckmckye wrote:
| I don't think Laravel is particularly GoF-ish, if that's what
| you mean. In terms of patterns it's mostly fairly simple.
|
| > Why not use the actual language or framework your engineers
| like instead?
|
| Go does not provide "enough" by itself to completely furnish my
| needs. And having a framework that uses common terminology and
| patterns allows you to get s__t done and not waste time
| bikeshedding.
|
| "Microservices are cattle, not pets."
| kflgkans wrote:
| Could you give a few examples what such frameworks provide
| that you need, that Go plus a few simple libraries doesn't
| provide?
| jbreckmckye wrote:
| It's a long list. It might be more productive to start with
| just one example: OpenAPI validation.
|
| In large orgs with customer-facing APIs, it's imperative
| that you can validate and enforce OAS specifications
| against all routes. Customers need to know exactly what
| auth mechanisms they can use and shouldn't be enabled to
| call undocumented capabilities. It's also important from a
| practical perspective that developers can scaffold up new
| routes that are always-already bound to a specification.
| Depending on the context you either need to do "contract
| first" specification or "code first" generation based on
| type system introspection.
|
| Go can let you knock something together yourself but as
| your team gets larger, the overhead of reviewing and
| marshaling your team's practices gets more and more
| difficult.
|
| It's like the problem you have with NodeJS. It's very
| possible to assemble something that has easy to scaffold
| routes with strong type-to-spec validation, authn/z, no
| exposure of undocumented APIs. But without something like
| NestJS or Adonis each project becomes a special snowflake
| with no support for interop across repositories.
| homebrewer wrote:
| 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'm missing personally is
| automatically generated OpenAPI specifications + API
| documentation & API clients autogenerated from it. Last
| time I checked Go, you had to write the spec manually,
| which is just ridiculous -- the code already has all the
| necessary info, and duplicating that effort is time-
| consuming and error-prone (the spec says one thing, the
| code does another). This may be out of date, but if it
| still isn't, it is enough to disqualify the stack
| completely for me.
|
| Also, I don't think there anything similar in the Go world
| to these administration panels:
|
| https://docs.djangoproject.com/en/5.1/ref/contrib/admin/
|
| https://activeadmin.info
|
| https://nova.laravel.com
|
| which are just fantastic for intranet projects and/or quick
| prototyping.
| reactordev wrote:
| A simple Google search returns https://github.com/oapi-
| codegen/oapi-codegen
|
| I get wanting to be productive and gravitating towards
| patterns you're familiar with but in the end it's all
| bloat. http can do routing and patterns and cookies and
| sessions. database/sql can do your DAL work. uuid
| (various implementations) work for user/tenant uid+oid
| obfuscation. JWT libs for auth. You can literally
| json.unmarshal your config for your whole application or
| use godotenv to use environment variables. template/html
| for views. Golang has batteries, it's just you don't know
| what you don't know so you expect a certain perspective
| that isn't how we do things. Like joining a new company,
| things are different here. If you spent some time to
| learn the "go way" you'd realize that you don't need the
| bloat, you just need the structure. The "where I expect
| it".
| jamal-kumar wrote:
| It depends on the framework and other stuff around it but
| you're right about the API documentation issue, there's
| godoc if you want to document functions but for something
| like API endpoints it's not what you'd find from
| openapi/swagger unless whatever you're using is adaptable
| to that and then whenever I was working with it an older
| spec of it too. Always fun to run into a client who
| expects this from working with most of their people and
| you're just drooling like a gopher at them but for now if
| you're writing something in go for pure performance I'm
| not 100 on what balances best between that and auto
| spec... Definitely choose an API framework in go that
| works out of the box for that if it's important. This may
| be better than when I tried it a couple years back
|
| https://github.com/swaggo/swag
|
| And this one seems to generate documentation from code
| rather than annotations/comments etc
|
| https://github.com/go-fuego/fuego
| eggzy wrote:
| I think it's the issues in "Go plus a few simple
| libraries". Frameworks come with all the extra features
| built in. If I need rate limiting, I can just open rate
| limiting docs and add it to my route, there is no need to
| search some library or blog post on the "best way" to
| implement rate limiting middleware in go.
| LudwigNagasena wrote:
| I want to write `framework init` or something like that and
| get the whole scaffolding done for me so that I can focus
| on business logic. I don't want to waste time integrating
| auth, OTEL logging/tracing/monitoring, SQL dynamic query
| building, parsing & validation, config management, i18n,
| unit/integration/e2e testing, routing, http/ws/grpc
| support, openapi generation, A/B testing, task queuing,
| background jobs, cron jobs, request control (deadlines,
| rate limiting, health checks), database migrations, live
| reloading.
|
| I love that I at my workplace I can use a service template
| that wires everything together. And I don't understand why
| people want to do boring solved tasks over and over again.
| KronisLV wrote:
| > Why not use the actual language or framework your engineers
| like instead?
|
| Consistency and predictability, but with a more convenient
| technology underneath.
|
| I don't want to mess around with JDK runtimes or .NET. I don't
| want to experiment with various static packaging techniques and
| wonder whether any sort of reflection will be incompatible with
| that or any of the large frameworks that pre-date it will work.
| The runtimes themselves are good, but that's just busywork.
|
| At the same time, I do want the ability to pick up a project
| made with a certain framework and approximately know how things
| work and how to do stuff. Less undocumented internal utilities
| and custom libraries, more of something predictable -
| controllers here, services there, repositories over here,
| here's how the ORM works that's tightly integrated with
| everything else, here's how you make a RESTful API. Think more
| like Angular than React to use a good front end example (e.g. a
| pre-packaged setup with batteries included). Or, you know, a
| direct comparison between the likes of Ruby on Rails, Laravel,
| Django, Spring Boot, ASP.NET etc., maybe not verbatim, but
| something consistent and close enough.
|
| Go's standard library is also pretty good and includes a lot of
| stuff. The IDE experience is good (no need to even think that
| much about configuring your own code formatting), the compiler
| is good, platform support is good, runtime performance is good
| while the language remains higher level and easier than the
| likes of Rust, it's not hard to get everything into a single
| self-contained executable. There's numerous projects that have
| sprung up around that, even something like K3s (full Kubernetes
| distribtion) can be downloaded as a single file. Also really
| good for just CLI utilities, or full blown desktop apps (e.g.
| with Wails).
|
| In other words, to take the technological advancements, shed
| the legacy cruft and still be able to have many projects be
| predictable and keep the productivity high, regardless of
| whether the greater language community is more interested in a
| grab bag of more self-contained libraries.
| gf000 wrote:
| Well, just use the new generation of "microservice
| frameworks" in Java.
|
| I personally believe that it is a much better language and
| ecosystem, and wouldn't bother using Go which has way more
| boilerplate, has pretty bad expressivity (so that
| libraries/frameworks will suffer from a usability
| perspective, e.g. look at JOOQs, a completely type-safe SQL
| query builder) for negligible benefits.
| Thaxll wrote:
| There are equivalent to JOOQ in Go, sqlc, jest ect ...
| HumblyTossed wrote:
| Tale as old as time. Everyone wants new shiny language then
| tries to turn it into old familiar language.
| __loam wrote:
| Go is 15 years old.
| babyent wrote:
| Using layers and SRP will solve literally 99% of organizational
| issues.
|
| No framework needed.
| dankobgd wrote:
| looks horrible
| gren236 wrote:
| Well, someone would've made this at some point anyway. I don't
| get why people tend to bring stuff from other languages to Go,
| but it's better to have something than not I guess...
| khantsithu wrote:
| just use laravel bro
| myflash13 wrote:
| What I've really wanted is a Laravel-like framework in Rust.
| coder_san wrote:
| Not sure how close it is to Laravel, but loco.rs claims to be
| Ruby on Rails for Rust, so it might be close to what you want.
|
| Link: https://loco.rs/
| mogaal wrote:
| 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
| someothherguyy wrote:
| > 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?
| bulatb wrote:
| You generally need an application server, which for Laravel
| I'm guessing is the FastCGI PHP that's already running. If
| your app needs something like ASGI, or even if it bundles its
| own server, you don't really have a way to start a proper
| daemon or a place to put it. Unless you want to try to run
| Gunicorn from /var/www.
|
| All you get is a directory where NGINX has read permissions
| and that's about it, and often they specifically forbid long-
| running processes. Shared hosting was designed for the
| request-response shared-nothing stateless application model
| that you get by dropping PHP files in a place where something
| knows to route requests.
|
| If that doesn't fit your app, you'll probably use something
| else.
| ulrischa wrote:
| Why not ust use Laravel itself? You can put it on the cheapest
| webhosting plan and go for it
| JadoJodo wrote:
| I love Go and I love Laravel, but I do find the naming an odd
| choice; it seems like borrowed clout. Especially so when
| Laravel's own name is a soft reference to the work of C.S. Lewis.
| Why not pick a unique, "Go-esque" name and still nod to Laravel
| in the title/description?
| tredre3 wrote:
| Goravel doesn't roll off the tongue either. They should have
| went with Gravel.
| deergomoo wrote:
| Slightly weird that the logo seems to have copy-pasted the
| "ravel" part of the Laravel logotype too (the hard-right-angle
| "r"), just changing the colour to blue.
| leetrout wrote:
| It's one thing to have MVC in Go. It's quiet another to match the
| productivity boost Laravel (or Rails or Django) give you.
| Admirable attempt... the docs don't say much on the template
| support in the views but I would imagine there's not a 1:1 with
| Blade yet.
| juwjfoobar wrote:
| The session interface is missing WithContext(ctx context.Context)
| unless something else is making it context aware
___________________________________________________________________
(page generated 2025-03-09 22:00 UTC)