What kind of team size are you working with? And strictly node?

Small team. Node and C#. Starting with one middleware app that I think might have a couple dozen end points. It talks to a web client and has to connect to a SOAP back end and some other DBs for some stuff.

But the idea is to build a MS platform and generic API paradigms that we can convert more stuff over to. The idea is to do as much as we can on lambda but fall back to EC2 for the stuff we can't do on lambda. I have very little idea how that split will shake out at the moment.

The other big part is to implement API gateway with cognito. There's an internal auth provider and external users. We want to federate that in API gateway and maybe even link (phase 2) when users happen to be both (which happens a lot).

I’m debugging problem coworker’s scripts and they are just off the charts awful. Like, clearly never tested them, just vomited some code into a script and pushed it.

when I say awful I mean, as written, there is no possible way in hell that it's even possible they run correctly the way they are written. It's really obvious they weren't even ran a single time.

At this point my options are:

- Have a serious talk with them about the quality of their work and how it needs to improve, which will probably be ignored
- Float it up to my boss and be a tattletale and forever lose this person's respect (if there was any)
- Do nothing and hope someone else notices it (I'm sure it has been noticed)

bleh

Oh, and to top it off, I burned a whole day debugging these stupid things and when I asked for help to figure out wtf was going on (I thought it was user error by me) I got blown off.

We might use cognito in the future, so if you end up using it let me know how it shakes out.

I would absolutely tell my boss about it to give them a chance to do something. And if it comes up again I tell them again with the addendum that it needs to get better or I'm looking for another job.

I've worked with two different people like that at my last company and watched it kill morale both times. So now I'm of the mind that **** like that needs to be aggressively dealt with.

Is this **** common? I swear I take enough pride in my own work that I test things I push like 1 billion times before I do it. Everyone else I work with is the same way. I thought this was some type of anomaly

One of the testing scripts I wrote I ran for48 hours straight, until it broke my VM (out of memory) to make sure that it was working correctly.

I use newrelic for all my services and it will generate service maps, and when you look at traces in newrelic it will annotate all the steps, you that you can see not only that you spent X ms in some remote endpoint, but that Yms of that came from this particular function on the remote endpoint or that DB call. It's pretty good.

We do most of our communication in a star formation, i.e. there are hubs that make a lot of calls to disparate services. We try to avoid multiple step service layers.

We do some data replication via queues. Like if there's a service that needs only a userid and username, instead of having it make a call to some "user service", the user service just publishes user changes and the other service uses that to populate a database. That can be a little fragile, if you decide later that you want emails too then you have to refresh your local version of the user database from scratch.

So far it works fairly well. We have, I think, 20-30ish services. Some are very well defined and self contained, some less so. We have one monolith next that will probably stay that way, or maybe get broken in 2-3 along very well defined lines.

We avoid most of the obscure AWS stuff, just RDS, S3, SQS and then recently some kinesis. RDS could easily be replaced, and we use wrappers for S3 and SQS so they could probably be replaced by anything with similar functionality.

We use new relic too. And data dog. I feel like I lean on those more for errors and health checks / paging.

XRay is cool because its code level, so rather than just seeing api endpoint serviceA.com/foo took 80 ms, you can see how long each function or action /foo takes as well. You could really use any tracing solution, we're just deeply engrained in AWS. I find it incredibly useful, we have actually found a few times a caching solution was expiring too quickly through XRay and could tailor the way it cached.

Our focus is kind of on standardizing stuff, because we have a lot of different things in different services. We built a scoring service, that looks for recommended things integrated in each microservice (like a new relic setup, or travis or code climate, or w/e) and then lists all the diff teams scores as gamification to motivate us. Its interesting

Right but I'm saying newrelic does this also - it lets you dig into the performance of the remote endpoints too (as long as they're also running newrelic in the same acct)

Yeah remote endpoints, XRay you can show how long a for loop adding a number takes too though. Its just more granular is all Im saying, sometimes we need a more involved look into where all the time is spent in a call to another service, not just the remote calls

I'm an idiot but it feels like you guys might be shoehorning in technology decisions before fully understanding the business requirements.

Seems like a lot of these decisions might be chasing the tech and not solutions.

I think we 100% did that with grpc, although in an environment with 5 diff languages we were looking for a solution that auto compiles to various languages.

Outside of that, explain

I started playing Exapunks today, anyone else playing? A few of my steam friends play but no one who is really trying to get good solutions. I'm "Rustybrooks" on steam
https://steamcommunity.com/id/rustybrooks

I guess it depends what your primary development language is? Coming from C++ it generally feels like Go requires a lot less boilerplate and you can get stuff done a bit faster in it, but I'm sure there are other languages where it feels like a relative drag.

Added! There's a thread for it in Video Games. I love this game.

ping thread when out of early access plz

It's in no way broken or anything afaik. Bit of a busmans holiday but I like it

I meant that to suzzer and was a page behind I think, went to address it to him but internet failed me at the time.

I forgot about a funny moment at the AWS summit -

We were talking to memSQL CTO, asking about implementation details and he was being pretty forthcoming. Then he realized we weren't interested in the product to use, but that we were sort of competitors - and he got openly hostile. The conversation ended with him telling us noSQL is going away LOL.

my company makes some pretty lolsy business claims sometimes and I've been careful not to drink the koolaid too much, but man if I ever get like that, just put me down.

I told my boss and he chuckled and said the perfect one liner like he usually does, "You should have told him to look at mongoDB stock."

I think it will take some monolithic failed projects in go before people stop drinking the koolaid

Yeah for sure. If all we were trying to do was build a product, I'd have us up and running on gitlab CI/CD and keep things super simple.

But my boss want the app we're building to be a base for a more generic REST API platform. And she really likes AWS and wants to learn all its features so we have those available as tools. I'm like ok let's learn AWS.

I mean, like the most important rule of deving is to not break the build or push buggy code. So ya, this is rare.

Yea this is an interesting conundrum.

Managers of technical resources want to claim they are doing innovative and cutting edge things, so they will often pick the tools that the cool kids are using. If the marketing team is privy to any of these decisions they will do it to an even more extreme.

Developers realize its silly, but hey, learning the new cool stuff is 95% of the time going to result in better job opportunities, and it isn't their ass on the line when other people make the decision to go with cool things, so its hard to imagine they ever complain.