nubs

Our organization recently looked into AWS Session Manager for tunneling but couldn't find documentation on how to make it work for our usecase. We were trying to tunnel into our VPC in order to be able to connect to an Amazon DocumentDB cluster. We don't have any EC2 instances which seems to be the only thing Session Manager has support for. Despite the callouts that Session Manager replaces bastion servers, that didn't seem to be the case for us. Did we miss something in our research?

KEY Concierge | Austin, TX | ONSITE | Full Time | Software Engineer

KEY is a hospitality marketplace for travelers, vacation rental properties, and vendors. We are transforming the industry through our technology platform, which vets properties and provides curated services to make guests’ stays seamless and homeowners’ lives easier.

Our Stack: Node.js, React, PostgreSQL, MongoDB, AWS, GraphQL

We are looking for an experienced engineer to provide technical leadership and build a technology platform that connects vendors, property managers/aviation partners, and travelers, enabling the travelers to effortlessly plan curated experiences. You will be a key member of the team to develop the platform for concierge service.

Are you ready to join us as KEY expands into the hottest travel destinations, and usher in the next big wave in the travel industry? Contact us at [email protected]

I think the National Association of Pastoral Musicians will be fine. I assume you meant npmjs.com. :)

It still proves your point, but the gallery is interactive via clicking to the sides of the image. Interactive but not intuitive.

I dunno, raise the T-Rex up and have it be able to protect you. Classic Lion King type story there with Timon & Pumbaa using Simba. ;)

You should only ever be squashing an error into a success response if that's what someone would be expecting but that's rarely the case. Normally you should be allowing the error to bubble up and be decided by the caller.

I can think of a couple cases where catching an error down low with the purpose of squashing it makes sense. One would be for a service that you know may not have data and you don't care if it doesn't. For instance, trying to get geolocation data for a user in order to improve their experience but if it fails you don't need to show an error:

return geolocationService.fetch().catch((err) { /* log error /; return {}; / empty result/ });

Another case is when you might have multiple ways of handling the request where one is prioritized over the other. In this case, you can catch errors from the first attempt and try a second method. If they both error out, then the result promise will be an error as well.

return primary.fetch().catch((err) => { return secondary.fetch(); }).then((data) => { / manipulate data */});

It doesn't need to care whether someone else is handling it. It should just do what it needs to do according to its contract. The caller that receives the promise as a result has its own contract that may or may not involve handling the error as well (and so on up the chain).

You generally have to have an end-of-the-chain catch as a safety precaution. If you don't have one and the promise fails you may get no feedback that an error happened at all. All methods that return promises should be able to expect the caller to handle them appropriately whether they pass or fail - it's not their responsibility to try and figure out how to handle an error in the context of the wider application.

The way I handle situations like this is to only put the catches where I need them to serve some purpose. Generally, I don't catch errors at the start of the chain because I can't know what to do with them at that point. If I do catch them, it's only for logging or similar purposes and I still let the error propagate further.

One pattern I use is to rethrow the error:

return service.fetchData().then((data) => {}).catch((err) => {console.log(err); throw err;});

Another pattern I use is to split the promise chain so that I let my main results flow be the result that gets passed on, but I can do other things in a parallel manner internally:

let results = service.fetchData().then((data) => {}); results.catch((err) => {console.log(err);}); return results;

It's similar to the naming convention used by other long, hard-to-spell words for projects. First letter of word, number of letters in the middle, last letter of word.

e10s = electrolysis

i18n = internationalization

l10n = localization

k8s = kubernetes