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

As we're talking business and long lifetime...

First point: nothing Microsoft. Done that show for 20 years and been through all the marketoid schizophrenia promoted rewrites for no business value. Now the new "start again" is .Net core and a big chunk of stuff just isn't portable and never will be. Plus the price gouging, licensing hell etc when you have to scale up. Entire ecosystem is a wasteland of unmaintained crap and automation prospects are terrible. Forget it at this point. I'm done.

At this point, I'd pick Java + Spring + Postgres + CentOS. Does most of the stuff you need out of the box, good support available, long product lifespan, well maintained, possible to automate everything. No SPA, just old fashioned dynamic pages with light weight in house JS framework that does partial page replacement, simple validation etc via DOM. Not even jQuery which has been nothing but hell to upgrade so I'm loathed to pick anything more complicated.

PaaS: none. Either in house or old fashioned colo, with HP hardware. If you have to go PaaS, then AWS which seems the most glacial in deprecation so far.

Edit: also desperately avoid any non portable abstractions and vendor specific features. They will ruin you. For example when someone suggests a database engine, hide it behind hibernate and only use the hibernate API!

Edit 2: it is important to assign an exit cost for every decision as well. What's true now is not going to be in a decade.

DB: Postgres

API: Ruby on Rails

Frontend: React, the react_on_rails gem to set up webpack, Flow, Redux, Immutable.js

Background Jobs: Sidekiq and Redis

Caching: Memcached

PaaS: convox (on AWS). See: https://convox.com and https://github.com/convox/rack (But you should start with Heroku.)

I recommend the Rails stack. It's not the "hot new thing", but it's very stable, secure, and productive.

Answer for your given question: Java + Oracle. They'll both be supported by legions of enterprise devs until shortly before the heat death of the universe.

Real answer: it depends. You've told us nothing about your application's business requirements, operating environment, or staffing availability.

I'd also caution on the idea "put aside what your devs are already familiar with" - different tech can give you different velocities, but either you accept a much lower velocity for a long initial period while your team spins up OR you accept a significant recruiting cost to hire new devs & teach them enough about the business to make good decisions.

LAMP (Linux, Apache, MySQL, PHP).

Boring stack. Easy to get developers on board.

NO frontend framework. Just html5.

NO compicated stuff to start with (SPA, microservices).

Just PHP for processing and a simple template for quick hacking.

And that will keep me 100% focused on just one thing: getting st done.

We're 99% Python but for an internal app I would probably go with Postgres, Memcached and Phoenix/Elixir as that's probably where we want to end up in a few years time. For the front end I'd go with HTML and vanilla JS. Front end dev has gotten so mad that picking any framework at this point could turn out to be a bad decision.

We're developing "boring" business applications intended for long (~10y) use:

- Kubernetes: provides a good abstraction for running multiple apps and services in a cloud, without vendor lock-in.

- Postgres: proven reliability, best (free) relational db with lots of functionality

- Clojure: expressive language with huge ecosystem of libraries (since all JVM packages are available)

- ClojureScript: also a huge ecosystem (JS interop). Because it is Clojure's sister language, we reduce training need an mental ovehead. It also enables code reuse between server and client in some situations (using .cljc files and reader conditionals).

- React + Reagent + Carry framework: sane view rendering and state management

- API format: RPC-style HTTPS requests, with payloads in Transit format (so that custom types can seamlessly travel over the wire between CLJ and CLJS)

- Our own `devops` automation software which lets us deploy K8S clusters and apps inside of it. It also provides abstractions around AWS services like S3, which should allow us to move to Google Cloud ifneedbe. We also wrote it in ClojureScript and run it using Lumo.

- Minikube + some standin apps like Minio (to run an S3-compatible service in a local container). This enables us to develop and test all of our apps locally without deviating much from our prod stack. We also support a `hybrid` mode where you can run your app locally (using a REPL) but let it connect to other services which all run in AWS. This further ensures similarity with prod env.

