4 ms·

The more you get to know Go's stdlib the less and less youll think a web framework is necessary. Youll find that utilizing http Round Tripper along with the Ha

The more you get to know Go's stdlib the less and less youll think a web framework is necessary. Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy. Youll eventually dig into filepath and path methods for extracting path parameters from url paths. And logging and recovery will be a concept youll need to extend outside of just http and into the rest of your application. I totally advise new comers to use a web framework, but in the long run, you probably wont want too.

nsomaru 6y ago
What path to this enlightenment would you recommend to one who has cut his teeth and delivered many projects (over many years) in Rails/Django?
- kortilla 6y ago
  This is a side effect of go’s lack of meta programming to be honest. So much magic that is possible in rails/django/etc is just not possible in golang. This leads to go web frameworks being sort of semi-hard mountainous turds of code generation. You’ll want to stick to stdlib after sifting through them and deciding they aren’t worth it.
  - ampdepolymerase 6y ago
    After Django, writing database code manually in Go is not fun at all.
  - jchw 6y ago
    Admittedly I liked Django's database layer but using it in Real World production has also left me feeling kind of... eh. Having automigrations and an ORM is fantastic 90% of the time. The other 10% of the time almost ruins the magic entirely. The ORM is not a panacea like SQLAlchemy nearly is. Issues with migrations in production can get surprisingly tricky surprisingly quick. The rest though I do not miss at all. Middleware patching attributes directly into the request object? Python's sad excuse for incremental typing? Ignoring the database bits of Django I struggle to find anything that I don't enjoy doing more in Go. I was a HUGE fan of Django REST Framework and assorted boilerplate for a long time, but I am so extremely glad to be off that ride. Yeah, it lets you do really cool, complex things succinctly and cleverly. The problem is that it lets you do really cool, complex things succinctly and cleverly. The cleverness becomes the enemy. I now have learned to appreciate code that is utterly stupid, obvious, nearly braindead. Every codepath is screaming at you. That is Go in a nutshell. if err != nil { ... } ad nauseam. Sounds terrible... but it kind of isn't. There are some things I would not use Go for. Game development is one of those things. Web servers, though? If you are going to be doing serious work in production environments, Go is absolutely among the best choices. I am still, however, looking forward to trying Rust more and more. My initial impressions with Rocket.rs have been lukewarm. (One thing that is bothersome but not quite a deal breaker is compile times. A lot of crates make the experience bad almost immediately.)
    - alexchamberlain 6y ago
      Using SQLAlchemy has been my biggest (technical) regret in my current project; it was great at first, but overtime it's made testing a lot harder and session/object management has led to subtle bugs.
      - jchw 6y ago
        I feel like it’s a great tool to have available because it has solutions for everything you might want, but I found myself preferring it more for scripting than for application servers. Never quite figured out how to properly handle database sessions, really.
      - danjac 6y ago
        Getting Flask/Pyramid + SQLAlchemy + pytest to play nicely with sessions, transactions and rollbacks has often been the one thing that made me go "screw it" and start over with Django.
      - ywei3410 6y ago
        Speaking from experience, session/object management is always tricky with ORM's. SQLAlchemy has been good for us; but the usage has been very, very disciplined and doesn't look idiomatic.
deleted 6y ago
[deleted]
krainboltgreene 6y ago
It sounds like what you've done is used a bunch of tools that weren't designed with web development in mind and made them do those things. That seems like not only a security issue but also an absolute mess to get into after you're done.
- mrmonkeyman 6y ago
  You're not getting it.
- buzzerbetrayed 6y ago
  100% correct. That sounds like a nightmare. Most backend web devs don't have the desire/expertise to handle all the intricacies of web security.
thiht 6y ago
I've been writing Go services in production for ~5 years and I don't really agree. Go Web frameworks are usually what used to be referred as micro frameworks. They're great because they embed the bare minimum making the writing experience tolerable. What you say is true, it's easy to do with stdlib, but it's neither enjoyable not readable. A router lib and a validation lib are realistically still needed. The same applies for the sql package, it's basically unusable without at least something like sqlx.
pjmlp 6y ago
Here is the thing, I have been doing Web development alongside native for a couple of decades now. This Go enlightment seems to only touch those that don't realize that programming to interfaces was already a thing back in Objective-C and WebObject days, or using Smalltalk categories (later formalized as traits in Pharo). Also that languages like Java and .NET also have a similar Http server on their standard library since Java 6 (2006) and .NET 2.0 (2002). The reason we don't use them beyond toy examples, is that they don't scale when things start getting hard and something like IIS, ngix or similar is called into action.
- AsyncAwait 6y ago
  > The reason we don't use them beyond toy examples, is that they don't scale when things start getting hard and something like IIS, ngix or similar is called into action. Hmm? You seem to be mixing two things here. Nobody is suggesting not using NGINX/Caddy etc. The comment was about being able to go very far with just the standard library.
