31–40 of 80 posts
DB: dynamodb
API: API Gateway and AWS Lambda
Frontend: angular 2+, or React
Cache: AWS Elasticache
Blob Storage: S3
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.
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.
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.
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 cr…
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.
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.
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.
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)
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
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 :)