Our great sponsors
-
-
fasthttp
Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Encore
Encore is the Backend Development Platform purpose-built to help you create event-driven and distributed systems.
It goes back to, what is a framework and what qualifies as a big framework here. I think classic rails isn't the fit, but something that's an extension of gRPC definitely works. What gets handcrafted is a lot of layers around gRPC or far more stuff around HTTP.
When I'm working on personal projects, frameworks don't make sense for me. When I'm trying to engineer something at scale e.g https://m3o.com then I need that standardisation at the platform layer, the framework layer, the API layer.
"You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now."
In Go, not necessarily, because net/http actually is what many languages would call a "minimalist framework".
There's a sense in which pretty much everyone here is right. You do need a framework in the general sense; you can't expect to just throw someone a TCP socket and get reasonable work out of them because the web is very complicated nowadays. But the reason why you can "do without a framework" in Go is that it is already a minimal one of its own, and in particular, that "minimality" focuses on providing a mechanism for composing various bits of HTTP code together.
So, do you need CSRF protection? Go grab this: https://pkg.go.dev/github.com/gorilla/csrf It operates with the integrated net/http Go framework to provide CSRF protection. You are objectively not abandoning the ability to have community-written CSRF protection when you go "frameworkless" in Go. Gorilla in general provides lots of mix-and-match pieces: https://www.gorillatoolkit.org/ , like cookie signing: https://pkg.go.dev/github.com/gorilla/securecookie
I think calling Go "no framework" is kind of misleading, because I get what you're saying, but the standard library is not the "no framework" option. The "no framework" option is more like using https://github.com/valyala/fasthttp , which is its own server implementation with an incompatible API that does in fact remove you from the community code, other than the code that works only with that server.
Don't over-read my post. I am merely saying that Go essentially ships with a minimal framework and so it is misleading to say or think of it as being "frameworkless", not that it is mandatory to use it and all other things on top of it are a bad idea. There are times and places to want large, preconfigured packages of additional functionality. But if there are times and places where it is not desirable, Go does come with a minimalist option by default. It is a pretty good, not-very-opionated option suitable for a standard library, where development is slow and there's not much room for experimentation in what a "full" web framework should look like.
The standard library minimalist framework even makes the other frameworks pluggable. You can, for instance, write an API website, then realize that if you need a conventional HTML website, you can plug in a framework for that part, but leave the API part as-is, simply by routing the API URLs to the existing API code while routing the HTML website to the http.Handler provided by the framework. Even "not using an additional framework" is not the commitment it may be in other environments, because the net/http foundation is still there.
Well said. The 'no big framework' thing works for Go because the Go standard library defines a common way for dealing with HTTP. The difficulty, then, is identifying 3rd party packages that play well with the rest of the ecosystem.
You can see the opposite in projects like Echo, Gin, Beego, etc., that eschew the standard library to various degrees and try to build the kitchen sink themselves. Sometimes this works! Echo is very popular, despite having nonstandard handlers and context. An absolute Go newbie is probably going to have an easier time using it than trying to pick out the best collection of libraries themselves.
I would love to see more 'blessed stack' collections that tie together good libraries such as this one: https://github.com/mikestefanello/pagoda
What if any is the relationship between https://m3o.com/ and https://micro.dev/ ?
We used Micro to build and offer Micro services on M3O. Every API to you see there is powered by the open source equivalent Micro service here https://github.com/micro/services
Create T3 app https://github.com/t3-oss/create-t3-app
I was fairly new to "modern" web dev, starting a project, and went with Django because I had more Python experience than anything else. But I found templates very lackluster and poor to integrate with all the different JS ecosystem libraries people are creating to do very cool things on the frontend. Unfortunately, hooking React up to Django is a mess and most people doing this are still 5 years behind in React-land. Are you going to hybrid some template and some React? Are you going to containerize your django and react build system together?
Basically, I wanted a robust frontend ecosystem, well integrated to a simple backend (no Spring, Django-Rest-Framework monstrosities).
That led to React -> Next.js -> Typescript backend -> the rest of the niceties around it like Prisma (ORM-ish)
Create T3 App simplifies all the setup into a template and is extremely fast to start building features. tRPC is an optional nicety.
For security/safety sensitive tasks, you should be using checklists e.g. [1] so you don't need to remember. Pilots use pre-takeoff checklists to reduce chances of human error. Likewise, you should not assume the framework will give you proper defaults.
[1] https://github.com/0xRadi/OWASP-Web-Checklist
Encore is a Go framework for cloud backend development, that comes with a set of tools built in to integrate the entire development process. With Encore cloud infrastructure is provisioned automatically from application business logic.