Good point.

Personally I'm glad I moved into node so I can skip the front-end framework churn cycle. Server-side seems to have more like a 10 year+ cycle.

But I know that doesn't work for everyone so I guess I'd recommend just get good at one framework as you point out, but especially get good at advanced vanilla JS. Also learn CSS. JS + CSS expert is much more valuable.

Even if companies stop creating new apps in Angular, all the existing angular apps need to be maintained. That’s not an insignificant number.

Also, Vue is like literally angular-js 2.0 with all the suckiness extracted - any angular dev should be able to pick it up in two weeks. It’s really not that complicated.

Dunno about that. In taking with companies during my job search it send like lots of companies are actively migrating away from angular.

Yea there was no reason we needed react-router connected to redux, but it happened, and when I tried to break it apart quickly it ended up seeming non-trivial so I left it.

The most frustrating part of the React ecosystem atm is that there are so many different ways to do things, and almost no one is advocating for a certain "correct" way to do things, so you end up with code in tons of different styles everywhere, like Rusty is experiencing.

eh dont really feel that way unless you try to do things like the above. React router 4 is very pleasant to work with tbh. Redux is the only thing I find irritating to use and using it with "ducks" is 5x better than the alternative.

Ducks does look nice. At first glance it looks similar to Kea? Have you ever used that?

Angular had such s huge market share seems like there will always be some jobs kicking around.

I had an interesting hour long phone interview with the lead engineer at a startup that apparently went through a big crash, with major bad press, where almost everyone left. But now they're back for incarnation #2. All the C-level people are new, but this engineer has been around a while. So yeah - lots of dysfunction - which is a concern.

They have a node app that sat there on node .10.x for 5 years w/o updating node or any packages. He just recently updated it. But they're calling it a "monolith" and they want to break it into microservices. I'd be coming in to help build out the microservice platform and making a lot of decisions.

Fortunately I have a lot of experience in that area. Unfortunately all my experience tells me that unless you're Netflix - you're probably better off with a well-written monolith or a few smaller apps.

Just a few of the problems I've seen:

• You gotta have full-blown DevOps out the gate. Figuring out CI/CD from scratch as you build out microservices leads to a huge mess.
• You always need some level of app-level governance across microservices - which to some degree turns your microservices back into a big app.
• Versioning and deprecation are not trivial problems and require coordination with clients.
• Shared library vs. microservice generator vs. let devs wing it is an ongoing tug-of-war with downsides to each approach.
• Reporting and logging are exponentially harder.
• Allowing any microservice to talk to any other microservice can get out of hand and quickly lead to mistakes that can't be undone - like fixing a malformed end-point. You can add something like a service bus - where at least you can fix things in a global place. But that adds a ton more complexity and it's own issues of course.
• Each microservice getting it's own cordoned-off database leads to all kinds of contortions and extra chattiness. Sharing a DB is supposed to be an anti-pattern.

These are just a few off the top of my head. Basically I see no way that "Hey, we're still figuring out a lot of things as we go, but we know we want microservices" ends well.

Do companies generally still think microservices are the way to go, or are they kind of coming to the same conclusions?

I'll laugh if Netflix comes out with a "Why we are sunsetting our microservices and going back to a monolith" blog post in a few years.

ironically I just saw a very promoted "microservices suck its back to monolith for us" post on HN like last week so maybe look for that.

yeah, all the geeks on slack here were just talking about how the microservices fad has finally ended like they knew it would.

is there something like this site for React?

https://www.vuemastery.com/

damn, i didn't realize Angular had fallen this far out of demand.
React 78% vs Angular 21%
https://medium.com/@TechMagic/reactj...8-b91e028fa91d

If you just mean paid courses, I am sure there are tons. I found Wes Bos videos to be excellent when I decided to learn some React. He has plenty of free stuff also.

If you mean paid courses by the React creators themselves, idk probably not.

I actually read this one... It was not so clear as it's title may suggest. To me it was more like "we tried to do microservices, the devs got annoyed with writing / running tests and using the latest version of shared libraries, so we let them skip those things. It became a nightmare to maintain with every service using a different version of what should be a common library and poor tests. Now we moved back to a monolith and enforced good tests and the library version issue went away, it's good! microservices suck!"