- bokwoon 6y ago
  Could you explain what you mean by things start getting hard? Why did the languages you mentioned stop using their HTTP interfaces?
  - pjmlp 6y ago
    Because that is just the basic, when doing web applications, besides handling HTTP requests you need: - workload distribution - security and authentication - role management via some form of directory services like LDAP or AD - running tasks in background in response for certain events - mapping into various kinds of databases and information sources - handling caching - have a way to manage reusable components of html/css/js + respective backend code Yep one can make use of libraries to achieve all of that, but then most likely they don't compose in an easy way, nor make an eco-system.
willsewell 6y ago
I see this sentiment a lot in the Go community. I think it is reasonable in some cases, but there are many use cases (vanilla CRUD web apps) where a web framework is really helpful. The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on. It feels like a waste of time implementing these "solved problems" from scratch, but the biggest problem is how easy it is to introduce security vulnerabilities when implementing from scratch, or forgetting to do so. It’s nice to learn concepts from first principals by using the standard library. But once I know how these things work, I’d rather rely on someone else’s battle tested code and best practices. Yes, you can add in separate libraries to solve these specific problems, but they are less likely to compose as well as they would in a framework. On top of this, each time you pull in a new library you have to spend time evaluating it. When I use a framework I don't have to think.
- lelandbatey 6y ago
  I find that this is a totally fine trade off to make until it isn't, and by then you're completely confined by your choice of framework. Better to use libraries built to compose around interfaces taken from the standard library so you lose none of the control. I'll also emphasize that doing it this way does make discovering the initial pieces harder than if they're all in one framework together, but I find the slight increase in research yields orders of magnitude improved results once your code starts to age past the two year mark and you reap all the reliability and composibility of the standard library. Also, here's a list of out-of-the-box library implementations for all the features you mentioned: Sessions: https://github.com/gorilla/sessions https://github.com/gorilla/sessions CSRF: https://github.com/gorilla/csrf https://github.com/gorilla/csrf User auth: https://github.com/qor/auth https://github.com/qor/auth
- boomlinde 6y ago
  > The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on. That's not the sentiment expressed here. To implement these things from scratch is not the only alternative to using a framework.
- sudhirj 6y ago
tyingq 6y ago
There's a lot of non-obvious stuff to cover, like getting all the caching related headers right, vary headers, relationships between proxy headers and logging, thwarting path traversal, dealing with file uploads, and so on.
morelisp 6y ago
> Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy. I thought RoundTripper was a purely client interface - am I missing something? Servers instead have the base Handler, net.Listeners, ConnState, BaseContext, ConnContext etc.

nsomaru 6y ago

What path to this enlightenment would you recommend to one who has cut his teeth and delivered many projects (over many years) in Rails/Django?

kortilla 6y ago
This is a side effect of go’s lack of meta programming to be honest. So much magic that is possible in rails/django/etc is just not possible in golang. This leads to go web frameworks being sort of semi-hard mountainous turds of code generation. You’ll want to stick to stdlib after sifting through them and deciding they aren’t worth it.
- ampdepolymerase 6y ago
  After Django, writing database code manually in Go is not fun at all.
- jchw 6y ago
  Admittedly I liked Django's database layer but using it in Real World production has also left me feeling kind of... eh. Having automigrations and an ORM is fantastic 90% of the time. The other 10% of the time almost ruins the magic entirely. The ORM is not a panacea like SQLAlchemy nearly is. Issues with migrations in production can get surprisingly tricky surprisingly quick. The rest though I do not miss at all. Middleware patching attributes directly into the request object? Python's sad excuse for incremental typing? Ignoring the database bits of Django I struggle to find anything that I don't enjoy doing more in Go. I was a HUGE fan of Django REST Framework and assorted boilerplate for a long time, but I am so extremely glad to be off that ride. Yeah, it lets you do really cool, complex things succinctly and cleverly. The problem is that it lets you do really cool, complex things succinctly and cleverly. The cleverness becomes the enemy. I now have learned to appreciate code that is utterly stupid, obvious, nearly braindead. Every codepath is screaming at you. That is Go in a nutshell. if err != nil { ... } ad nauseam. Sounds terrible... but it kind of isn't. There are some things I would not use Go for. Game development is one of those things. Web servers, though? If you are going to be doing serious work in production environments, Go is absolutely among the best choices. I am still, however, looking forward to trying Rust more and more. My initial impressions with Rocket.rs have been lukewarm. (One thing that is bothersome but not quite a deal breaker is compile times. A lot of crates make the experience bad almost immediately.)
  - alexchamberlain 6y ago
    Using SQLAlchemy has been my biggest (technical) regret in my current project; it was great at first, but overtime it's made testing a lot harder and session/object management has led to subtle bugs.
    - jchw 6y ago
      I feel like it’s a great tool to have available because it has solutions for everything you might want, but I found myself preferring it more for scripting than for application servers. Never quite figured out how to properly handle database sessions, really.
    - danjac 6y ago
      Getting Flask/Pyramid + SQLAlchemy + pytest to play nicely with sessions, transactions and rollbacks has often been the one thing that made me go "screw it" and start over with Django.
    - ywei3410 6y ago
      Speaking from experience, session/object management is always tricky with ORM's. SQLAlchemy has been good for us; but the usage has been very, very disciplined and doesn't look idiomatic.

