6 ms·
It seems like there are three classes of "web problems" to solve: (1) The absolute basic "hello world" stuff at the outset. How to route URL's to their handle
by StevePerkins 10y ago
It seems like there are three classes of "web problems" to solve:
(1) The absolute basic "hello world" stuff at the outset. How to route URL's to their handlers, how to render dynamic templates, how to map data structures to and from JSON, etc.
(2) The problems that are one level up in sophistication, but still common to nearly all web apps. How to handle authentication (username/pass, OAuth/JWT, etc), how to manage session state or the lack thereof, juggling synchronous blocking operations with async background ones, etc.
(3) Really advanced issues that are probably specific to your industry domain or specific application, and aren't necessarily common to others (e.g. how to isolate this medical data for HIPPA compliance).
I don't want to poo-poo this website, it's nice. But in my mind, the world is already flooded with Category #1 examples. At the same time, Category #3 doesn't really lend itself to this sort of thing at all. So what the world really needs is more Category #2 stuff.
Example: What are the patterns available for authentication, including their advantages and drawbacks?
If you do your own authentication with usernames and passwords... then you have to either have to pass them every time and re-auth every request, or else store a session cookie on the client side and find some way share it across all your server-side instances (or use a load balancer with sticky sessions). That's material for 3 or 4 patterns right there!
If you use OAuth with JWT tokens, then you can (maybe) avoid the need to store any session state on the server side. But how do you explicitly "logout" prior to the JWT expiration? Another 3 or 4 patterns down this route!
Category #1 is fun and easy to write about, and a lot af that material comes from newbies who are writing in order to teach themselves. But Category #2 is the brick wall that people always run into in the real world... and because you need a lot of real experience to write about that class of problems, there's a vacuum of available material out there.
- tptacek 10y agoApart from the JWT thing (please avoid JWT if possible), I agree with this comment 100%. Things I'd like to see in a Go web app example site: 1. Examples of using context values to pass things selectively to handlers. 2. An arbitrary trivial middleware example, like a specialized request logger, just to demonstrate Go middleware. 3. A Rails/Django-style session token done in the same middleware style. 4. Giving requests a notion of "current user". 5. Simplified user-visible vs. developer-visible error handling. It's too much to ask for ORM-style database query examples, I know, but that too would be nice.
- jankiel 10y agoCan you expand on JWT thing? Why should it be avoided?
- StevePerkins 10y ago> please avoid JWT if possible That's why this Category #2 stuff is so important. People can agree without much controversy what "best practice" is for the Category #1 stuff, but at the next level it's just blog posts and discussion thread comments passionately arguing opposite statements. I'm curious... if not JWT, then how would you approach the problem of authenticated sessions without server-side state? (assuming you aren't rejecting the overall premise entirely) If you track authentication with a server-side session, then you have to either: (1) Setup a backing store for your session state (e.g. Redis, relational database, proprietary app server solution, etc). Share the backing store across all instance nodes in your server-side cluster. Tune the inevitable performance issues and point-of-failure risks, and expect the worst if you're using a proprietary thing (they're all terrible). (2) Use a hardware solution. Have the load balancer always route a given client's requests to the same server-side instance. Deal with failover scenarios when that instance goes down, have to drain traffic every time you want to do a deployment, etc. JWT's ugly, but no uglier than either of those! Always on the lookout for other recipes...
- tptacek 10y agoThe choice isn't "JWT" or "server-side sessions". It's client-side sessions versus server-side sessions, and JWT is just one (bad) option among many for client-side sessions. 'lvh and I are working on a piece about this for our clients, so I want to be careful not to write a crappy version of it in an HN comment first. But I think you'll find something close to a consensus on JWT/JWS/JWE/JWK among crypto engineers of our ilk. I guess I'd close by saying: if you were writing a Rails app, it's almost certainly the case that you'd be better off just using ActiveSupport::MessageEncryptor to create an encrypted token than you would be building a shambolic equivalent of MessageEncryptor in JWT.
- ownagefool 10y ago