Our great sponsors
-
validator
:100:Go Struct and Field validation, including Cross Field, Cross Struct, Map, Slice and Array diving
-
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.
-
-
ozzo-validation
An idiomatic Go (golang) validation package. Supports configurable and extensible validation rules (validators) using normal language constructs instead of error-prone struct tags.
-
-
-
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.
This is where it gets spicy: I just don't get at all who ever though this struct-tag based validation library was a good idea https://github.com/go-playground/validator - and yet it's the most mainstream one. Try to implement your own type, you're up to register some global validation tag and repeat it every time you're using that type. I'm grateful https://github.com/go-ozzo/ozzo-validation exists, that's what I use. But it's still way behind the other things I mention, where in general, it's simply not possible to pass around an invalid struct - because it can't be built if it's invalid in the first place.
Node is a pain in the ass to work, Go is not, at least in my experience. https://go-app.dev/ syntax is 1000x better than whatever you can code in Node IMHO.
Your backend is perfectly capable of generating that DOM itself, it has the tools it needs right next to it, directly available without a round trip (database, authentication, third-party external REST interfaces) and you can couple that with https://htmx.org (or similar) to produce as SPA-y, dynamic-y front-end as you like, with the logic in one place (your backend), in a single programming language (instead of 2, with a crippled transport layer between them).
This is where it gets spicy: I just don't get at all who ever though this struct-tag based validation library was a good idea https://github.com/go-playground/validator - and yet it's the most mainstream one. Try to implement your own type, you're up to register some global validation tag and repeat it every time you're using that type. I'm grateful https://github.com/go-ozzo/ozzo-validation exists, that's what I use. But it's still way behind the other things I mention, where in general, it's simply not possible to pass around an invalid struct - because it can't be built if it's invalid in the first place.
And one of the biggest proposals to fix it hasn't had any comments in two years...
that leads to the noticeable performance results once comparing goroutines and node workers https://github.com/danielbh/node-worker-threads-vs-goroutines
I know. You're confusing "serverless" as a concept with the serverless framework which is what the original comment referred to