Live data from Hacker News

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

news.ycombinator.com

51–60 of 80 posts

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

#51
post #6

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…

Wow, that's pretty hardcore...borderline badass! Interesting thing is this stack was doable probably 13+ years ago, so I see your emphasis on stability. Anyway, it's similar to what I'm using and surprised to see it here. Biggest tweaks are that I'd consider Vue/Webpack if starting today and do believe PaaS to be far superior to on-prem/colo. Also, not big on Hibernate or too much abstraction at the data access layer…

Could you elaborate on the PaaS? I've been avoiding it, but partly that's perhaps because I'm a control freak and not for any particularly good reason.

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

#52
post #50

Earlier quoted context omitted.

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?

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…

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.

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

#53
post #39

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 (N…

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

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

#54
post #50

Earlier quoted context omitted.

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…

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.

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

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

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

#55
post #6

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…

I can see not using PaaS, but strictly going in-house or colo seems odd. Not saying that there aren't reasons for this, but IaaS, rented servers, ... all are options with more flexibility and little lock-in.

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

#56
post #55
post #6

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…

I can see not using PaaS, but strictly going in-house or colo seems odd. Not saying that there aren't reasons for this, but IaaS, rented servers, ... all are options with more flexibility and little lock-in.

Agree on IaaS. I missed that in there.

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

#57
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.

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

#58
post #54

Earlier quoted context omitted.

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.

I think it's a matter of luck and/or scale. On tiny projects it seems fine but we're huuuuge.

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.

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

#60
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'.

Post reply on HN