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.
Ask HN: What tech stack would you choose for a serious, long-term business app
61–70 of 80 posts
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#62As 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…
In contrast I'd like to offer our competing ServiceStack framework as an alternative (commercial) platform [1] which has been in active development since 2008 that in contrast to the ever changing MS frameworks offers a single integrated Web Services [2] and Web [3] solution that has maintained the same clean, stable high-level message-based API throughout its lifetime. It was created out of frustration in the WCF/WebForms era [4] where we were the first to offer an integrated IOC, impl-free/testable multi-provider logging, caching, virtual files and configuration providers, clean/extensible typed user sessions - all using high-performance components. The first to run on .NET Framework and Mono, the first to create high-performance JSON and text serializers and fast typed ORM, which at the time they were developed were several times faster than anything MS offered [5].
All pre-dating Web API [6] and outlasting the continually changing fragmented MVC/Web API "framework in a framework" coupling as well as the rolling churn of abandoned OWIN/katana abstractions [7]. Instead we've maintained clean impl-free IRequest/IResponse interfaces which provides a lightweight abstraction over the underlying platforms concrete HTTP Request/Response abstractions where we're still the only framework where the same ServiceStack App can run on classic ASP.NET, self-hosting HttpListener (.NET Framework or Mono OSX/Linux), ASP.NET Core on .NET Core (Win/OSX/Linux) and ASP.NET Core on .NET Framework v4.7 [8].
As a result of our stable surface area we still have older v3 (BSD) Customers upgrading to our latest commercial version just so they can leverage their existing investments to run on ASP.NET Core which is relatively easy to port [9] where most of our .NET Live Demos [10] have been ported to run on .NET Core [11].
Unlike any of MS offerings, ServiceStack:
- Has never abandoned any .NET library, our libraries are continually enhanced and maintained, not rewritten or discarded
- The same Services implementation supports multiple formats out-of-the-box, can be called from multiple HTTP / MQ / SOAP endpoints, on multiple hosting options [12]
- Provides native, end-to-end typed development experience for C#, TypeScript/JS, Java, Kotlin, Swift, F# and VB.NET [13]
- Has no prejudice towards MS products, our libraries work equally well on all platforms/back-end providers, e.g. OrmLite [14] provides a high-level typed DB agnostic API across all major RDBMS's. Whilst SQL Server is our most popular dialect (courtesy of marketing in .NET), we personally prefer/use PostgreSQL and its a popular configuration to configure Unit tests to use SQLite for faster Integration tests.
- Provides clean abstractions of multiple providers for AWS [15] and Azure [16]
- Has its own flexible Auth Provider model [17] which hasn't had a schema change and never needed a "migration" whilst being continually updated to support new providers
- Has an aversion to complexity, instead of blindly adopting over-engineered solutions we develop our own cleaner alternatives. Some examples of this include AutoQuery vs OData [18] Add ServiceStack Reference vs WCF Service Reference [19], Templates [20] vs Razor [21]
- Offers a Simple and "pure Cloud App" solution for developing .NET Core Apps with built-in hot-reloading and without any compilation or builds [22]
From 2013 we've adopted a sustainable dual licensing model (commercial for closed-source or OSS/Free for OSS projects) which has allowed ServiceStack to be actively supported and maintained and continually updated with new releases [23].
Anyway I'd like to offer ServiceStack a stable competing framework for .NET and .NET Core that's being developed from a different mindset/values which has evolved gracefully over the years and stands no risk of abandonment or rewrite with many of our Customers sharing a different experience [24] than if you've had to live through the churn of MS's multiple framework rewrites.
[1] http://docs.servicestack.net/why-servicestack
[2] https://github.com/ServiceStackApps/HelloMobile
[3] http://razor.servicestack.net/
[4] https://www.slideshare.net/newmovie/what-istheservicestack-14819151
[5] http://mono.servicestack.net/benchmarks/
[6] http://mono.servicestack.net/mvc-powerpack/
[7] https://servicestack.uservoice.com/forums/176786-feature-requests/suggestions/4851342-owin-compatible-servicestack
[8] http://docs.servicestack.net/releases/v5.0.0#servicestack-mobile-and-desktop-apps
[9] http://docs.servicestack.net/netcore#exceptional-code-reuse
[10] https://github.com/ServiceStackApps/LiveDemos
[11] https://github.com/NetCoreApps/LiveDemos
[12] http://docs.servicestack.net/why-servicestack#multiple-pluggable-formats
[13] http://docs.servicestack.net/add-servicestack-reference
[14] https://github.com/ServiceStack/ServiceStack.OrmLite
[15] https://github.com/ServiceStack/ServiceStack.Aws
[16] https://github.com/ServiceStack/ServiceStack.Azure
[17] http://docs.servicestack.net/authentication-and-authorization
[18] http://docs.servicestack.net/autoquery
[19] http://docs.servicestack.net/add-servicestack-reference#advantages-over-wcf
[20] http://templates.servicestack.net
[21] http://docs.servicestack.net/why-not-razor
[22] http://templates.servicestack.net/docs/web-apps
[23] http://docs.servicestack.net/release-notes-history
[24] https://servicestack.net/#testimonials-carouselRe: Ask HN: What tech stack would you choose for a serious, long-term business app
#63API 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
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#64As 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 definitely sympathize with having to endure the perpetual rewrites of Microsoft Web and Web service frameworks. In contrast I'd like to offer our competing ServiceStack framework as an alternative (commercial) platform [1] which has been in active development since 2008 that in contrast to the ever changing MS frameworks offers a single integrated Web Services [2] and Web [3] solution that has maintained the same c…
The only desirable feature was Redis sentinel but we can live without that.
Honestly we can just switch parts of the system to another platform for the same cost and get an ROI over a couple of years.
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#65Earlier quoted context omitted.
I definitely sympathize with having to endure the perpetual rewrites of Microsoft Web and Web service frameworks. In contrast I'd like to offer our competing ServiceStack framework as an alternative (commercial) platform [1] which has been in active development since 2008 that in contrast to the ever changing MS frameworks offers a single integrated Web Services [2] and Web [3] solution that has maintained the same c…
Thanks for the write up. We evaluated ServiceStack and the license conditions, lock in risk and cost for a supported product across our estate was prohibitive. The only desirable feature was Redis sentinel but we can live without that. Honestly we can just switch parts of the system to another platform for the same cost and get an ROI over a couple of years.
It's a different world with a much improved development model that I find vastly superior compared to traditional classic ASP.NET Framework Web Apps - which I don't see myself ever creating greenfield Apps for again.
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#66Earlier quoted context omitted.
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.
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.
[1] http://www.mikeperham.com/2015/09/24/storing-data-with-redis...
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#67Earlier quoted context omitted.
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.
That is, I would advocate PaaS and IaaS over on-prem/colo, and how far you go towards PaaS is a matter of comfort.
I do think that comes down to control though, and I actually can't think of a much better basis for the decision.
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#68LAMP (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.
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#69API: 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
Re: Ask HN: What tech stack would you choose for a serious, long-term business app
#70"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).