Live data from Hacker News

How I build software quickly

evanhahn.com

171–180 of 215 posts

Re: How I build software quickly

#171

Earlier quoted context omitted.

Ya this kind of usecase is for sure straying into the "this is more of a pain than its worth" with regards to k8s. Esp when you can just do basic nfs mounts in nix anyways. If you are already familiar with k8s volumes and csi's its not a huge problem but if you arent its not worth learning if your goal is simple. At least in my opinion.

Thank you for taking the time to confirm this. Yeah, that is also my opinion after that experience. Also, it was really frustrating as the number of moving parts that have to play nice to each other is high.

K8s and its derivatives ultimately were designed to declaratively orchestrate stateless apis/middlewares. It of course can quite competently do many other things. But it does what it was BUILT to do originally the best and the simplest.

Many hobby projects are just that, simple apis and can benefit from the simple declarative yamls that exist in say a sqlite db on the vm vs random config in /etc, /var and ip table scripts etc.

But trying to do anything out of that simple mold? just do it the simpler and easier traditional way.

Re: How I build software quickly

#172
post #145
post #137

Earlier quoted context omitted.

You mention Django, but these days, are you using the full Django experience or are you mostly writing REST APIs? In Java land a very nice and much lighter weight framework is Dropwizard: https://github.com/dropwizard/dropwizard It's basically a sort of All-Stars collection of Java libraries, nicely packaged and with some nice conventions. Towards the more servless route route there's Micronaut: https://micronaut.io/

I haven't tried Dropwizard. Is it a batteries included as Spring Boot? Eg: How is authentication support? Do we need a lot of boilerplate to implement let's say an OAuth2 resource server?

I used it a long time ago. As far as I know, it's an abandoned project now, very few people use it in the Java community. Go for one of the more popular ones: Spring, Micronaut, Helidon or Quarkus.

Re: How I build software quickly

#173
post #88

Earlier quoted context omitted.

> Forget Celery How do you do background job processing without Celery? Every app/website I ever developed required some sort of background job processing, for Python I use Celery, Rails I use Sidekiq, Node.js I use Faktory. One of the biggest drawbacks (at least until a while ago) was that setting this up had to be a hacky webhook call to your own app that allowed up to N seconds request/response.

You write the demand to the database, and have a worker process execute it. Exactly like you'd do with celery. Celery is a solution to scalability, not to any business problem in particular.

Years ago I ditched Celery in favour of using BLPOP with redis. It was multiple times faster than Celery. Is this still the case today? So with vanilla Redis you need less workers for same throughput; if you need more throughput, spawn multiple workers.

Re: How I build software quickly

#174

Earlier quoted context omitted.

K8s is chock full of complexity though. Complexity that the vast majority of applications do not, and will not need

I only used it once forever ago, and all I remember is being very confused about pod vs service and using a lot of magic strings to get load-balancing to work. Sure I could figure it out, but didn't want to.

Kubernetes is really complex but I'm surprised by this - for a simple setup, I think those 2 resources are not that difficult.

I'd describe a really simple setup as this:

Pod: you put 1 container inside 1 pod - you can basically replace the word "container" with "pod". Let's say you have 1 backend in python and 1 frontend in React: you deploy 1 pod for your backend, and 1 pod for your frontend. The simplest way to deploy pods is not with "Pod" but with "Deployment" (1).

Service: Kubernetes really doesn't want you to connect directly to pods, it wants you to have a service in between. This is sensible because pods are ephemeral - they can be killed due to crashes, updates, etc. You define a service, point towards the pod, and all internal requests should be sent to the service, not to the pod. (2)

(1) https://kubernetes.io/docs/concepts/workloads/controllers/de...

(2) https://kubernetes.io/docs/concepts/services-networking/serv...

Note: technically, a pod is a group of containers. It can get more complex than this, but it's not unusual to have a group of 1 pod, especially in simpler setups.

Re: How I build software quickly

#175
Functions and immutable data.

Yessir, that is the way to speed. You're composing and climbing to higher levels of abstraction while the competition is trying to synchronize their accidental state machine network.

Re: How I build software quickly

#176
post #174

Earlier quoted context omitted.

I only used it once forever ago, and all I remember is being very confused about pod vs service and using a lot of magic strings to get load-balancing to work. Sure I could figure it out, but didn't want to.

Kubernetes is really complex but I'm surprised by this - for a simple setup, I think those 2 resources are not that difficult. I'd describe a really simple setup as this: Pod: you put 1 container inside 1 pod - you can basically replace the word "container" with "pod". Let's say you have 1 backend in python and 1 frontend in React: you deploy 1 pod for your backend, and 1 pod for your frontend. The simplest way to de…

The thing about managing pods using deployments rings a bell, but most official Kubernetes tutorials/examples (at least back then) were declaring "kind: Pod" directly which gave mixed signals, maybe because deployment was a newer feature. Per the service doc you linked, services connect directly to pods rather than deployments, using a seemingly magic "kubernetes.io/service-name" label.

In the deployments example, what gets me is they called 4 different things "nginx." It's hard to tell what does what. Like I've read 6 times what matchLabels does, and it's still not clear if that's supposed to mirror template.metadata.labels.app, or what happens if it doesn't. Sure I'd figure it out if I set up the real thing and messed with the config to see what it does, but it shouldn't take that.

Of course it's easy to follow tutorials without fully understanding how stuff works, and I did. Slightly more advanced things were a lot of trial and error. At some point I lost interest because I didn't really need this.

Re: How I build software quickly

#177

Earlier quoted context omitted.

Whats so hard about writing an SQL query and some json struct tags? I really dont like LLMs but all the pain points of Go you described above are relatively mute now if you use them for these little things

There's nothing hard about it, it's just that the sum total of code you need to write is much larger, and that takes more time.

edit, my karma for this comment has been dealing with type assertion problems in my repo functions all day.

Re: How I build software quickly

#178
I write (mostly) bug free production code fast by doing the following:

1. I use a custom code generator to generate 90%+ of the code I need from a declarative spec.

2. The remaining hand written code is mostly biz logic and it is exhaustively auto tested at the server API level.

3. I maintain and "bring along" a large library of software tools "tested in combat" I can reuse on new projects.

4. I have settled on an architecture that is simple but works and scales well for the small to large biz applications I work on.

5. I constantly work on removing complexity from the code, making it as easy to understand and modify as possible.

Re: How I build software quickly

#179

Earlier quoted context omitted.

There's nothing hard about it, it's just that the sum total of code you need to write is much larger, and that takes more time.

edit, my karma for this comment has been dealing with type assertion problems in my repo functions all day.

Haha :D

Re: How I build software quickly

#180
post #57

Earlier quoted context omitted.

This is the point at which u scale down. Nobody needs these huge systems but everyone for some reason wants them...

In that case your system is a legitimate candidate for Micro Services. Services that can each be maintained by a small team, with a clean, understandable API, appropriate protections for data (both security and consistency) and easily predictable cost and behavior. Then you can compose these services to get more complex functionality.

Yea I know microservices, depending on how you do it this comes with a ton of extra complexity. There are microservice architectures out there where each microservice seems to have a different tech stack, so now you have to hire all kinds of talent. Can work out well too, I believe just doing it in Elixir would save one a lot of headaches
Post reply on HN