[HN Gopher] Pagoda: Rapid, easy full-stack web development start...
___________________________________________________________________
Pagoda: Rapid, easy full-stack web development starter kit in Go
Author : tosh
Score : 128 points
Date : 2024-09-29 18:19 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chasehayes wrote:
| Looks impressive, and the docs are thorough. Nice work!
| divan wrote:
| Has anyone tried both Pagoda and GoBuffalo and can compare?
|
| GoBuffalo recently archived their github project and basically
| become unmaintained, which is extremely sad for such a mature
| framework used in production by many.
| BoorishBears wrote:
| Is this common in Go?
|
| Just this week I was examining moving my early stage stack to
| Golang, but I repeatedly came across highly recommended
| packages that were dead. Gorilla had apparently died but come
| back in some capacity, Echo seems to be actively dying as PRs
| aren't being addressed, Buffalo was an option I looked at and
| is now archived
|
| Does the "just use the stdlib" mentality mean everyone is just
| rolling the glue layers on their own 1000x over?
| moomoo11 wrote:
| Can't speak for buffalo but there are many libraries that
| have not been updated in a while and there's a reason for
| that - they are complete.
|
| There is no reason to update them, this isn't nodejs that
| depends on one billion packages to do one thing where one of
| those changing basically affects any downstream users.
|
| The std library is awesome, backwards compatible, and lots of
| libraries just add onto it. The interfaces are compatible and
| you can just keep your code simple.
|
| I used to code a lot in Go. These days I'm back in node
| because it's just easier for me to move faster. I'm also not
| doing anything with concurrency, so haven't had a real need
| for Go
|
| I think for core critical services I would use Go again just
| I haven't needed to yet with my new project.
| BoorishBears wrote:
| I can appreciate feature complete software but ignoring PRs
| and literally archiving the Github project means it's dead,
| not complete.
| azuanrb wrote:
| I just started coding in Go professionally over a year now.
| So far, that's the pattern that I'm seeing as well. I'm not
| really a fan. Some common answers on why to not use a lib is
| because it's trivial to rollout your own.
|
| I like Go as a language but not so much on the community
| because of the reasons above. I just don't want to implement
| cache/cron for the n-th time again. I'd rather spending more
| time on building a new product instead, which is not the case
| when I'm using Go.
| arp242 wrote:
| There's a bunch of caching and cron libraries; you can pick
| one that best suit your needs, and you don't really need to
| implement that from scratch.
| tonyhart7 wrote:
| Yeah sadly this is the case for most webframework in Go, but
| if you want looking for something like that check beego
| cgg1 wrote:
| I found Pagoda required me to juggle too many things that were
| only loosely coupled together.
|
| GoBuffalo was great but as soon as I started using, it got
| archived :')
|
| Now I default to beego. It isn't as batteries included as a
| rails or django app, but there's enough there that I don't have
| to write as much boilerplate as with only the stdlib.
| Xeoncross wrote:
| It's often the change that happens with experience. Most
| developers join Go looking for their Laravel, Rails, Next.js,
| Spring framework. Because it's almost impossible to write
| something in those languages without a framework.
|
| In Go, the longer you use it, the more you realize "just use
| the stdlib" actually works for most things. A lot of these
| projects die because most Go devs either 1) need a mux and use
| httprouter or gorilla or 2) need a more robust multi-instance
| setup (go-kit, goa.design, smithy, etc..)
|
| Most big projects just don't use a MVC (or otherwise framework)
| as it's more work to use, update and understand than just
| writing your own glue for the libraries you do need.
|
| I might have explained this poorly, but I like to think of Go
| as a collection of packages where other languages are a
| collection of frameworks because the packages can't be used
| together easily and need organization on top to ensure
| everything works.
| ch4s3 wrote:
| > Because it's almost impossible to write something in those
| languages without a framework
|
| That doesn't sound right to me at all. I've definitely worked
| on some apps in Ruby that we basically just rack, and a few
| gems. And good lord, the Java landscape is full of in house
| architectures.
|
| > I might have explained this poorly, but I like to think of
| Go as a collection of packages
|
| This is exactly the approach a lot of JS apps took for a long
| time. That's what MERN(mongo/express/react/node) was about.
| ko_pivot wrote:
| As an Ent user, I'm surprised to see that as the default ORM. It
| is graph oriented for better and for worse. No composite primary
| keys for 'nodes' and minimal use of joins (no use?) in the
| underlying generated SQL. The DX is great, but GORM is a better
| default IMO.
|
| Nonetheless, great to see a new serious Go meta framework.
| endigma wrote:
| Ent heavily uses joins and does support multi field indices,
| you should read up on the docs. You can show the queries it's
| running using a debug client.
|
| It's not a Graph DB under the hood and uses any normal
| relational db quite normally beneath the DX
| ko_pivot wrote:
| > Ent heavily uses joins
|
| I'm specifically talking about this:
| https://github.com/ent/ent/issues/977.
|
| Devs assume that the `With` methods are adding join clauses
| but that is not typically the case.
|
| > does support multi field indices
|
| Composite primary keys are useful for reasons other than
| unique constraints and query speed. For example, CockroachDB
| uses the primary key to partition rows. Also, at scale, an
| extra multi-column index in addition to the primary key when
| the primary key alone could have sufficed can be a meaningful
| performance degradation.
|
| > not a Graph DB under the hood
|
| No it is not, but because it has a graph 'mindset' and does
| support Gremlin, traditional SQL folks expecting a
| lightweight ORM (such as Drizzle in the JS world) may not
| have a good time.
| brodouevencode wrote:
| Agreed - surprised gorm or something a little more mature
| wasn't used.
| ksajadi wrote:
| Same here. Go community has a tendency of not using frameworks
| as much (which I guess is confirmed by the lack of long term
| maintenance for a lot of Go frameworks), compared to say Ruby.
| I don't think that is a bad thing. We ended up using Gorm as
| one of the few frameworks for our web stack and I personally
| have mixed feelings about it.
|
| On the one hand, it's a very comprehensive ORM (support for
| different DBs and types of queries, joins, associations, etc).
| On the other hand, the documentation is not very good and often
| its behavior leaves you baffled (updates of columns and the
| associates in different times, for example).
|
| Overall, I think I'd still choose an ORM over writing SQL or
| quasi-SQL in the code for the sake of maintainability and
| readability of the code. GORM is the best one around but I wish
| there were more options.
| seneca wrote:
| I'm surprised to see HTMX as part of the front end stack. I like
| the idea of HTMX a lot, but I always got the impression it wasn't
| widely adopted. Do people use it for production applications
| often?
| sleepytimetea wrote:
| I discarded the HTMX stuff - the rest of the framework is
| nicely put together. The ability to queue worker items to asynx
| workers as well as the ability to add CLI commands to CRUD on
| the DB helped get a project going in quick time.
| ksajadi wrote:
| I'd really like to see a Go API backend / React frontend stack
| instead of using Go to render HTML directly.
| husarcik wrote:
| How does this compare to goravel?
___________________________________________________________________
(page generated 2024-09-30 23:01 UTC)