Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Go web dev notes

jvns.ca

Post reply on HN
Print view View original

21–30 of 154 posts

Re: Some Go web dev notes

#21

Post by leetrout »

tmpz22 wrote: post #18
joshlemer wrote: post #10

Earlier quoted context omitted.

I stumbled on this Go starter project that has enough batteries included to get you started I think. You might find it useful https://github.com/mikestefanello/pagoda

Right and mikestefanello/pagoda seems like a comprehensive framework combining the labstack/echo/v4 routing framework and entgo.io/ent "ORM" - among other things like HTMX and Bulma. That is a highly opinionated grouping of tools that gets you to a poor persons version of a full stack framework that many in the Go community would flat out reject.

I really don't understand the hate for a framework in "the community". I had stayed away from Go for about 3 years and I posted on r/golang asking if anything had popped up like a django in go and got nothing but hate.

I chock it up to people enjoy writing the same boiler plate stuff over and over in their paid jobs where they have the time to do it.

To your point, I've got my own set of libraries that I think are The Best™ for all my reasons that at least keep me productive.

Echo for the routing... sqlc for the db interface... I actually _love_ gomega and ginkgo for BDD but it makes people actually angry so I settle for testify and for logging we have slog now but I usually grab the logging lib from charm bracelet for nice colorized, leveled logging.

Re: Some Go web dev notes

#22

Post by returningfory2 »

gwd wrote: post #20

> I learned the hard way that if I don’t do this then I’ll get SQLITE_BUSY errors from two threads trying to write to the db at the same time. OK, here's a potentially controversial opinion from someone coming into the web + DB field from writing operating systems: 1. Database transactions are designed to fail Therefore 2. All database transactions should done in a transaction loop Basically something like this: http…

I don't think this controversial. Retrying failed transactions is a common strategy.

Re: Some Go web dev notes

#23

Post by joshlemer »

tmpz22 wrote: post #18
joshlemer wrote: post #10

Earlier quoted context omitted.

I stumbled on this Go starter project that has enough batteries included to get you started I think. You might find it useful https://github.com/mikestefanello/pagoda

Right and mikestefanello/pagoda seems like a comprehensive framework combining the labstack/echo/v4 routing framework and entgo.io/ent "ORM" - among other things like HTMX and Bulma. That is a highly opinionated grouping of tools that gets you to a poor persons version of a full stack framework that many in the Go community would flat out reject.

And since it isn't a "framework" but rather just a wired up collection of libraries, it would be pretty simple and even a good learning process to change out the couple of libraries one doesn't like (say, in case they prefer not to use ent, and backlite).

Re: Some Go web dev notes

#24

Post by okibry »

yegle wrote: post #13

It's sad https://pkg.go.dev/embed was not mentioned in a post about web development in Go :-) Having a true single binary bundling your static resources is so convenient.

Which time golang read file, build time or run time ?

Re: Some Go web dev notes

#25

Post by gwd »

returningfory2 wrote: post #22
gwd wrote: post #20

> I learned the hard way that if I don’t do this then I’ll get SQLITE_BUSY errors from two threads trying to write to the db at the same time. OK, here's a potentially controversial opinion from someone coming into the web + DB field from writing operating systems: 1. Database transactions are designed to fail Therefore 2. All database transactions should done in a transaction loop Basically something like this: http…

I don't think this controversial. Retrying failed transactions is a common strategy.

You're the first person I've heard say so. When I was learning DB stuff, there were loads of examples of things that looked at the error from a transaction. Not a single one of them then retried the transaction as a result.

The OP's comment is a symptom of this -- they did some writes or some transactions and were getting failures, which means they weren't retrying their transactions. And then when they searched to solve the problem, the advice they received wasn't "oh, you should be retrying your transactions" -- rather, it was some complicated technical thing to avoid the problem by preventing concurrent writes.

Re: Some Go web dev notes

#26

Post by jeffreyrogers »

leetrout wrote: post #15
jeffreyrogers wrote: post #5

Earlier quoted context omitted.

