Ask HN: What tech stack would you choose for a serious, long-term business app

Definitely agree with memcached. This has been entirely bullet proof for us for years. We have had lots of nodes with billions of hits each running non stop for 3 years without a reboot on CentOS 5. Zero maintenance required. Amazing bit of software.

My ideal business app layout (I assume we are talking enterprise, here) would be:

DB: A hybrid of Postgres & MongoDB

API: Hand rolled w/ SparkJava

Front End: intercooler.js (SPAs blow out your complexity budget, which should be spent on business logic)

Caching: Redis

PaaS: the system should be designed to deploy on anything, including internal servers

For a SaaS app, I would look at rails due to the ecosystem and stability, but otherwise it would remain the same.

First off. As someone else pointed out it depends on the application.

Heavily data dependent / ETL applications have different requirements than CRUD applications. There is not a one size fits all stack, you need to consider the user cases.

For example:

- We use DynamoDb and ElasticSearch on the back-end because our case is very key-value oriented but also needs faceted search in some use cases.

- We use Node.js for our user-facing REST API because it was fast to develop and quick to iterate on but we use GoLang for our internal gRPC APIs and front-end because in our case those are the hot paths and where the performance differences between node and Go make a difference.

For an activity feed API (hundreds of thousands of activities a day) I've used Redis with huge success.

The point being is if your app is truly enterprise you'll probably have more than one microservice, and you should pick the right stack for each microservice.

In absence of a hard business requirement that is significantly different between languages choose the framework your team can develop the fastest in and get to market fastest (like our hot path example).

My personal go to is...

Backend: Postgres, Redis, Elasticsearch, DynamoDb

Front-end server and APIs: Node.js with express (no framework), focusing on as few lines of code per microservice as possible

OS: Definitely Linux

Cloud Provider: AWS

Cache: Cache close to the app when possible, if you don't need cache to be synchronized across machines there is no need for a central cache. With that said, I personally love Redis

On the cloud platform note, I'm an AWS guy but they all have their benefits. I try to use as many AWS services as possible to decrease dev time / costs but write the code in such a way where it is abstracted so getting away from vendor lock-in would be possible (painful but at least possible).

All the cloud providers have a service catalog that can shorten your development time if you take the time to learn them use them right. I happen to like AWS value added services best.

With all that said:

- The most important things you should worry about is getting to market and solving the customer's use case. The stack is not important in 90%+ of cases. If you structure as microservices you can always replace individual services cheaply on a case by case basis once you have customers.

- Second, "When I ask tech stack I'm talking the whole dam thing" is very unprofessional and I almost didn't answer because of that. I suggest perhaps an attitude adjustment when asking the community for free consulting advice.

> very vital brand new application for your company that needs to be maintained long term

Long term maintenance is easier if the tools are relatively stable. I think that argues against most (all?) Javascript frontends. Eg, if you started this 3 years ago, your current JS devs would want to throw away your entire JS framework and tooling stack. Odds are if you do it today, they'll want to do the same in For minimum maintenance issues, I'd pick PostgreSQL for db (data integrity FTW), Redis for caching, and do a server-rendered app.

Of the server-side frameworks I know, Elixir Phoenix is my favorite, but Rails is older and arguably changing less. Probably some Java framework is even more crufty / stable?

Of course, there are other concerns besides stability that might argue for different choices - eg, using Elixir Phoenix means that a lot of your caching would be unnecessary, because the dynamic parts of view rendering are "cached" in compiled functions and the responses are very quick without further caching. And you'd get richer experiences with an SPA, in exchange for a lot more work. But you highlighted maintenance.