I'm no microservices expert tho, not in the slightest.

I'm leaving a place with a monolith backend and there's no ****ing way it's the best/right way to do it.

Yeah that was exactly my point in saying that if you're not Netflix, maybe microservices aren't right for you. IE - rock star devs, solid app governance (forcing updates of shared libs), solid testing and DevOps culture already in place, management fully on board and willing to make tough decisions up front to do things right even if it means delaying release of the product etc.

However, one thing I've found is that basically every technology decision needs to have a huge amount of disclaimers based on your current situation.

Given where you currently are, and your current business priorities, I feel like it's generally rarely a good idea at a startup to spend time making large scale changes that aren't user facing. Sure, it would be nice to use micro-services, but if you have a monolith and everyone is used to it, switching is probably a horrible idea.

Likewise there are tons of things that are in general a good idea (using cloud services instead of buying hardware) that given your current situation are not high enough value to change.

We had a Scala/Play API layer and a node web-presentation layer. Maybe 50 APIs in the play layer and over 100 pages or ajax calls on the node side. It worked pretty well.

We did a really good job of letting the APIs and node components be independent - while still maintaining control and adaptability over global or semi-global behaviors, stuff like reporting, etc. A monolith doesn't have to be a monolith.

Also if all your microservices are ultimately serving one client - you still have a monolith in a lot of respects. You're just splitting your back-end components up at a different layer of abstraction.

Our disaster "monolith" that we were replacing was the Weblogic beast that had evolved organically over a decade and was not well managed or coded at all. At least not for future flexibility. But to me that's understandable given the timeframe. It would have taken a super-human effort to keep that thing nimble after a decade of cruft trying to creep in.

Microservices are supposed to be some magic bullet to avoid cruft creeping in and keep the app nimble, when in reality they add all kinds of new cruft - often at a layer that's much harder to globally refactor.

This is the HN piece I'm guessing:

https://news.ycombinator.com/item?id=17499137

https://segment.com/blog/goodbye-microservices/


This one is some interesting discussion too:

https://news.ycombinator.com/item?id=16200007

https://www.dwmkerr.com/the-death-of...dness-in-2018/

Yeah this one really nails a bunch of my feelings on them.

I like this guy's interview process better than any I've heard. https://www.karllhughes.com/posts/rethinking-hiring

I read the microservices post from Segment. It really feels like they're conflating code organization with service organization. It's totally possible to have separate services that are defined in the same repo. The blog post doesn't really cover if they looked at this, but it sure seems like it would have solved a bunch of their problems without a lot of the downsides of the monolithic service itself.

demo'd my test infrastructure today formally in front of the whole company, a few holdouts voiced concerns with the process, the CTO/CEO says "this is EXACTLY what I wanted."

Feelsgoodman. But now, I'm married to this thing, if there are ever any problems with it. I tried to make it robust as possible but we'll see. Starting to wish I had used python for some of the higher level scripts, bash differences between environments is surprisingly annoying.

I'm at like ~3k lines of code now easily. But it's pretty loosely coupled, considering how large it is and how many moving pieces there are - barring some major, disastrous update to docker I should be fine.

If there is still time I would 100% replace bash with python. We have had nothing but issues with a lib that is written in bash. Same thing as you, different OS and something breaks. Took us a day to track down a bug caused by a diff OS in travis than on our devs local. Ugh

Nice jmakin! Sounds like some good engineering work.

Also anyone who says algorithms don’t matter, I was able to whip up KMP string matching for one of our services and was able to benchmark and found our injestions running 3x faster locally. Going to deploy tomorrow and hope everything holds up.

I’m really scared b/c I feel like this is a job that normally would fall to our QA/systems guy, but he’s explicitly stated to me he wants no part of this process because he feels it isn’t going to work out for long term, that he’ll just provide “high level support.” But I’m really just implementing what was told to me by my boss and the CTO - no one seemed willing/able to help me with it. The QA guy’s provided me with a ton of support especially when i was encountering very difficult technical networking problems, and advice too so I really appreciate and am kind of treating him like a mentor right now so i can make a reasonable contribution and show my mettle. But i’m really way over my head