Pagoda: Rapid, easy full-stack web development starter kit in Go | Hacker News Reader

Pagoda: Rapid, easy full-stack web development starter kit in Go

github.com

140 pointstosh24 comments

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.

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

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

Agreed - surprised gorm or something a little more mature wasn't used.

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.

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?

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.

This is how things get adopted, it's not usually overnight.

HTMX has been more than good enough all along for the applications it can help with.

I don't use HTMX, but I use Turbo (which is what htmx is based on) in Rails daily for web apps that are in production at scale. Its in my opinion the future of web development.

htmx was not based on turbo: it was based on intercooler.js, which was released in 2013. At that time only turbolinks existed.

intercooler.js was based on the jquery load() method, pjax and angular 1’s use of attributes.

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.

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?

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.

I can appreciate feature complete software but ignoring PRs and literally archiving the Github project means it's dead, not complete.

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.

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.

Yeah sadly this is the case for most webframework in Go, but if you want looking for something like that check beego

No, definitely not common. GoBuffalo had some initial design frustrations, but overall it was such a solid and well maintained project. I was really surprise to discover that the Github repo was just quietly archived. Gophers slack has a channel for buffalo, and users still can provide some help, but still.

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.

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.

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

Looks impressive, and the docs are thorough. Nice work!

How does this compare to goravel?

I'd really like to see a Go API backend / React frontend stack instead of using Go to render HTML directly.

Reply on news.ycombinator.com