
Ask HN: What tech stack would you choose for a serious, long-term business app - bballer
If you were about to start building a very vital brand new application for your company that needs to be maintained long term what tech stack would you choose? Put aside what devs at your company may already be comfortable with and lay out what you think is best.<p>When I ask tech stack I&#x27;m talking the whole dam thing, for example:<p>DB engine : ie MySQL, Postgres<p>API layer : ie Node w&#x2F;joy, Java w&#x2F;spring, PHP w&#x2F;laravel, Elixer w&#x2F;phoenix<p>Frontend SPA : ie React, Vue (do you use typescript or flow, webpack etc)<p>Caching : ie Redis, Mongo<p>PaaS : ie AWS, Google, Azure<p>Interested to hear your thoughts, and don&#x27;t want any flame wars stating x is always better than y etc.<p>Feel free to just specify the stack but better to also back up why you think it is best in a few sentences.
======
nathan_f77
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](https://convox.com) and
[https://github.com/convox/rack](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.

~~~
setquk
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.

~~~
Tobani
While memcached is great. I feel like its hard to argue for both redis AND
memcached. It seems like redundant infrastructure unless you have very
specific needs.

~~~
nathan_f77
It's not a good idea to use a single Redis instance for both caching and
persisted/transactional data (background jobs). For background jobs, you need
real-time persistence with AOF. For caching, you want everything in memory,
and you need an LRU cache that evicts any old data. This means you should run
two Redis instances with different configurations. But in that case, it can be
a good idea to use Memcached, which is recommended by Mike Perham [1].

[1] [http://www.mikeperham.com/2015/09/24/storing-data-with-
redis...](http://www.mikeperham.com/2015/09/24/storing-data-with-redis/)

------
al2o3cr
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.

~~~
hood_syntax
I'd like to second the important of staffing. If we were in a perfect universe
we could use domain oriented languages for every project because devs would be
familiar and competent with them. Obviously that is not the case.

~~~
wink
I know it's kind of cliché and in my last project it also wasn't soo bad, but
Java is not something I associate with lean and nimble. I know, OP didn't ask
for that - but it sounds like the inception phase of a product, and I can't
imagine working any other way than "release early, release often". Long-time
support viable? Very probable.

------
jjude
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.

------
aascher
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'.

------
scarface74
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.

------
setquk
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.

~~~
alex_hitchins
For me at least, I'd definitely go .Net Core. And I'd not have issues using
MySQL either. True, there are fads and fashions that come and go, but over the
last 15 years I've not had an issue building and maintaining applications of
all varieties built on MS technology. Plus, given the current owner of Java,
I'd stay well clear of it. Already moved anything that was MySql over to
MariaDB.

~~~
setquk
I couldn't possibly consider .Net core on a number of reasons I didn't discuss
above. Opt out telemetry, constant direction changes, who is in charge of the
project and the general abusive nature of the company running the show towards
its customers and end users over the last decade. The list is endless.

I have actually tried to get things fixed on MSFT open source projects as well
and even when you get up to Scott Hanselman poking it on github, nothing tends
to happen. On top of that many crippling bugs remain unresolved for so far 9
years. We have unreliable tooling, portability problems, all sorts.

On a larger team and product, it's a non trivial time and cost sink.

~~~
alex_hitchins
What was the bug that remained open for 9 years? Was it part of the .net
framework or a Windows SDK issue?

What sort of projects did you have the most trouble with? Where were your pain
points?

~~~
setquk
Sorry was 8 years ... ClickOnce refused to launch on over 2000 machines when
they removed download prompting from IE9. This sits between the .net framework
and the IE team, neither of which would take responsibility for fixing.
Eventually we got a registry fix out of them from bottom line support which
turned download prompting back on which was removed from the IE UI but still
left in there. The registry fix we had to deploy to hundreds of clients and
had a massive support cost. This is still broken in IE11. It was reported on
an IE9 beta.

Pain points: large project performance, high concurrency projects, IDE
reliability, cost, odd time sinks, bugs in the framework, lack of automation
possibility for a vast number of project types (try building VSTO applications
on a CI server), deprecations (WWF/WCF changes, AppFabric, Velocity etc) all
sorts.

~~~
alex_hitchins
Thank you for this response. I'll not counter each point as that will get us
nowhere and serve no purpose. I'm just very interested in how two people can
have such polar views on the same technology.

~~~
setquk
I think it's a matter of luck and/or scale.

On tiny projects it seems fine but we're huuuuge.

~~~
alex_hitchins
I'm not familiar with the size of your code estate so I can't compare. I've
certainly worked on some 'big' projects with .Net. In terms of users and
application structure.

------
scaryclam
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.

------
vincentdm
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.

~~~
levimaes
I think the gRPC team/community has been fast at work on a
Golang/Node/Java/Haskell + Docker RPC tool; maybe you'll find some insights at
their 'grpc-ecosystem/grpc-gateway' or 'grpc/grpc-web' GitHub repo home pages
-- for your API format. It might tie back nice and conveniently to Minikube
and K8S -- if gRPC is compatible with Clojure (essentially Java?).

------
eb0la
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 s __t done.

~~~
Can_Not
VueJS is getting pretty popular in that stack, it can operate in SPA mode like
react, but also has first-class documentation for not being the dominant
"framework" on your front-end (e.g. if your site's front-end is mostly boring
but one or 2 pages need something fancy that doesn't already exist as a jQuery
plugin).

------
bausshf
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.

------
OhHeyItsE
> 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.

------
nathan_long
> 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.

------
Herbert2
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.

------
billysielu
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.

------
falcolas
> 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.

------
needcaffeine
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.

------
pbowyer
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](https://symfony.com/roadmap#checker)

2\.
[http://symfony.com/doc/current/contributing/code/bc.html](http://symfony.com/doc/current/contributing/code/bc.html)

------
jpetitcolas
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](https://marmelab.com/blog/2018/03/28/1859.html)

------
donw
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.

------
mindcrash
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).

------
spectaclepiece
Postgres / Django / Vue / Redis / AWS

------
happywolf
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).

~~~
wasted_intel
> the market has more Java or PHP engineers

That's a quantity over quality argument. Assuming there isn't an _extreme_
shortage, I'd opt for a language and/or framework that tends to attract higher
quality candidates. Personally, Ruby/Rails feels like it hits the sweet spot
there.

------
mercer
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.

------
Rjevski
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.

------
midrus
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.

------
chronid
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.

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

------
drcongo
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.

~~~
mercer
I agree 100%, but I'm curious how you feel about the state of Phoenix/Elixir
when it comes to popularity.

I'm perhaps too inexperienced/young to know how these things tend to shake
out.

That said, my impression is that it has enough of a foothold, and with Erlang
enough of a solid base, that I wouldn't end up in a situation, say, 10 years
from now where the whole ecosystem is a ghost town and I need to move to some
other language/framework. And based on my research it's even quite possible
that Elixir might end up becoming a formidable player.

But I don't feel certain enough about this to recommend Elixir to a new
startup, for example. I'd love to hear other people's thoughts on the matter.

~~~
drcongo
I'm old enough to wait until a technology has somewhat proven itself before
jumping on it for client work, personal / internal projects are the perfect
place to try this sort of thing out though and get a feel for whether you
think it can succeed. I've had a pretty minimal play with Phoenix and I liked
what I saw in terms of developer productivity and application performance,
things looked a bit less certain when it came to CI and deployment though.
This was a while back mind, and these areas may have improved a lot since
then.

------
nielsv
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.

------
catchmeifyoucan
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

------
chomp
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.

------
dustingetz
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?

------
gshakir
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.

------
wink
[https://www.google.de/search?q=choose+boring+technology](https://www.google.de/search?q=choose+boring+technology)
:)

------
petraeus
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

------
machinemob
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.

------
lambda-powrz
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

------
pencilcheck
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

------
neya
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](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 :)

~~~
mercer
I'll add that I love the 'with' keyword when piping doesn't cut it. Other than
that I've also found that until about a year ago I would've recommended Rails
or Django, and now I'm all for Phoenix/Elixir to a fault (as in, I'd even
consider using Python packages _from_ Elixir over going for Python because of
those packages. Or cut out the middle-man and get a C guy to join the team).

------
Gonzih
Postgres + Go + Vue.js + Redis + AWS

Go with or without any framework (like Buffalo)

Vuejs with Vuex

------
rajacombinator
Definitely the most serious, serious tech stack available.

------
throwaway2016a
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.

------
hungerstrike
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.)