deleted 6y ago

[deleted]

krainboltgreene 6y ago

It sounds like what you've done is used a bunch of tools that weren't designed with web development in mind and made them do those things. That seems like not only a security issue but also an absolute mess to get into after you're done.

mrmonkeyman 6y ago
You're not getting it.
buzzerbetrayed 6y ago
100% correct. That sounds like a nightmare. Most backend web devs don't have the desire/expertise to handle all the intricacies of web security.

thiht 6y ago

I've been writing Go services in production for ~5 years and I don't really agree. Go Web frameworks are usually what used to be referred as micro frameworks. They're great because they embed the bare minimum making the writing experience tolerable. What you say is true, it's easy to do with stdlib, but it's neither enjoyable not readable. A router lib and a validation lib are realistically still needed. The same applies for the sql package, it's basically unusable without at least something like sqlx.

pjmlp 6y ago

Here is the thing, I have been doing Web development alongside native for a couple of decades now. This Go enlightment seems to only touch those that don't realize that programming to interfaces was already a thing back in Objective-C and WebObject days, or using Smalltalk categories (later formalized as traits in Pharo). Also that languages like Java and .NET also have a similar Http server on their standard library since Java 6 (2006) and .NET 2.0 (2002). The reason we don't use them beyond toy examples, is that they don't scale when things start getting hard and something like IIS, ngix or similar is called into action.

AsyncAwait 6y ago
> The reason we don't use them beyond toy examples, is that they don't scale when things start getting hard and something like IIS, ngix or similar is called into action. Hmm? You seem to be mixing two things here. Nobody is suggesting not using NGINX/Caddy etc. The comment was about being able to go very far with just the standard library.
bokwoon 6y ago
Could you explain what you mean by things start getting hard? Why did the languages you mentioned stop using their HTTP interfaces?
- pjmlp 6y ago
  Because that is just the basic, when doing web applications, besides handling HTTP requests you need: - workload distribution - security and authentication - role management via some form of directory services like LDAP or AD - running tasks in background in response for certain events - mapping into various kinds of databases and information sources - handling caching - have a way to manage reusable components of html/css/js + respective backend code Yep one can make use of libraries to achieve all of that, but then most likely they don't compose in an easy way, nor make an eco-system.

willsewell 6y ago

I see this sentiment a lot in the Go community. I think it is reasonable in some cases, but there are many use cases (vanilla CRUD web apps) where a web framework is really helpful. The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on. It feels like a waste of time implementing these "solved problems" from scratch, but the biggest problem is how easy it is to introduce security vulnerabilities when implementing from scratch, or forgetting to do so. It’s nice to learn concepts from first principals by using the standard library. But once I know how these things work, I’d rather rely on someone else’s battle tested code and best practices. Yes, you can add in separate libraries to solve these specific problems, but they are less likely to compose as well as they would in a framework. On top of this, each time you pull in a new library you have to spend time evaluating it. When I use a framework I don't have to think.

lelandbatey 6y ago
I find that this is a totally fine trade off to make until it isn't, and by then you're completely confined by your choice of framework. Better to use libraries built to compose around interfaces taken from the standard library so you lose none of the control. I'll also emphasize that doing it this way does make discovering the initial pieces harder than if they're all in one framework together, but I find the slight increase in research yields orders of magnitude improved results once your code starts to age past the two year mark and you reap all the reliability and composibility of the standard library. Also, here's a list of out-of-the-box library implementations for all the features you mentioned: Sessions: https://github.com/gorilla/sessions https://github.com/gorilla/sessions CSRF: https://github.com/gorilla/csrf https://github.com/gorilla/csrf User auth: https://github.com/qor/auth https://github.com/qor/auth
boomlinde 6y ago
> The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on. That's not the sentiment expressed here. To implement these things from scratch is not the only alternative to using a framework.
sudhirj 6y ago

tyingq 6y ago

There's a lot of non-obvious stuff to cover, like getting all the caching related headers right, vary headers, relationships between proxy headers and logging, thwarting path traversal, dealing with file uploads, and so on.

morelisp 6y ago

> Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy. I thought RoundTripper was a purely client interface - am I missing something? Servers instead have the base Handler, net.Listeners, ConnState, BaseContext, ConnContext etc.