I like Go for this reason as well. In Python I found the Flask framework to be suitably unobtrusive enough to be nice to use (never liked Django), but deploying python is a hassle. Go is much better in that area. The error handling never bothered me either. I think if Go shipped better support for auth/sessions in the standard library more people would use it. Having to write that code yourself (actually not very har…

I am a Django apologist because I grew up with Django. So with that being said, I'm not out to convert you but I am genuinely curious what you don't like about it. Promise I won't refute anything I just like to try to understand where it turned off folks. I don't like flask because it seems just easy enough to be really productive in the beginning but you eventually need most of the things Django gives you. So I woul…

It's opinionated in a way I dislike. I don't actually have anything against opinionated software--tailwind is very opinionated about how you should write CSS but I like it because it matches up with how my mind works. But I find Django very jarring. I can't point to a specific thing about Django, it's more that if I were to design a framework from scratch it would look nothing like Django, so I experience a lot of friction trying to shape my ideas about how to build an application into Django's way of doing it. I have the same problem with Rails as well.

I agree with you that Django provides most things that an application will eventually need, and if I were managing a team that was starting a project from scratch I think Django would be a reasonable choice, but aesthetically something about it irritates me.

Re: Some Go web dev notes

#28

Post by kolja005 »

jeffreyrogers wrote: post #5
codegeek wrote: post #3

What I love about Go is its simplicity and no framework dependency. Go is popular because it has no dominating framework. Nothing wrong with frameworks when it fits the use case but I feel that we have become over dependent on framework and Go brings that freshness about just using standard libraries to create something decent with some decent battle tested 3rd party libraries. I personally love "library over framewo…

I like Go for this reason as well. In Python I found the Flask framework to be suitably unobtrusive enough to be nice to use (never liked Django), but deploying python is a hassle. Go is much better in that area. The error handling never bothered me either. I think if Go shipped better support for auth/sessions in the standard library more people would use it. Having to write that code yourself (actually not very har…

I'm curious in what sense you find Python difficult to deploy? My company has tons of Python APIs internally and we never have much trouble with them. They are all pretty lightly used services so it it something about doing it on a larger scale?

Re: Some Go web dev notes

#29

Post by imiric »

There are some good tips here.

As for sqlc, I really wanted to like it, but it had some major limitations and minor annoyances last time I tried it a few months ago. You might want to go through its list of issues[1] before adopting it.

Things like no support for dynamic queries[2], one-to-many relationships[3], embedded CTEs[4], composite types[5], etc.

It might work fine if you only have simple needs, but if you ever want to do something slightly sophisticated, you'll have to fallback to the manual approach. It's partly understandable, though. It cannot realistically support every feature of every DBMS, and it's explicitly not an ORM. But I still decided to stick to the manual approach for everything, instead of wondering whether something is or isn't supported by sqlc.

One tip/gotcha I recently ran into: if you run Go within containers, you should set GOMAXPROCS appropriately to avoid CPU throttling. Good explanation here[6], and solution here[7].

[1]: https://github.com/sqlc-dev/sqlc/issues/

[2]: https://github.com/sqlc-dev/sqlc/issues/3414

[3]: https://github.com/sqlc-dev/sqlc/issues/3394

[4]: https://github.com/sqlc-dev/sqlc/issues/3128

[5]: https://github.com/sqlc-dev/sqlc/issues/2760

[6]: https://kanishk.io/posts/cpu-throttling-in-containerized-go-...

[7]: https://github.com/uber-go/automaxprocs

Re: Some Go web dev notes

#30

Post by nasretdinov »

okibry wrote: post #24
yegle wrote: post #13

It's sad https://pkg.go.dev/embed was not mentioned in a post about web development in Go :-) Having a true single binary bundling your static resources is so convenient.

Which time golang read file, build time or run time ?

embed package allows to embed assets directly into the binary, so the files are read once during build time and then you can access them as e.g. a byte slice, a string, or a special FS object that acts like an in-memory file system
Post reply on HN