71–80 of 86 posts
Congrats! > One Binary > Build frontend apps along with your backend and ship everything in a single binary. I'm doing something similar and love it. Do you embed the entire `public` directory and then traverse the embed.FS to access the files in memory?
Earlier quoted context omitted.
I think an ORM like https://github.com/xo/xo with https://sqlc.dev/ as a fallback for complex queries will be a killer combo!
Two high level abstractions that compile into another high level abstraction called SQL. Why increase the complexity of something that's already a high level abstraction? Abstractions are about simplification. An orm and sqlc are not it.
Haha, moscow mule? I appreciate the alcohol name theme to go with all the other Go web frameworks. ;P
Earlier quoted context omitted.
Building a "Rails-like" framework in Go is honestly totally antithetical to the "Go way" of doing things. Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on. Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on. In my 8 years of writing Go, I w…
Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.
https://sqlc.dev/ makes your SQL the focus, not your Go-specific query code.
Earlier quoted context omitted.
Two high level abstractions that compile into another high level abstraction called SQL. Why increase the complexity of something that's already a high level abstraction? Abstractions are about simplification. An orm and sqlc are not it.
https://sqlc.dev/ is not an ORM. It's not an abstraction over SQL. It is a brilliant way to make SQL the focus of your models by generating the code from your SQL, instead of the other way around.
Am I do only one who hates frameworks that need a cli to get started?
Congrats! > One Binary > Build frontend apps along with your backend and ship everything in a single binary. I'm doing something similar and love it. Do you embed the entire `public` directory and then traverse the embed.FS to access the files in memory?
Here are the embed statements [3]. One thing to note is that embed.FS does not send 304 Not Modified status back, which is why I made a CachingEmbedFS [4].
[0] https://github.com/binwiederhier/ntfy/blob/main/Makefile#L77
[3] https://github.com/binwiederhier/ntfy/blob/main/server/serve...
[4] https://github.com/binwiederhier/ntfy/blob/main/util/embedfs...
Devs interested in this may also be interested in Pagoda [1], a rapid, easy full-stack web development starter kit in Go that I wrote. It leverages popular frameworks and modules that you can easily swap out, if desired. The readme contains full documentation and it's very much batteries-included. [1] https://github.com/mikestefanello/pagoda
Earlier quoted context omitted.
Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.
SQL is an incredible language with decades of theory and implementation behind it. I have never found an ORM to be better or faster or more useful than hand-written SQL for anything but the simplest of queries, and even then the benefit is debatable.
An ORM that didn't let you escape to SQL when you wanted to do more complex things would be a total failure, of course -- but to suggest that they're not more convenient for the 80/20 or even 90/10 use case is just really hard to understand. Must be NIH syndrome.
Earlier quoted context omitted.
Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.
ORM's help do simple stuff well enough, but they sure make hard tasks harder. Ever try to construct a 30 line report query using this years language flavor of an ORM? https://sqlc.dev/ makes your SQL the focus, not your Go-specific query code.
Client.find_by_sql("
SELECT * FROM clients
INNER JOIN orders ON clients.id = orders.client_id
ORDER BY clients.created_at desc
")