I've never been in a position to pick an inheritance paradigm - and generally just use whatever the framework dictates. Mostly I just rarely use inheritance in JS. I kick-ass when this question comes up in interviews obviously.

Tell me if there's a fix for this, and if not, if my proposal makes sense:

I have cloudfront set up to serve our UI from S3. I have it set to proxy our API at, say, /api/. Works great. The UI is a react app and routes "look" like URLs but you know, it's a SPA so they all just refer to the same page (/index.html).

So I think like most people we have a handler on cloudfront that says "if you get a 404, then display /index.html and return a 200". But this means that if the backend API returns a 404 then the caller gets index.html and a 200. I feel like there has to be a solution to this but I haven't found one (I tried modifying s3 to return index.html as it's error document but this doesn't seem to do anything useful)

So my proposal is essentially to have the backend API lie - have it return something OTHER than a 404. Then make cloudfront have an error handler for this that returns a generic "not found" json doc and a 404.

This sucks to me because it means any dev of the backend will have to be careful to return whatever the fake 404 code is. Not sure what else to do. (I was thinking of using 406 (Not Acceptable) as the fake error code but I'm not sure it matters)

We do the exact same thing with rerouting to index.html on 404. Otherwise you can't have deeplinking into a react app. Well not w/o precompiling the routes into pages, which is a mess.

Our API goes to a different subdomain though so I don't have the problem you do. We have one cloudfront in front of the S3 bucket for the front end code, and a second cloudfront in front of the API Gateway.

The real solution is to use something other than cloudfront as your front-line delegator. I've never liked blindly rerouting to index.html.

you could set up a box running nginx as a proxy in front of the api and check for errors and put up whatever you want when you get an error

Every word of this is why I'm glad we're 100% on AWS. No boxes. No setting up. No proxies. No ingress controllers. No load balancers. No discovery. Nothing to babysit. No distros. No upgrades. No digging to find out what version of gcc comes with RHEL 7 and why it's incompatible with something.

I'll gladly trade the flexibility for not having that hassle.

The entrance to the site is cloudfront, which directs some traffic to s3 (for the UI) and some to our containers (for the api). Putting something in front of the api won't change anything, because the problem is how cloud front handles errors.

You have one error handler that handles errors for all "origins" (so, in this case, s3 and the api backend). s3 gives a 404 means that someone (probably) tried to get a UI route, which doesn't *physically* exist in s3, so we need to return index.html. If we do that then it forces us to treat 404s from teh API the same way.

Can you move the API to another subdomain and use a separate cloudfront?

Otherwise what he's saying is right. When I was researching this - the answer is that cloudfront->S3 really isn't intended as a fully-fledged static content webserver. It works but has very limited capabilities compared to niginx or apache (for the react deep-linking problem, both of those can use fine-grained rules instead of a blanket reroute of 404 to index.html).

The answer might be something like cloudfront->nginx->s3. Or just WAF->nginx->S3 - but I dunno I haven't looked into that at all.

Yes and no. They used to be separate. I don't really want to get into it but for reasons outside my control that's not really a great option for us at the moment.

Replacing s3 with "something else" might be a reasonable solution.

For the short term I'm going to try this returning-a-406-from-the-api thing, which I am doing with middleware (so devs will still return a 404, it'll get turned into a 406 automatically when returned from the web app)

like ideally the way it would work would be
/assets -> s3
/api -> our api backend
everything else -> front end index.html

Yep - that's beyond cloudfront's capabilities.

Yes and no - I can just make a thing which is an ecs task who's sole job in life is to hand out copies of index.html, make that an origin, and make it the default. Then get rid of the error handler.

That sounds simple and totally not klugey.

I think Lambda@Edge can handle your use case

https://aws.amazon.com/about-aws/wha...m-your-origin/

So, you know, this is the job

It looks like it might. I mean I can think of like 9 ways to that AWS could have made it possible and it's a bit of a head scratcher that this is what they landed on, but ok

Gotta fork out that money for certification!

Actually you just reminded me. We have an amazon guy who comes in once a week for "office hours" and you can run pretty much anything by him and he'll tell you how it can be done, and sometimes he has clues to stuff coming down the pipeline. I'll see if I can schedule some time with him.

some of us have been strongly advising jmakin to gtfo for nearly a year. given his background his resume should easily be strong enough to find a decent developer job, esp in that area.

Yeah the "bad advice" bit seems a bit unfair since I don't recall the range of advice given to him in detail and my perception may be driven mostly by what he ended up doing. I vaguely remember people encouraging him to work at startups and/or situations where he can straddle different roles, especially last time around, but I may be entirely wrong. How I feel at the moment is that 1) he gives off the impression that he would do well in a flexible, ambiguous situation because he's a seemingly well-rounded person that can improvise well in different situations, so he will tend to get advice along this line, but 2) due to poor self-control combined with just enough ability to manipulate his surroundings to indulge his worst instincts, he can't handle this level of flexibility and autonomy. I think he will do much better in a relatively rigid situation where it's clear what's expected of him and he doesn't have the ability to deviate because 1) it's easier for his psyche to handle, 2) he can focus energy on becoming good at specific things that will prove useful down the road, 3) and structure will help him develop the discipline that he needs to apply his talent more broadly eventually.

Avoiding any deep psycho-analysis of jmakin, I think it?s just generally a mistake for a new grad to jump into a very poorly defined role across different engineering functions. It?s definitely a mistake at a dysfunctional company - which was obvious all along. If something like your top 3 executives don?t deal with product details and only with financing - that?s a massive red flag that nobody should ignore.

That being said, who knows, maybe there?s lessons you can take from a shortish experience at a place like that that will serve you well. I had a couple of terrible internships that I?m glad I did looking back on them.

Well, all that said it?s looking like it may lead into another job where all the execs are gone and I get to stay with my engineering team, which is very talented. Replacing all our execs with competent ones in a well funded startup is not a bad outcome at all. And in the new company I?ll likely be an engineer.

I disagree with some things you said but overall it?s been a good learning experience for me and I definitely got a solid sense of what I am good and not so good at, and areas I need to improve

I already got a freelance devops gig for a medical company, just to have something to do in my interim. I may take a few months off and just brush up my skills while I job hunt. My programming has already improved hugely in the last 2 weeks. I?ve gone from not being able to solve problems on leetcode to finishing most of them in 5-10 mins which is where I wanted to be.

I have a networked opportunity for an upper management position I?m fairly confident I?ll get an interview for but i would greatly prefer not managing for a while.

Sounds like things are going reasonably well. Which isn't really surprising. In this environment competent engineers can get jobs pretty easily.

Just a note on the "upper management" position. Anyplace that would want you for upper management at this point is probably not a place you want to work. Just my $0.02. But obviously things can go many different ways and there are many paths to success, so what do I know?

It could also be a stepping stone used to get a management job at a real place. This whole industry has a youth fetish. Jmakin' could become an up and comer.

Jmakin - work on your suit jacket, t-shirt and sneaker game. The T-shirt has to be kinda nerdy but still kinda cool. And no mom jeans!

Yea but i?m not

I just want a job where I can excel in, I?ve been flailing for almost two years now