I'm aware some components of our stack might turn out to be wrong choices, so we try to limit blast radius by trying to prevent leaky abstractions where possible. (e.g. our apps are not aware of K8S in any way, and could just as well run on a non-virtual machine, with all related services like DB also running as a local daemon).

Our biggest gamble is Clojure(Script), but because of its Java(Script)-interop, the greatest risk there is language stagnation.

Is your business just starting, or already have some customers? How much funding you have, and what are the skillsets of your staff have?

A safe place to start would be Linux + Postgres + Java Spring or PHP Laravel.

My experience is the market has more Java or PHP engineers (compared to say, Elixir).

I own a dev shops and I also write apps for clients big and small (think big 500 to 5 person startups) for a living.

I used to advocate Rails a lot, but over just the last year, I realized nothing out there can replace my current stack (Phoenix/Elixir/Vue) then yet and I think it's still true today. And, that's a good thing after playing with tons of frameworks out there.

So far, I've tried the following - Express (Node), Play/Scala, Paython/Django/Flask, Ruby on Rails, Phoenix/Elixir.

My pick would be the following (and I'll explain my reasoning):

    DB: Postgres (Google Cloud)
    API: Phoenix/Elixir
    Frontend: Vue + Brunch
    Caching: We don't use caching (haven't had to, will explain a bit)
    Paas: AppEngine (Google Cloud)

I wrote an app for a startup backed by a large VC firm last year and we chose Phoenix/Elixir for it. With Elixir, we were able to find code errors early on, we had the freedom of organizing code in Rails style (think concerns), while not having to fight with opinionated OO.

Elixir is drastically different in the sense the piping makes you think way more differently than working with other languages such as Ruby/Python. An example, this is production code from our E-commerce platform:

      def process_order(user, token) do
        user
        |> mark_order_type()
        |> collect_payment(user, token)
        |> fulfill_order(user)
        |> verify_order()
        |> update_order_status()
        |> clear_cart(user)
        |> email_order_confirmation()
      end

The code is more elegant and really beautiful to write and maintain. As a nice bonus, about last year, we had so built so many drop in libraries that we'd just throw in into new projects and we were good to go since they would just "work".

There was one startup that abandoned their project midway after paying a lot of money, but as a courtesy, I told them I'll keep it online as long as I can, but promising only minor/security fixes to their web app. You'd be surprised how little effort went into maintaining their app. Once it was all setup, it just worked without any hiccups, (yeah, we do our regular checks).

I have fallen in love with Phoenix/Elixir ever since.

