I prefer the more readable form. Although complexity checking programs indicate that nesting adds to complexity and the more readable form adds a nesting level.

In what little code I write I tend to try and do:
Which is probably hold over from cobol and liking seeing both sides of things...

Too late now but you can search interview questions for X company on glassdoor

Good luck

I sometimes do this, if only because sometimes making a positive condition into a negative one ends up convoluted and hard to understand. But it's not super common.

Neither is my writing code... I could tell it was going out of favor as do nothing statements used to be more common in languages.

I can't think of one that's more convoluted as a "not". In most languages it's a single exclam.

Or

Okay, the second one is tougher. I see your point.

Well that couldn't have gone better.

Toughest question was about closures, which I was over prepared for.

I have a co-worker who has a healthy holy crusade against 'elses' and I'm coming around to his way of thinking (sort-of-similar to what Rusty wrote above). So he would do:

It's not really about the syntax. It's the cognitive load.

Figuring out if !A is true is generally 'harder' than figuring out if A is true. This is especially true when combining multiple conditions.

One reason against the "else" condition is that it introduces the cognitive load of reversing all the if conditions before it. By making each of those conditions return, you get a bit simpler code to mentally process.

I will say, I'm really not sure how much this sort-of stuff really matters. Like are we talking tiny differences in average comprehension vs the massive differences in average comprehension that things like interfaces/apis, domain models, etc. can introduce.

Oh that's good to hear.

Well the side job finally ran out of money (supposedly) so they're laying me off until the get funding. Kind of relieved because it was stressful due to being so dysfunctional. But it was a nice extra paycheck for a year.

The funny thing is I had a feeling this was coming when the big boss demanded we switch from one proxy service (which I owned) that all web clients went through to talk to the other microservices - to a decentralized model with an auth microservice off to the side. They were scared of the old proxy system because they don't know how passport or express sessions work.

In the new decentralized model - each other microservice keeps a local session cache - which needs to be invalidated in complicated ways and also each microservice needs to report in to the actual session (which lives in the new auth microservice) so it doesn't time out. So it's 10x more complicated than the old proxy system. It still has all the complications of the express sessions and passport, but combined with a distributed session cache. It's going to be a scary black box.

It was a good run, that's for sure.

I am of the mind that APIs should not use sessions, doubly so for distributed service stuff. If you must, use something like JWT tokens as login keys, keep the data small, and avoid having to look it up from a 3rd party or maintain a cache.

But, you know, programming is hard, and authentication is among the hardest of things that people have to deal with on a daily basis.

You can't track user sessions or do other things with session timeout with stateless JWT - only if the user explicitly logs out.

Also lets say you have 10 parallel calls that get generated when the user first lands on the dashboard after logging in (which we do). Say one of those calls adds a flag to the user session that you want to be sent to the server with the next user interaction after the initial dashboard loads.

With stateful back-end sessions, at least you know when all the calls are done your new flag will be set before the next user interaction. With JWT if the last call that comes back isn't the one that adds the flag, your JWT token won't have the new flag for the next user interaction. So now the client has to do more work and consider more logic to synchronously load the flag call either before or after all the calls. Or send the flag data some other way.

Here's a good breakdown of the drawbacks of stateless JWT: http://cryto.net/~joepie91/blog/2016...-for-sessions/

I agree with most of their points. I use JWT as a shortcut essentially - it comes back from our external SSO provider and I ask them to include a few pieces of information that I've previously given them, so that I don't have to make a round trip every time someone presents the key to me. We're not super concerned with not being able to invalidate a key, although I suppose at some point that could be an issue. Our JWT keys only last for an hour though.

We don't really use them to store dynamic session data - that would clearly be a mistake.

In our services architecture, we don't really have a guarantee that every service can access a central cache server, so using sessions isn't going to work for us, unless those servers won't need what's in the session. This actually might be true for us, I don't know, because we don't really have any kind of use for cached session data.

We have tried to keep everything stateless as much as possible. We will probably be breaking some of that soon, in an effort to speed up certain things, but all of the breaking will be local - that is, a single service might keep a sessiony-kind-of-thing that only it cares about. In our case this is going to kind of be a "cursor" into a set of search results for a user. We have this persistent problem where someone comes in and does a search and wants *all* the results. They get page 1, then 2 and so forth. There may be hundreds of pages. So we end up doing the same damn search hundreds of times. There's also a chance that they can miss or duplicate data this way, since there is a gap in time between pages. But anyway.

After not having any work for a month, I ended up closing down the main contract I was working on. They left this review for me:

A well rounded individual that definitely knows the rights and wrongs of programming.

Back to the drawing board, looking for work, figuring out if I should call this most recent project (another) failure, etc.

So do your keys expire after an hour no matter what? If so, is re-authentication seamless to the user?

In our case (and most apps I've worked on), it's just too damn convenient to put stuff in the session for every other service to expect.

There's a re-issue procedure - I don't remember the details exactly, but you I think you exchange the old token for a new one. It's seamless to the user. You can only do this up to a point, I think, the details are handled by the SSO.

I agree that sessions are convenient but IMO they add a layer of complexity to the system that is going to cause you problems. You start having endpoints that behave differently depending on what's in the session. Testing and debugging becomes somewhere between difficult and impossible.

I think the biggest issue my work ran into was trying to do CSRF in pure stateless mode.

I'm curious why you use CSRF on an API, presuming that's what we're talking about.

What CSRF is for is to ensure that a POST comes from a form from "your" site, prepared by you. But API endpoints aren't typically POST targets, so I'm not really sure what the point of using CSRF is. If you're trying to control who can access your API, I think you want CORS. (I think CORS is a little silly too, frankly)

If he didn't mean CORS I'm definitely confused.

wait why aren't API endpoints POST targets? isn't it standard to do:

GET /resources/ - list of things
POST /resources/ - save new thing

or maybe we've been doing rest wrong

Yes, you can post to APIs.

But all the CSRF protection I've seen is designed to protect you from a specific type of exploit. You own site A and someone else owns site B. site B has a form that posts to your site, so that when someone clicks "save" or whatever, it hits your site, site A, instead of site B. If the user is logged in via a session or something, then it'll post to your site as them. site B can trick them into favoriting a post or deleting something etc.

The traditional protection is to require forms to post a special form variable that can be verified by your site.

I suppose "csrf" is a general term (cross site request forgery), I just think of it as a specific type of thing. CORS probably counts as a system designed to thwart csrf.

But I don't know what specific problem you'd have with stateless APIs and csrf. I think the Django csrf protection uses a cookie, which would be a problem with stateless APIs, but, it protects against these form attacks, you don't need it for API stuff (you can/should use CORS)

I'm pretty rusty on my front end work, but I don't think it needs to be a form. You can just as easily pass the token value to the front end and then include it in post requests back to the API.

CSRF needs a stateful handshake between the client and server, there's no other way to do it afaik.

CORS doesn't need to be stateful but can get tricky if you need to white-list some domains but not all. You have to dynamically set your CORS headers based on the request host.

CORS only applies to AJAX POST, PUT or DELETE. On a GET or a straight HTTP form POST the browser doesnt' check for CORS.

As part of CORS you also have to return an empty 200 reply to an OPTIONS request. Then after seeing that the browser will submit the ajax form. Not all browsers do this part, I know Chrome does.