Ask HN: If you were to build a web app today what tech stack would you choose? Not for your current job. But if you were starting a new passion project. |
Ask HN: If you were to build a web app today what tech stack would you choose? Not for your current job. But if you were starting a new passion project. |
Frontend: Lit and Tailwind (in reality, unocss, a tailwind runtime that doesn't need build)
Database: indexeddb + some CRDT
Backend: no backend, webrtc to sync between devices without a central server
Hosting: Github and cloudflare cache, the app has a functionality to deploy itself, generating a minified tailwind CSS and if needed, a "SSR" version of it (but without hydration, this is the part of the frontend craziness that I don't wanna get close).
I’ve built several projects like this and just started another one and it is by far my favorite stack.
I don’t like spending time fighting frameworks, so I like to keep my stack as minimal as possible. Thankfully the Go ecosystem pretty uniformly shares that ideology.
Seems super simple to get up and running and let's you focus on the product itself rather than the stack.
Alternative answer: Use whatever you're most familiar/comfortable with.
https://github.com/refinedev/refine
It has built-in integrations for UI libraries and data providers. You can select your stack
I keep changing my mind. Part of me wants to use old school tech. But I do like the DX of Next.
NextJS tends to make sites that need JS on the front end. And probably bigger bundles than an old school MVC job. I will take that hit though for some of the positives of working in React and productivity and modernness and community of great work around React.
I think I might use Bootstrap but I'd heavily customize theming.
Probably SvelteKit or Vue for the frontend. Most likely SvelteKit.
SQLite or a flat file database for sure.
I think what I would do is use Tornado to serve SvelteKit pages, if I went with Python.
Definitely a monorepo for front and back end. Probably I'd try to do zero server side templating.
I’m planning to try out HTMX + a backend written either in Rust or Go. Since it’s a passion project it doesn’t necessarily need to be out there for thousands of users, so I’ll go with SQLite.
- HTML
- JS (Ecma Script, not some "framework")
- CSS (not "Typescript" or whatever, standard CSS)
Edit: The same would apply for $job
(Typescript, tRPC, Tailwinds
Next.js React, Prisma, Zod
Bun)
Client and server in one project and language. All the trendy, still free, easier to use compute instances let you deploy javascript server projects. Many don't support other stacks like Java or Python. Heroku supports python but no longer has a free tier.
Also, this stack is free if using vercel + supabase until you reach an BIG userbase
Backend: ASP.NET Web API (REST). Only calling these APIs from the backend-for-frontend Node code.
Hosting: Everything at one Cloud provider, either Azure or AWS. No SaaS-services.
Database: Postgres
Infra: Terraform or Bicep for infratructure as code, and Docker.
Would prefer go on the backend but language switching when doing frontend at the same time is a bit of a pain.
Probably Laravel with Livewire and Lit for creating interactive widgets. Postgres for the db.
Tomorrow: Who knows.
Frontend: Flutter
If Flutter is not possible or suitable than htmx + bulma (or w3c, pico etc..).
- SSR SvelteKit with Hydration (https://github.com/sveltejs/kit)
- PostgreSQL database server
- Postgres.js - PostgreSQL client for Node.js (https://github.com/porsager/postgres)
- Migration powered by graphile-migrate (https://github.com/graphile/migrate)
- PostgreSQL Row-Level Security (https://www.postgresql.org/docs/16/ddl-rowsecurity.html)
- svelte-headlessui (https://github.com/rgossiaux/svelte-headlessui)
- sveltekit-i18n (https://github.com/sveltekit-i18n/lib)
- TailwindCSS (https://tailwindcss.com/)
- Superforms (https://superforms.rocks/)
- sveltekit-flash-message + svelte-french-toast (https://github.com/ciscoheat/sveltekit-flash-message + https://github.com/kbrgl/svelte-french-toast)
Tooling :
- asdf (https://asdf-vm.com/)
- Docker and Docker Compose
- NodeJS
- pnpm
- Jest for unittest
All deployed on a VM at Scaleway (https://www.scaleway.com/en/) with Bash script (https://github.com/stephane-klein/sveltekit-tendaro-webshell...)
After 3 months of development on this stack, I'm very satisfied. My application is fast, light and requires very little code.
Project skeleton example: https://github.com/stephane-klein/sveltekit-tendaro-webshell...
Mainly for the following argument:
- It is built for SvelteKit and has good SSR support.
And also, the following:
- The translations are loaded for visited pages only. (and only once!) - As of v2.4.2, the size of the sveltekit-i18n package is 14 kB in the minified form and 4.6 kB in minified + gzipped form
From https://blog.aakashgoplani.in/comparing-i18n-libraries-in-sv...
FE - Typescript, React, Tailwind
DB - Postgres
Cache - Memcached
Server/Routing - Envoy
- Either vanilla js or vue.
In a while, s/node/bun
Go on the server is fine as well.
Plain SQL with Postgres
React
Backend: Golang standard lib, gorilla/mux for routing Front: htmx + tailwind
If i need a database, i tend to start with redis, then sqlite and ONLY if it scale, postgres!!
Also tried Remix for a few smaller projects - didnt really fly but was quick to develop.
Fastify has been game changer for me.
Flask / HTMX / Pico.css / Postgres or Sqlite
Dockerized so that it's easy to spin up.
Edit: Caddy for webserver.
- infra on AWS via AWS CDK TypeScript
- backend domain plain TypeScript
- frontend plain React, no framework (TSX)
- database RDS Aurora serverless v2 (Postgres)
- monorepo using pnpm
Choosing a stack has always been a balance between "what you are currently productive in" and "the best possible tool for the job."
These days, assuming you have a base level of skill and experience, it's like 2-10x easier to get up to speed in a brand new stack thanks to those AI coding buddies
Your current competencies still matter and always will, but today, IMO we're way more free to choose the "best" tool and assume that we can get up to speed quickly.
Putting that aside, I still think Rails is amazing for "most" webby stuff. Would consider Flask if I needed things from the Python ecosystem. Or I guess Phoenix if I needed that massive concurrency. Would pair them with Postgres and/or Redis as needed.
For frontend... Vue? Or maybe just server-side rendering if I could get away with it.
Most of what you need to get something functional and not totally ugly, not a lot that you don’t.
Accessible Powerful cost Effective
relative to your audience and available resources.
I would pick flutter / istio / booternetes / helm
For more complex projects it’s normally Tailwind
Backend: AWS Appsync (or AWS API Gateway) integrated with AWS Lambdas written in Golang. Authentication through AWS Cognito. DB: anything serverless from AWS (Dynamodb, Aurora etc.)
This way the app would be 100% serverless, no need for effort to scale it or to maintain the infrastructure (apart from automating the ifrastructure through AWS CDK).
Serverless is cool when you start with 300 users and you’re still in the free tier plan. After that, it’s going to cost you a fortune when you really need to scale, and I’m not even thinking about the time that you would need to waste writing everything back to a monolith/microservice, because that is what’s going to happen most likely.
Was fun running on lamba etc, until as you say, the costs starts soaring massively. Moved it to a cheap VPS and never looked back.
But I believe that, in the early days, Drupal made excellent foundational design choices as a framework, and if you used it's APIs in your custom module development, then, generally speaking, you would have a secure website.
But now, D7 is approaching EOL, and I absolutely don't want to migrate to the latest flavor. D7 has been rock solid for a decade, and I have no desire to chase the latest fad.
I wish that there were a stable, monolithic solution that is simpler to setup (as in including everything, including database, webserver, SSL certs, etc.) that just worked and was extendable and overridable programmatically, in the same way that Drupal was.
Modern web stacks have become a bucket of Lego pieces that seems ok if you are an expert in everything and know how to put everything together exactly. The problem is, most people aren't experts in form handling, login and authentication, media handling, caching, etc.
if the passion is to learn some new tech then well, there are lots of options, i'd pick something that i haven't worked with yet.
if it is something where the passion is in the content, i would use the same old stack that i used for my last few projects. in my case that is aurelia+custom backend which is a reusable object storage and user management platform, where i didn't need to add any project specific features for some time now.
if i could not use that backend, i would pick something that makes it easy to manage objects through a REST API.
if i had to evaluate a new framework then the main thing that i would look for is the ability to minimize or avoid any dependency on build tools.
unfortunately, with the rapid evolution in frontend frameworks there is also a rapid evolution in build tools. that just adds extra effort to maintain a site for more than a few years.
without buildtools getting in the way i can maintain a site with minimal effort, and i know it will still be running in a decade from now.
Functional programming, pattern matching, and immutability make life a lot easier.
It's all built in, you can buy packages that implement most SaaS features out of the box, authentication, 2 factor, all the crap you need is rolled in as packages.
I would stick with something like Orchid for admin type CRUD apps as there is ZERO html/js knowledge required.
for a public app - I would still use Orchid on the backend and then on the frontend use something simple with blade templates and controllers.
PHP is a lot better than it was, Laravel developers are easy to find, the stack is very well understood, and it's flexible enough to build whatever you want.
EDIT: I just wanted to add 99% of "apps" are not retail facing but are internal apps or business to business type apps that solve a specific business niche. For that, I only care about how fast and easy is it to stand up and implement that specific business logic.
It's simplicity has been a fresh of breath air. I love Go and being able to use it for almost the entire web app is amazing. I am excited for the upcoming router enhancements Go has proposed, that will let me move off Chi router. I try to stay as close to the std lib as possible. Though, the `templ` package is amazing and I very much will continue to use it when possible.
For my database I use `libsql` by Turso with server mode.
As for deployment, I just dockerize the app and the database then run them as two separate components in a Docker App.
Makes it a simple and easy to develop and deploy updates.
SvelteKit is the best combination of front-and-backend in terms of performance and developer usability that I've found.
If I was trying to learn something new, I'd experiment with solid.js or htmx.
For anything new, I'd try Phoenix to see what I can achieve with Elixir and a non-React/Vue frontend.
Choice of stack is simple: it may not be the best in class or fancy choice, but it’s close enough, allows simple infrastructure setup, quick start with rapid iterations and easy to go from 1 dev setup to a team. More importantly I have a lot of experience with this stack, so I can focus on business rather than on learning new technology.
Depending on the frontend need, I might go with straight server rendering static pages. So often the big stack of rendering contexts and HOCs and blah blah blah just gets in the way. Rendering a view shouldn’t be difficult, and progressive enhancement is easier starting from strict HTML + well structured CSS.
I love React, I’d be happy to try Svelte… my fear in not doing that would be “when we eventually need it, it’s difficult to opt in progressively” (which is terrible).
Which of those depends on whether the focus of the passion was exploration of new tech to make an impact on my understanding of tech or exploitation of existing tech to make an impact on the world.
If it was the former, today I'd probably learn Rust + whatever webapp stack is popular in that language. Seems to make some pretty interesting guarantees around programming and is blazing fast.
If it was the latter, I'd pick rails. Nothing in my experience beats rails for productivity for a bog standard webapp.
Go backend. Single binary. Big performance. I’d use Go for as many things as possible until I actually had a need for distinct technologies (queues, redis, etc.). Throw embedded db into the mix and you shouldn’t have any problems for a long time.
React UI on cloudflare pages. Free. Easy.
Postgres. Single node goes far. Great plug n play extensions. Same as with Go I can push this pretty far until there is some serious requirement to do something else.
Deploy on either cheap bare metal or an affordable provider like DO.
Currently I always have a little redundancy in my projects when it comes to the JS HTTP client that calls the golang backend's API and I want to avoid that.
I usually just make the types by hand on TS client.
Maybe gpt :p
- Backend: Django (Postgres in production) + Celery to handle async tasks - Frontend: HTML (standard django renderer), CSS, HTMX + occasional jQuery - Deployment: Render
I was already familiar with Python and I feel the language is more than capable to handle the data processing required and with Django I could concentrate on the actual app functionality without diving too much into auth etc
For me it would be:
*Django* for backend with the built-in templates. No frontend backend split.
TailwindCSS for styling.
StimulusJS for sprinkling JS wherever needed, which is not very often.
Postgres as my DB (although if I'm not integrating Stripe, SQLite will suffice).
Maybe Redis for caching and as a broker for background tasks, if needed.
Of course SQLite has limits but it takes a lot of complexity or concurrent users to come close to them.
If it was a big corporate with deep pockets then I'll (or they'll force me to) go with React, Angular etc.
I've seen a lot of projects fail/struggle in golang (package ecosystem is still missing a lot of basics imo) or nextjs (very buggy).
.NET has been my secret weapon. It's boring, works really well, has a good ecosystem and asp.net is really well thought through and you can go as "deep" as you want with middleware etc. Plus performance is extremely good, as is the deployment story with docker these days (having to use Windows server with .net Framework a few years ago was a nightmare, enough to put me off, but in .net core Linux is a first class citizen now).
Also the IDEs are great these days, especially rider.
I feel that it's actually quite rare to run modern .NET apps on Windows Server now.
If not: the tried but true Rails + Postgres.
Add more things only when needed. For example Alpine.js if a bit of interaction that's not covered by Rails' Turbo. If the need for background processing arises, bring in the good_job gem, and there may be no need to deploy it separately at first.
For hosting I'm not quite sure these days. Heroku may be on life-support, but its feature-set covers most basis.
I'd probably start with Render for rails hosting these days. Seems to be the best heroku descendant.
I would pick what I'm most comfortable with, a simple monolithic Nest.js application running Fastify, with Postgres or SQLite, Dockerized, hosted on a predictably-priced host like Hetzner, and Ansible to automate everything. I know that stack will give me plenty of headroom until I eventually need to scale differently.
Front-end is still React, which has a massive ecosystem, and I feel like I can do _anything_ with it by just bringing in some dependencies, if it's a passion project then I want to deliver features fast, React allows me that.
I feel like a dinosaur, edge, workers, cloud functions... I'm familiar with none of that magic, there's probably a whole universe of amazing new ways to build for the web I'm sleeping on, but at that point I don't even care really.
For the former, I tend to reach for the tech stack that I've spent years working in and can very quickly spin up projects in. This is heavily specific to your background, but for me:
- Frontend: React, vite, react-router, Chakra UI.
- Backend: Node.js + Express
- Database: PostgreSQL
- Scheduled jobs/ML/data processing: Python
- Deployment/Infrastructure: Docker, docker-compose, AWS EC2 or Lightsail, Digital Ocean droplets, Netlify, Render
For the latter, there are lots of potentially better options, whether that's server-side rendering, serverless functions, etc. (Next.js, fly.io, supabase, are a few examples) and again depends on your industry.
If I had to get more people involved and have it scale I might go to Flask but might also go to a Java-based backend as it really has the best ability to use threads and parallelism.
As for HTMX I like it but I think there could be something similar but a little more feature risk, for instance my app has a lot of tables and tools that make it easy to add client-side sort buttons would be nice. If I had more people working on it I could see using a react-a-like system as well.
The database is arangodb which I love for rapid prototyping but if it had to be really reliable the first thing I would look at is postgres.
For me personally, I've been working on one that's pretty app-y and used Postgres + Deno + React/MobX (built with esbuild)
I'm very comfortable and happy with TypeScript, so I like having it on both ends (especially because I can share types between the two sides of the wire). And Deno and esbuild make the tooling story really simple and no-nonsense on the back and the front respectively, while being less opinionated than a framework like Next (I like Next for other things, just didn't choose it here)
It can easily be maintained by a single developer. Scales well enough for a decent number of users. Huge ecosystem of components. Easy to deploy to literally any web host. Wide variety of front-end systems.
If you need to scale, it can do that. Developers for it are plentiful. But you can always rewrite it in the flavour-of-the-month framework when you hit either scale or money.
I'm building a B2B2C marketplace in my free time and I'm blown away by the practicality of this stack. Due to longevity of Django, every problem I encounter is just a search away. DRF makes it dead simple to add REST APIs. The Admin panel is a golden cherry on top.
... Or the stack you're most efficient/ effective in. A short time-to-market is most important for learning. If you don't reach an audience, your project might bore you soon. Tech rarely is the holy grail to success.
Are there any patterns where you have an API with nice json payloads but also use htmx to push the rendering to backend? What do you do when you have users that just want basic data from the API? Do you add json endpoints, or is it more of a “fuck you learn how to accept html” situation?
"These two different types of APIs have different strengths and needs, so it makes sense to use both. The hypermedia approach can be used for your web application, allowing you to specialize the API for the “shape” of your application. The Data API approach can be used for other, non-hypermedia clients like mobile, integration partners, etc.
Note that by splitting these two APIs apart, you reduce the pressure to constantly change a general Data API to address application needs. Your Data API can focus on remaining stable and reliable, rather than requiring a new version with every added feature."
For frontend side, if i can get away with minimal js, i'd go that way. If not, highly depends on team and target interactivity. If it's just me, i'd go with LiveView
Turbo gives regular server rendered pages the snappiness of an SPA with zero dev effort.
The latest Hotwire allows easy replacement or lazy loading of any portion of a page.
All while preserving 10x developer efficiency. There’s simply no other stack with similar productivity.
(Not the original poster but came to this thread with “Rails” as the answer)
Hotwire is backend agnostic. Laravel has adopted it as a front end solution too.
There's nothing even close to the productivity we had back in the days of VB6/Delphi to be had on the web, ever. The closest we're going to get is a pale imitation.
There isn't nothing magical about VB6/Delphi, just a lot of work put there. Many JS developers are multiple times more productive than what was possible to accomplish with VB6/Delphi.
Do you have any suggested reading for what you're suggesting because I'm just about to start a project and as we do a lot of our LOB apps in Delphi this seems useful?
I have some existing code in pascal[1]... and it would be helpful for it to run in the browser.... lemme see how bad it is making this happen. It'll take a few days, I think.
I can totally see how a senior fullstack dev would have a completely different approach though.
Vite and TypeScript were new to me. I'd briefly used a older version of Vue for something. I currently deploy to Vercel, but don't have any Vercel dependencies.
I used Phind, ChatGPT, GitHub Copilot extensively in order to understand the "AI pair programming" experience. They were helpful for suggesting solutions and helping understand mistakes. Just to set expectations, the flow was less "problem→solution", and more "problem→try this→iterate→try this→iterate→solution".
Very fast to get going and nice developer experience. Love jamstack style hosting. Scales from simple static site generator that is free to host, to live APIs/dynamic pages, and back again without changing frameworks. Can make beautiful pages that load in 100ms and 30kb.
Currently using tailwind css because it also compiles (like svelte) and only ships what you use to the client.
Hetzner (bare metal) for hosting. Bash script for provisioning a server. Vanilla JavaScript only when necessary. Tailwind for design. nanoc for generating a static site.
If I were to start again, I'd pick the same stack again. It just works and gets out of the way.
Honestly though, the vast majority of webapps I implement are "boring" and the technology behind them needs to be boring and focus on productivity and maintainability. For this I usually select JakarataEE and JSF/Primefaces. Component based frameworks like this are stupid easy to slap together forms and business processes for internal webapps.
Ideally, I'd pick something that has OpenAPI as a first class citizen or code generation, including validation.
For a website, it'd be Go + HTML/CSS (sprinkling JS where needed). Here's why: (1) Code will "just build" years later (2) Deployment is stupidly easy -- just build to a single binary with all resources embedded (3) Everything about the stack is stable and easy to reason about. Though perhaps not exciting.
For a "web app", I feel there are no great options. The half life of the JS ecosystem is about 5 minutes, so whatever you start with will be out of fashion shortly after. React has had some staying power, though isn't without its flaws. I generally feel like most "web apps" could actually be websites though.
Another recent project I did in mostly pure Java, with only a third-party library for SMTP email sending, and a library for using HTML templates.
IDE is VSCode with clangd as linter, and gcc as compiler, and CMake as build system. For Java, I use the RedHat VSCode plugin.
Frontend in pure TypeScript, with an icon library.
Challenges I encountered: - Statically checking data structures between frontend and backend. This needs code generation. And there was a lot of code repetition for shared data structures between front- and backend. - More database abstraction would be good.
Other than that it all runs great.
It’s not the .NET Framework you might remember from the 2000’s.
I have experience with a pretty wide variety of development. I've worked with embedded microcontrollers (minimalistic RTOS), embedded applications (on top of a proper Linux), desktop applications in Java and in C#, some C++ work, gamedev and more. But to this day I haven't touched Web apps. I have not written a line of JS and the closest I've done to modern web is a tiny API in Go that sends a JSON response and renders a static HTML page.
With my total lack of Web experience (and self-confessed hate of webapps as a user), I have no opinions on React, Rails, Node.js, Vue and whatever people are naming here. But I'm taken aback at the variety - there's 20-odd replies all giving different answers.
Does Web development in 2023 not have 2-3 tech stacks that dominate? Are the existing frameworks/techs so lacking that new ones keep appearing to address those problems? Is there a high rate of change because things keep improving? If so, where is that improvement for me as a user, when webapps still feel inferior to late 90s native programs?
Every few years, a group thinks they're the ones with the one true ring, and try again.
Each new shiny seems to promote even poorer practices than the last, lowering both the bar and the barrier of entry further.
I realized that front end software is actually pretty shallow.
Design is important, deep, and requires talking to users, but once you have a design it is pretty straightforward to get the pixels into your favorite JavaScript/React/Vue/CSS/etc code base. Importantly, design is not about the code. Designers work in tools like Figma, not react.
Web frontend applications will then need to call into a backend. If you are doing anything computationally heavy or complex you are back in the world of normal software development.
I think this is why you see more full stack than frontend engineers.
If you are worried about it, I’d suggest trying a project. If it looks like crap, you probably need to get help from a designer or learn design, not figure out which web stack to use.
no
> Are the existing frameworks/techs so lacking that new ones keep appearing to address those problems?
The existing frameworks are fine. Most languages have just 1 or 2 frameworks for you to build in that language.
The problem child for all of this is the JavaScript ecosystem. A lot of developers in that space just keep proliferating a bunch of heavy-handed frameworks that do not accomplish anything new, but represent some opinionated take on architecture, tooling, etc., and which obfuscate everything behind layers of magic and indirection.
> Is there a high rate of change because things keep improving?
For the most part, I wouldn't say things are "improving" that much. I mean, React and Vue and Svelte are better for front-end development than what came before, for sure, but, speaking at least re: React, it's become a bit of a monstrosity. Pluses and minuses, I suppose.
Again, the problem is mostly in JS land. They are a little like the stereotype of Java devs, in some ways.
If developers could execute with confidence in the browser understanding the compile target, the DOM, we wouldn’t be in this mess. But, most developers are scared shitless of tree models and/or writing any form of original code. That is not a technology problem. It’s a people problem.
Those are things people do not need unless at an appropriate scale, or appropriate use-case, etc.
I'm surprised that Java and modern C++ are not more popular. I know for large web applications, Java is popular in "enterprise" environments.
Java scales both up (Spring Boot, with it's many integrations) and down (Dropwizard, a bunch of popular packages, nice for simpler projects) pretty well, has a great runtime and the language itself is okay.
Also there's .NET, where everything seems to revolve more around ASP.NET and EF, but as a consequence feels less fragmented than things on the Java side. Performance is also nice (especially on Linux with Kestrel) and the tooling is nice.
Honestly, both seem a viable option for something with more typing and language guarantees, as well as on average having a bit better performance than some of the highly dynamic languages (at the expense of iteration speed early on in development).
That said, Go is probably also worth a look, the deployment situation there is way simpler.
It's been a hot minute since I was looking for PHP developers, but when I did, I saw a ton of folks with Wordpress experience. And not many others who had experience with traditional three tier applications, how to write a database query, separation of concerns and general software development.
Maybe I was looking in the wrong places.
Do you find that software engineers who work in PHP are prevalent?
FreeBSD
Nginx
PostgreSQL
PHP/Python
Or, for something a bit less mainstream and only for certain types of application but more minimalist:
FNRL
FreeBSD
Nginx
Redis
Lua
Unfortunately these abstraction layers end up being just as, if not more complex than what it is building on top of.
People creating frameworks can work a lot faster than the browser development teams. The modern browser stack is actually getting pretty good, but still some things like creating web components are awkward compared to many of the popular frameworks. And when people find something awkward to do, especially in as flexible a setup as JS, they will make their own abstractions.
My suggestion for anyone feeling overwhelmed by the JS ecosystem is to just work with plain ol' vanilla JS for a while. It'll give you a much better understanding of what is actually going on and you'll likely realize the problems you're trying to solve are pretty straightforward. But you'll also see that things can end up quite verbose (though the comprehensibility will likely be quite high). You'll find that there are some areas that are kind of annoying and this is where when you go back to one of the frameworks you'll see its value (but also likely where it is totally overkill). At the end of the day if you can keep your mindset focused on the browser runtime rather than the specific framework you happen to be using, you'll have a much better time. At least that is my experience.
just give me a simple VPS
If I'm deploying an app to a K8s cluster, I assume I would still opt for an ingress rather than making my app handle that bit of functionality? Where's the cutoff here?
Also, how do I handle discovering what ASP.NET offers in terms of functionality? Is there an overview somewhere that I missed?
In this case, asp.net core has a built-in web server named Kestrel. IIS can be used as a reverse proxy so you can have IIS forward requests to web servers bound to local host.
Personally, I think its quite hilarious that you went straight to k8's. The vast majority of asp.net code is running on servers (bare metal or otherwise).
> Personally, I think its quite hilarious that you went straight to k8's.
I work in a production environment with some 1.5mil loc that runs in a k8s cluster, so that's what I know. I'm not sure which reverse proxy we use in our ingress. I'd have to check with devops.