Why Vue? Because, it's fast, has a very low learning curve and doesn't involve JSX (Mildly related: https://twitter.com/thomasfuchs/status/810885087214637057)

Why Google cloud? Before Google cloud, we were on Elastic beanstalk. There was this issue of dockerized setups where instances would randomly shut down and also updating them would take forever. The only solution was to delete and re-create the instances. This issue persisted as early as Jan 2018, I'm not sure about now. The sole purpose, I repeat, the only reason why you wan't to go the Paas route is because you don't want to do DevOps. And ElasticBeanstalk got us to a point where we were almost doing DevOps. I don't blame Amazon, since Phoenix/Elixir is still relatively new, but unfortunately didn't work well for us.

Between AWS and Google Cloud, AWS has a lot more breadth in terms of the services offered - My favorite is their image processing service. Their (AWS's) official SDKs are also usually more stable. But, I prefer to write my own as most of the time Elixir isn't supported anyway.

Recently Google enabled first class support for Elixir on AppEngine, so it makes it all the more attractive. They also offer a $3000 in credits if you're a startup. I don't have the links, but I know the program is still live as I got one very recently.

Caching: We don't use caching for our use-case. We divide our app into high-load parts and low-load parts. The high load parts are usually the static ones, such as your home page, about us page and so forth. We use Jekyll to push up static sites. For some of them, we use Netlify. But, for the rest, we use S3/Cloud storage. As scary as that sounds, for most of my use cases, I think caching is pretty much overkill for my clients since they don't have their response times as bottlenecks yet (I've only had 6-7 clients who've faced such issues in the last 2 years).

Having said all this, I would also factor in the learning curve to develop such an application. IF this is your first time, I'd rather prefer you stick to something you know already and are familiar with. If this is a mission critical project, I wouldn't gamble with a new stack. So, use my advice with caution :)

1. Tech stack has to be decided based on functional requirements (real-time chat, less-write but read-intensive etc) and non-functional requirements (concurrent connections to support, regulatory compliance requirements etc).

2. Any serious business system (not just one app) will have multiple tech stack.

3. In the long term tech stack has to change depending on the changing business needs.

Assuming a whole lot about above 3 points, choice could be postgres, python, react, aws. Purely because they are battle tested. Any discussions about their merits are moot without knowing requirements.

The goal would be 4 CentOS servers (probably VMs in AWS/Azure) Server 1 - Nginx load balancer Server 2,3 - ServiceStack (default setup; minimal plugins) with C# on .Net Core Server 4 - centralized file/data storage. Postgres for SQL, Redis for Cache (possible Message Queue as well) but would start with 2 servers (one for .Net Core/Service Stack and one for Postgres)

This setup keeps the OSes standard across layers with the possibility to move pieces to Saas (eg. Redis -> Azure Cache/RedisLabs, ServiceStack -> anything supporting .Net Web Apps) if there is a cost/support benefit. IMO these tools have simple installs with common/sane defaults but are well documented for when business features become more complicated.

ServiceStack is mostly C# code with minimal coupling to the framework. It also offers many Plugins/Features for common web scenarios (auth, validation, etc). Basically ServiceStack is great at handling 'Http Request In' and 'Http Response Out'. Everything in-between should be straight C#/.Net.

Redis makes a great cache but can do messaging and pub/sub. ServiceStack offers libraries for Redis but others are available. It doesn't try to do too much so if a more feature rich Cache or Queue is required it will likely support the Redis use cases (and more).

Postgres is a great db engine but can also be a great document store. ServiceStack offers Ormlite support for db, there is raw SQL support via Npgsql or Marten for the full 'kitchen sink' use of Postgres...and I guess even Entity Framework.

I would start with HTML (ServiceStack/C# DTO -> Razor Format Plugin -> HTML) with Bootstrap and jQuery and add in API Support (ie. JSON) with Vuejs frontend if single page application interactivity made more sense.

When starting an assumed 'vital long-term' project I want my tools to have simple/clear boundaries so I can add/remove when necessary (well, more likely forced to) without losing my investment or doing any heavy 'dependency lifting'.

Db Engine - AWS Aurora (Mysql or Postgres no preference). No lock in since you can just move to a Standard DB later. But little maintenance since you don't have to maintain your own servers.

API layer - I'm biased toward statically typed languages so either Node with Typescript, C# .Net Core with Web API, or Java. I don't trust Oracle's direction with Java and Node just seems to be architected badly but that's what the cool kids want to use. I prefer c# but again the cool kids have anti MS bias.

Front End - I'm no front end guru but since I'm always concerned with my marketability, React and Angular seem to be the most marketable. You can't go wrong either way.

Caching - It depends on your use case, but either Redis or Memcache would be good - especially since they are both supported by AWS ElastiCache. No server maintenance and still no lock in.

PaaS - AWS is more mature and no one ever got fired for choosing AWS.

Even though I've done my own dev ops, I avoid it like the plaque. In 2018, I would go serverless as much as possible. That means a combination of AWS Lambda for small tasks and AWS Fargate for serverless docker. But write your Lambda functions in a way that doesn't tie you tightly to AWS.

You should pick your technical stack depending on what the requirements are. Picking the stack first means you're forever going to be trying to shoehorn the requirements around it, which is a pretty terrible way to design a long term solution.

And then you need to look around yourself at the resources you have now and what they may be 5 years from now. There's no use writing something up in a little used language hoping you'll be able to hire for it later and adding risk by writing something in a language or technology only you know in your company is creating an unnecessary bus factor of 1.

Your first mistake is that you limit yourself to what's "in", rather than what gets the job done "properly".

For serious long term business apps you want to use multiple technologies that all integrate with each other, where each are used for the tasks they suit best.

> Put aside what devs at your company may already be comfortable with

At your peril. Sorry, but it's true.

Any time there is something even slightly amiss it's going to be "Uh oh - looks like Mongo is giving us trouble again."

No matter what the real problem is a slam-dunk scapegoat. And your name is going to be forever attached to it.

Also consider how you're going to deploy & maintain the stack itself. Do you have an ops team that's familiar with deploying war files into a servlet container? Well now on the critical path to this thing going live is them learning how to maintain a new app server, language and deployment process?

That said, at the end of the day - all the tools, frameworks, and languages you mentioned are just fine, with some slight nuance:

DB: MySQL is fine, Postgres has some nice additional features if you need them: GIS, great scripting support, etc

API/App: Stick with the big ones (Elixir? C'mon...). Slight edge to Node because JSON de/serialization is automagic. Slight ding to PHP because... PHP.

Frontend: Who cares? It's going to be outdated in 6 weeks anyway.

Caching: Which ever one you don't have to maintain or think about. Did you choose AWS? Great. Elasticache supports Redis and Memcached.

PaaS: Whichever one supports all the features that you need.

> 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 < 3 years.

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.

General answer since this is a general question.

DB engine: Postgres, something more exotic (dgraph, cassandra etc) depending on use case.

API layer: Microservices with grpc, write services in languages which are/will be good for each service's use case. Allows for a relatively easy longterm upgrade path, service rewrites in new languages when staffing or needs require.

Frontend: React, because a) it's great and b) you will worst case be able to reuse a lot of techniques if you decide to use React Native, best case a lot of code. Structure the frontend with lerna and you can avoid the churn of JS build tooling for more stable parts of your application.

Caching: Redis or Memcache

PaaS: I like GCP more but they're pretty much the same dish plated by different chefs.

Answering this before reading so I'm not impacted by others. SQL Server, ASP.NET Core, As little JavaScript as possible, No caching initially, Dedicated servers, IIS.

> very vital [...] maintained long term

These scream to me two requirements: Stable technology that lots of people understand.

Either DB engine would fill the bill; I would use MySQL because that's what I know. I can make it dance to my tune and can work around its issues.

A typed language like Java or Go will work better in the long term with changing teams. Both are easy to hire for, and the type systems help minimize the complexity of working on an old code base.

The very first question I'd ask of the frontend is "how much does it really need to be an SPA?" An SPA increases the complexity while simultaneously lowering compatibility across devices. If it doesn't have to be a SPA, don't make it an SPA just because it's "in" now. For technology choices, I'd defer to my frontend brethren.

Caching: Memcache or Redis. Both are bulletproof.

I'd likely host it on AWS, with one big caveat: limit your integration with them. If your application can be easily lifted out of AWS and into GCE/Azure/DO/..., you can negotiate some really good prices out of them.

Postgres, PHP w/ Slim Framework, Python w/ Django, React, Redis, AWS.

This is a combination of things I'm most familiar with and things I'd build shit in if not for the fact that other devs at my company aren't familiar with it. i.e. We use MySQL everywhere, so I can't just spin up a new project using Postgres for the sake of consistency.

For the API layer: If you're sure that the app is going to be for the long-term, and you know what you're going to build (rather than a prototype), choose a SOLID framework.

Having been burned by others, my choice is Symfony. It has set EOL's for each release [1], a strict backwards-compatibility policy [2], is well tested, and has good documentation.

You haven't defined long-term, but I maintain software I wrote over a decade ago, and learned the hard way how important these features are. More than the tech itself.

For everything else: Choose proven technology. Choose databases that aren't reliant on VC funding. Avoid the hype train.

1. https://symfony.com/roadmap#checker

2. http://symfony.com/doc/current/contributing/code/bc.html

Your technical stack should not be frozen. During years, it will probably evolve, either to use some promising features of new technologies, or to still be able to hire. For instance, hiring some Cobol developers is really hard (and then expensive) these days.

More important than technologies is testing. If your whole app is well tested (with both unit and E2E tests), you won't be reluctant to upgrade some part of your system because it doesn't answer your needs. Moreover, it would bring a lot of reliability and would be self-documented. That's the biggest point IMO.

For nowadays mood, we are really glad using React, Node, GraphQL and PostGreSQL for all our apps.

Note: we wrote a blog post about one of our long running customer story, which may interest you: https://marmelab.com/blog/2018/03/28/1859.html

Node is fine for the frontend -- I'd go with React and React Native personally -- but between NPM issues and a general cowboyishness, I wouldn't go near it on the server-side.

Backend/API layer would be one or more of Ruby, Python, or Java, depending on what my team felt comfortable with. Large, mature communities, healthy ecosystems, overall decent tooling, good support for testing and deployment automation.

Nothing Microsoft. Not going down that road again if I can help it.

AWS hands-down. Google tends to have this pathological distaste towards providing support for their customers, and I don't trust them to not just shutter any of their non-core products randomly one day.

I am very sold on GraphQL or Protobufs as the interchange format over REST.

Databases, hard to go wrong with PostgreSQL. Redis and Memcache for caching.

These components form the backbone of the analytics app we are working on.

"DB engine" / Long term state storage: Kafka w/ RocksDB*

API layer: Node/GraphQL

Frontend: React

Caching / Short term state storage: Redis (if/when needed)

PaaS: Something like local Kubernetes w/ possibly some Istio and OSS services such as Spark when needed

*) We are currently building Microservices using local state storage in RocksDB which really (ahum) rocks. We plan to offload serious queries and data slicing to Elasticsearch.

Our current reactive microservice infrastructure is homegrown (due to it being written using .NET Core (and a sprinkle of Reactive Extensions) but if you are able to use Java or Scala you can (in some ways) get a even better version of our microservice infrastructure using Kafka Streams (the KTable and KStream primitives look really nice).

Postgres / Django / Vue / Redis / AWS

I think a crucial part of the equation is the context. I'll give my answer with that in mind:

DB engine:

Postgres or otherwise MySQL, unless I'm planning to do something specific that clearly warrants the use of something else. Too often I've regretted using something more 'exotic' for no really good reason.

API layer:

If this is something I'll mostly be building myself, definitely Phoenix/Elixir, unless the Rails/Ruby or Django/Python ecosystem has something that I 'need'. If hiring 'cheap' bodies is at all a concern, I'd go for Django/Python or Rails/Ruby. But at this point I'd rather hire that one developer (remote or nearby) who is itching to use Phoenix/Elixir over five of the alternative. And I think any decent Python/Ruby programmer could pick up what I started with pretty quickly.

Frontend SPA:

Just myself: React. If I need to work with others, possibly Vue, but most likely React still. I would probably start out with TypeScript right away, and go for the most 'vanilla' possible everything else (Webpack, Redux, React-Router, Babel, bits of Lodash perhaps).

That said, while last year I would never consider this, I'd probably go for a 'good old' server-side templating approach (w/Phoenix) with some React/Vue components sprinkled in. Even with the best of devs and the best of tools, front-end just strikes me as still too fiddly, too labor-intensive, and too expensive (front-enders often cost more than back-enders, or am I wrong with that impression?) to be worth the effort. Obviously this depends entirely on what's being built though.

Caching:

With Phoenix, possibly none at first. Otherwise I guess something on the nginx side? Not sure if I can see this mattering too much until later in the process.

PaaS:

No. unless there's a good justification for it. I still lean towards using a VPS or something like that, at least until things get out of hand.

No hype, just use simple, proven technologies. No MongoDB, no React, ideally no SPA at all, just plain HTML and tiny bits of Javascript when/if needed.

My personal pick would be a Django app with Postgres as the DB, Django REST framework for the API endpoints (if needed), Redis for caching, and that's pretty much it. Platform is irrelevant as it might change in the long term, so I'll pick whatever is easiest/cheapest at the time and be done with it; the platform can always be swapped out later if needed.

Appengine flex, Google Pub/sub, postgres, Java (doors open for kotlin in the future), lombok, Dropwizard, typescript, react, redux, redux-thunk,css-modules, hostedgraphite, sentry.io, circleci.com.

No ops team. Maybe replace Java/Dropwizard with more Typescript and express if the same people will do Frontend and backend.

That's my dream stack. I've used all of this at some point in my career and I really believe their drawbacks are very worth it.

I'm not sure about the stack (depends on what you are comfortable with, your requirements...) but:

1. use something that has been around a long time and is well supported/known

2. you probably don't need stuff like cassandra or other "big data" data stores (just yet). PostgreSQL/MySQL is plenty fine to start with (and easier to manage/think about).

3. please use only a single cloud provider.

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.

For our SAAS we're running:

- DB Engine: MariaDB on RDS (multiple instances) + Redis for specific use cases. - API layer: Symfony (PHP) - Frontend : React - Caching: Redis - Ops: Rancher Orchestration on EC2, and a bunch of AWS features like S3, ALB, ...

We had some hiccups here and there, but I'd say we are happy with the stability of it.

A No hassle, No worries plan is to use AWS. It's going to scale, and not on you for everything (deploying, packaging). Zero provisioning, and pay as you use. You'll get up and running very fast with low costs, high reliability.

DB: dynamodb

API: API Gateway and AWS Lambda

Frontend: angular 2+, or React

Cache: AWS Elasticache

Blob Storage: S3

The stack should be chosen based on the requirements, not just "needs to be a long term application".

Honestly I echo the Java suggestion plus a rdbms. You have a big talent pool, it's well supported and "enterprise stable", and it's multiplatform.

Tech or nontech business? Engineering driven org or not? Size of org? Structure of existing team? Relationship of this team to other teams? Overall structure of org? Hiring strategy? Where in culture spectrum does your business require you to be?

The investment in the stack should be based on team's skills and strengths. If they are good in Ruby/Rails, then choose that or if they good with JVM based tech, then choose Spring or Play.

https://www.google.de/search?q=choose+boring+technology :)

Ruby with rails or php with laravel, the js stacks are too new and too hip for a long term application, go with a mature stack that doesn't change with the wind

bballer start with requirements and then evaluate tools/stacks based on that. Your requirements will help guide your research of what's out there and is best for the job.

All technical disciplines use this approach including ours.

While it seems helpful and fun to see what other people are using, you'll come to find that it's just a salad of product names and marketing gibberish. ;)

Trust your process.

Database: Postgres

API layer: PyPy (Flask) w/ Golang (Swagger)

Frontend SPA: Plain HTML/JS with some CSS and webpack for ES6 suport

Caching: Memoization

PaaS: My own home server running w/ Docker

DB: Postgres

API: Postgraphql (generate graphql from postgres schema and stored procedures automatically)

Frontend SPA: nextjs framework with reactjs

Cache: Depends on the usage e.g. Redis

PaaS: Heroku

Postgres + Go + Vue.js + Redis + AWS

Go with or without any framework (like Buffalo)

Vuejs with Vuex

Definitely the most serious, serious tech stack available.

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.

Consider not doing an SPA. A classical web-app will get you to market sooner with fewer bugs. Here are some big issues with SPAs:

- Unsubmitted form input is not automatically saved in history by the browser, so you must write code to cache it and restore it again if the user leaves the page. A classical web app can identify all the form elements before rendering, so this functionality is free with a non-SPA.

- If you use the browser History API to allow navigation within your SPA, you'll have to write code to cancel async requests upon navigation. With a classical web app, the browser will cancel them all for you and provide a handy UI for the user to do it themselves.

- If you have lots of views within your SPA, it's going to get big and then you'll have to structure your project for code-splitting.

These are the top three issues that I've had with building my SPA and I've spent way more time putting together all the infrastructure instead of building user-facing views and logic because I won't ship a broken app. At this point, I might as well pivot my app to be a developer tool for building SPAs! (No kidding - I'm actually considering throwing away months of work to start over with a classical web app after all this.)