← Back to context

Comment by stuff4ben

4 years ago

Out of curiousity, what would the HN crowd recommend for the tech stack for a project like this? They had Angular, Mulesoft, and some other cruft I'm sure thrown in. What technology/languages/frameworks would work well enough to support Hertz and their subsidiaries for now and into the future?

Here's what I'd choose as someone who hasn't done something like this in his 25 year career: Some front-end framework (is React still relevant?), Java/SpringBoot, Kubernetes/KNative, some mesh, some back-end mainframe integration with their legacy systems...

Angular was a reasonable choice - it's well suited to "enterprise" web applications as it has standard ways of doing things the Angular way in contrast to React which has 3 - 5 options for different things. Certainly back when it was chosen, there's no issue in this choice.

Mulesoft, personally hate it - but it's definitely an option if you're trying to abstract out a whole bunch of legacy systems into clean APIs. Personally, I'd probably create some lightweight integration components in custom code (whatever language you like) deployed in containers on some scalable cloud platform over buying a chunk of enterprise middleware and trying to find the skilled resource to configure it. But, I don't think Mulesoft was a death knell here - merely a bit of a money pit. Same thing for AEM.

Overall, it doesn't look like they were choosing unreasonable tools to do the various things they wanted. e.g. they weren't trying to use Salesforce as a transactional database platform.

You could definitely pick a better stack, largely from open source, and deploy to the hyper-scale cloud provider of your choice - but I don't think the tech stack that's what screwed this project up overall.

Here's what I'd do.

- Monolithic Haskell web application.

- Very little JavaScript.

- Small team of people who know what they're doing.

- A couple of servers.

- Postgres and Redis.

With the remaining $31,500,000, I would buy weapons for Ukraine.

To be fair, mulesoft is not an obstacle here, it lets you expose a http API using the built-in components, generate an OAS description pretty easily. Performance can be shaky but just chuck Varnish in front and hire a guy who knows how to read GC logs for a week to tune the STW-pauses and presto, you can handle >10k r/s on a laptop.