It looks neat, but a demo blog would have been nice to see.
Looks a little bit like Svelte.
1. It is trivial to have a metric about how many requests were made for a link on a site, say a/
2. It is legally very much non-trivial to have a metric about how many requests were made to a/ followed by requests to b/
One way to solve 2. would be to change links based on earlier interaction server-side. So instead of [a/, b/], the requests would be [a/, a.b/] IMO, this should be legal, but might not under strict interpretation of the law.
User sessions were created with a URL query parameter, like `?sessionid=`, and every page would pick up the sessionid and include it in every link on the page.
Loading parent story...
Loading comment...
If you serve the U.S., then you need to calculate all the different sales taxes for each state. If you serve the E.U., you need to create PDF with included standardized XML soon. Don't know about other continents.
I think invoices are not about quick and pretty anymore, but there is a lot more to consider. You should make it clear what you provide and for which target customer.
Someone used my email address to sign up for a Mint account. And the only way you can delink Mint is to call Mint or log into someone else’s financial account. I’m no lawyer but that seems like a very, very bad idea to me.
Get some inexpensive bare metal servers and you maybe can save 80% cost.
If you do anything professional, you better choose proven software like kubernetes or managed kubernetes or whatever else all the hyperscalers provide.
And the complexity you are solving now or have to solve, k8s solved. IaC for example, Cloud Provider Support for provisioning a LB out of the box, cert-manager, all the helm charts for observability, logging, a ecosystem to fall back to (operators), ArgoCD <3, storage provisioning, proper high availability, kind for e2e testing on cicd, etc.
I'm also aways lost why people think k8s is so hard to operate. Just take a managed k8s. There are so many options out there and they are all compatible with the whole k8s ecosystem.
Look if you don't get kubernetes, its use casees, advantages etc. fine absolutly fine but your solution is not an alternative to k8s. Its another container orchestrator like nomad and k8s and co. with it own advantages and disadvantages.
I need to run on-prem, so managed k8s is not an option. Experts tells me I should have 2 FTE to run k8s, which I don't have. k8s has so many components, how should I debug that in case of issues without k8s experience? k8s APIs change continuously, how should I manage that without k8s experience?
It's not a k8s replacement. But I do see a sweet spot for such a solution. We still run Docker Swarm on 5 servers, no hyperscalers, no API changes expected ;-)