[gf000]

We are talking about Laravel. The primary way to interact with your app is either via HTTP requests or not, there is not much in-between, so I don't really get your point.

There is a very well defined architecture for the CRUD part that gives itself to "frameworkification". That part is free to call out to any other business code you deem necessary, this is such a surface you can trivially build on. Your software does complex route planning? Sure, have an endpoint that specifies a config and call out to however complex logic you need, and return the result (or just that you are working on it, and another endpoint will later be available for the results or whatever). But not everything gives rise to such stable surfaces.

> writing a basic CRUD in Go

Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization, CSRF, preventing injections, session cookies, authN/authZ, easy database CRUD operations?

[bborud]

> Well, what about converting strings to business data structures safely? > What about complex JSON parsing, serialization, CSRF, preventing > injections, session cookies, authN/authZ, easy database CRUD operations?

So you are saying this is only possible if you use a large framework? You cannot do this with libraries? That's a very odd position.

JSON has never been a problem as it is part of the standard library. And there are lots of libraries to extend the functionality if you need something the standard library doesn't offer.

Heck, Go even has ASN.1 in the standard library so I can write custom serialization of certificates to satisfy fiddly crypto components that only work with certain representations. And it was surprisingly easy to do. If it is one thing Go is really good for, it is writing robust code for transforming data.

Learn to do things using the standard library first. Then learn what libraries to add and keep a collection of snippets and notes on how to use them so you can apply them quickly when you need them. Learn once, take notes, use again.

[whstl]

> Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization

Those are solved problems in Go's standard library. And let's be fair: while some frameworks do a lot of stuff, the majority is very bare bones and just automate serialization, so compare with the average. And some even cause even more problems than they solve (Rails mass-assignment).

> CSRF

Available in several routers, if you choose to use a custom one, or in the form of middleware if necessary.

> preventing injections

Which kind? For SQL, database/sql provides the tools necessary for avoiding SQLi, and requires the same care/discipline you'd need on a big-framework app. For XSS just use the builtin facilities of html/template rather than reinventing the wheel.

> session cookies

Library, if it's not in the router of your choosing.

> authN/authZ

Once again, let's be fair. AuthN didn't exist on Rails for 20 years, for example (and is still quite bare bones compared to libraries). AuthZ still doesn't. In Spring and .NET both also require libraries. So just use a Library in Go?

> easy database CRUD operations?

What's that, ORMs? SQL Generators? They do exist in Go.

[bborud]

ORMs tend to make things more complicated and usually slower. I'd recommend using SQLX. It is a nice half-way point. It eliminates most boilerplate, is going to be sufficiently performant for 99% of cases, and it reduces a lot of cases down to between 1 and 5 lines of code for simple CRUD operations. (Where it isn't fast enough you can easily fall back to using the SQL drivers directly.

[whstl]

I agree 100% with you, and this is how I build my stuff too!

I was just pointing out that framework-less Go projects can have SQLX, ORM, etc, if you want to!