back in my day kid we used to serve far more users from 40mhz CPUs. The only interesting part is that today you can get pipes fast enough to do this in your house, while back then dialup was all we could afford ($1000/month to get into the 1 megabit/second range, ISDN and DSL came soon after and were nice).
Of course back then we didn't use dynamic anything, a static web page worked.
I like that you're pointing out application longevity in the linked article. It seems that new SaaS apps appear and disappear daily as cloud hosting isn't cheap (especially for indie hackers). I'd much rather sign up for an app that I knew wouldn't randomly disappear in a couple of months when the cloud bills surpass the profits.
That's amazing. Mac Mini is very efficient and is a great little home server. Idles at 3-4w total for the entire machine. Plus, the M4 is a beast of a CPU. It might even be possible to serve a small LLM model like a 3b model on it over the internet.
I've been thinking about that article for the past week so much that I've been looking at $250 Ryzen 7 5700U 16/512/2.5G Ace Magician NUCs to move some of my properties to. They're known to be shipping spyware on their Windows machines, but my thought was that I'd get 3 of them, clear them out with Debian, and set them up as a k8s cluster and have enough horsepower to handle postgres at scale.
It's fun to host at home, I run docker on alpine VMs on two proxmox machines. Yeah, different docker machines for each user or use-case look complicated but it works fine and I can mount nfs or samba mounts as needed. Only thing I have on the cloud is a small hetzner server which I mostly use as a nginx proxy and iptables is great for that minecraft VM.
Why did you go for Cloudfare tunnel instead of wireguard?
I've tried to do so with a $9 pocket pc, but ended up frying it by accidently short-circuiting it.
I wrote a visualizer for the traffic that I think people will appreciate [1]. I will post it next month once I add it on github. It was fun to watch an article that went #1 on HN.
Is cloudflare tunnels really this free to support thousands of internet requests?
I run a windows server at my office where we connect to it using RDP from multiple locations. If I could instead buy the hardware and use cloudflare tunnels to let my team RDP to it then it would save me a lot of money. I could recoup my hardware cost in less than a year. Would this be possible?
(I wouldn't mind paying for cloudflare tunnels / zero trust. It just should be much smaller than the monthly payment I make to Microsoft)
I see you're serving a GTS certificate. Does GCP allow you to download TLS certificates? I honestly didn't know. I thought just like AWS, you get them only when using their services like load balancers, app runners etc.
Pretty cool. Wouldn't work for me as my ISP is horrendously unreliable (Rogers in Canada, I swear they bounce their network nightly), but I might consider colocating a mac mini at a datacenter.
What kind of Mac mini do you use (cpu and ram)? I’m really interested in making the same thing but I’m not sure if the base M4 mini is enough with just 16gb of ram.
Hosting from home is fun, I guess, but it actually was a money-saving exercise before the cloud. I've done it.
Now, however, what is the point? To learn server config? I am running my blog with GitHub pages. A couple of posts made it to the top of HN, and I never had to worry.
Always bewilders me when some sites here go down under load. I mean, where are they hosting it that a static page in 2020s has performance issues?
I really like web apps that are just CRUD forms. It obviously doesn't work for everything, but the "list of X -> form -> updated list of X" user experience works really well for a lot of problem domains, especially ones that interact with the real world. It lets you name your concepts, and gives everything a really sensible place to change it. "Do I have an appointment, let me check the list of appointments".
Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one.
So even though you can build in any style with whatever technology you want:
Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific screen"
The problem with 1 model = 1 rest entity (in my experience) is that designers and users of the applications I have been building for years never want just one model on the screen.
Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly.
If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing.
I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).
> I really like web apps that are just CRUD forms.
I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.
Rails is set up for that, but it doesn't force you to build like that. You're free to build in other patterns that you design yourself. It's nice to have simple defaults with the freedom to opt into more complexity only if and when you need it.
Why is the ruby/rails community so weird. Half of us just quietly make stuff, but the other half seems to need to sporadically reassure everyone that it's not dead, actually.
> Rails has started to show its age amid with the current wave of AI-powered applications.
> Rails has started to show its age amid with the current wave of AI-powered applications. It struggles with LLM text streaming, parallel processing in Ruby
Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).
We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.
> Rails has started to show its age amid with the current wave of AI-powered applications. It struggles with LLM text streaming, parallel processing in Ruby, and lacks strong typing for AI coding tools. Despite these constraints, it remains effective.
A plug for Django + gevent in this context! You have the Python type system, and while it's inferior to TypeScript's in many ways, it's far more ubiquitous than Ruby's Sorbet. For streaming and any kind of IO-bound parallelism, gevent's monkey-patches cause every blocking operation to become a event-loop yield... so you can stream many concurrent responses at a time, with a simple generator. CPU-bound parallelism doesn't have a great story here, but that's less relevant for web applications - and if you're simultaneously iterating on ML models and a web backend, they'd likely run on separate machines anyways, and you can write both in Python without context-switching as a developer.
RoR is a beast, it has its place. The issue we have today is that everything is to fast paced, so fast that people feel the need to follow the latest and greatest, or they will be left behind.
This has (in my opinion) lead to a false sense that if something is not hyped as often, then its not used either.
I've heard this criticism a few times – the fear that LLMs will be bad at Rails because there's no types – and I don't think it's accurate.
At least in my experience (using the Windsurf IDE with Claude 3.5 Sonnet) LLMs do a very good job in a Rails codebase for stuff like "I want to create a new page for listing Widgets, and a Create page for those Widgets. And then add pagination.". I've been able to spin up whole new entities with a model/view/controller and database migration and tests, styled with tailwind.
I think the reason strong types don't matter as much as we might assume is because Rails has very strong conventions. Routing lives in routes.rb, controllers go under app/controllers, most controllers or models will look very similar to other ones, etc.
Type information is something that has to be presented to the LLM at runtime for it to be accurate, but convention-over-configuration is stuff that it will have picked up in training data across thousands of Rails apps that look very similar.
On top of that, the core Rails stuff hasn't drastically changed over time, so there's lots of still-accurate StackOverflow questions to train on. (as opposed to something like Next.js which had a huge upheaval over app router vs pages router, and the confusion that would cause in training data).
In my opinion the future of LLM-aided Rails development seems pretty bright.
I am using Django and I do understand the sentiment.
But everything old is new again.
Today there is better tooling than ever for these tools. I am using Django with htmx + alpine.js and sending HTML instead of JSON. Breaking free from JSON REST APIs is a huge productivity boost.
I worked at a company that, when faced with the choice between rewriting its Django apps in Python 3, and rewriting them in RoR, decided to go with the latter.
Now, I didn't like that since I was on an undermanned team that had literally just started a major update of a Django site, and it arguably wasn't the right way to go business-wise, but a lot of ideas that have come into Django over the years were ideas that existed in RoR.
I'd like to see that sort of innovation happen in some of the other spaces that Python is in, if for no other reason than to prevent monoculture in those areas. There needs to be offerings for Ruby in other areas, like scientific computing, machine learning/AI, and data analysis that get the same uptake that Rails does.
It’s interesting to see how convention over configuration had its hay-day in the 2010s. Angular, EmberJS, Django, and Rails were very, very popular. Now, the new type of modern stack, e.g. React/NextJS with bespoke backends consisting of things like NodeJS spaghetti with express seem to have a lot of traction.
I base the above assertion mainly on looking at Who’s Hiring posts btw.
sidenote - is NextJS really the best “convention over configuration” approach for react? I’d love to just use ember, but most of the community has moved to react, but I really enjoy the opinionated approach
In an era of microservices-and-k8s-all-the-things, Rails monoliths are a breath of fresh air. For stuff that's really performance- or latency-sensitive, tacking on a satellite service in Go or Rust works great.
I haven't actually used RoR, but I've used Django extensively and understand they are fairly similar. How do people build things that aren't just CRUD? Django calls itself a "web framework" but I think that's wrong, it's a CRUD app framework. Is RoR the same?
The main problem I have is the mixing up of low-level logic like web and database etc with high-level logic (ie. business rules). The easy path leads to a ball of mud with duplicated business rules across views and forms etc. How are people dealing with this? Does RoR fit into a larger application architecture where it does just the CRUD part and some other systems take over to do the business part?
It always seems to start well, you have your models, and views just doing CRUD stuff. But then someone says "I don't want to have to create an author before I create a book, let me enter new author details when I enter a book", and then the whole thing breaks. You need some logic somewhere to create authors but only in certain cases and of course the whole thing needs to be one transaction etc. Then you end up basically undoing all the simple views you did and essentially fighting the system to handle logic it was never designed to handle.
In essence, these systems make the easy stuff easy and the hard stuff even harder.
This is an unfortunate comparison. I actually chose Next.js because of its similarity to Rails - it's a batteries included, opinionated framework that favors convention over configuration (though it's not sold that way since these are not the currently trending buzzwords). There's absolutely nothing preventing you from using both tools. Rails works great as an API supporting a Next.js UI.
it’s been quite a few years since I’ve worked in Rails, but I miss it sometimes. None of the other platforms ever completely replicated the functionality of a standard Rails environment circa 2009, so we reinvent the wheel every time. Basic stuff, too: ORM hooks, validations. It’s always a relief when I get to work with someone who has also worked on Rails before, because it means we have a shared vocabulary - there’s no equivalent thing among Python programmers, or JVM programmers, or anywhere else that I’m aware of
Just because of job availability, I've been a JS (Node, React, Next, etc.) dev for almost a decade now. I still feel much more productive with Rails.
Rails isn't the right tool for every job, but I find that it's the right tool more often than not.
Rails is architected really well. Many decisions don't need to be made at all, and everything has a place. Plus, it's very friendly to extensibility and has a healthy ecosystem. It's mostly about the code that I don't need to write. It's really years beyond most other frameworks. Next will get there, but it will take it another 5 years. No shade on others, but Rails is just well built software with many years of learning and improving.
For highly reactive or "dynamic" systems, it probably isn't the right tool. Building a Figma or Notion. As @graypegg said in their comment, most websites work best as "CRUD forms". Though I would have said the same about email, but Hey.com exists so YMMV...
After all these years, rails is still my favorite framework to build with. Although I have become increasingly bored/frustrated with the front-end development in rails, which lacks a solid rails-way.
To go in the other direction, static site generators (SSGs) also have a place on the menu. Build locally. Host them on your favorite CDN. I personally really like Zola (Rust), inspired by Hugo (Go).
[+] [-] philip1209|1 year ago|reply
https://www.contraption.co/a-mini-data-center/
(The CPU load from this is pretty negligible).
[+] [-] asdfman123|1 year ago|reply
[+] [-] bluGill|1 year ago|reply
Of course back then we didn't use dynamic anything, a static web page worked.
Now get off my lawn!
[+] [-] trinix912|1 year ago|reply
[+] [-] aurareturn|1 year ago|reply
[+] [-] bmelton|1 year ago|reply
[+] [-] tempest_|1 year ago|reply
[+] [-] TomK32|1 year ago|reply
Why did you go for Cloudfare tunnel instead of wireguard?
[+] [-] firefoxd|1 year ago|reply
I wrote a visualizer for the traffic that I think people will appreciate [1]. I will post it next month once I add it on github. It was fun to watch an article that went #1 on HN.
[1]: https://ibb.co/cXT3VNDR
[+] [-] adamtaylor_13|1 year ago|reply
Render is crazy expensive for blog sites and hobby apps.
[+] [-] jonwinstanley|1 year ago|reply
https://vincentwoo.com/3d/sutro_tower/
[+] [-] your_challenger|1 year ago|reply
I run a windows server at my office where we connect to it using RDP from multiple locations. If I could instead buy the hardware and use cloudflare tunnels to let my team RDP to it then it would save me a lot of money. I could recoup my hardware cost in less than a year. Would this be possible?
(I wouldn't mind paying for cloudflare tunnels / zero trust. It just should be much smaller than the monthly payment I make to Microsoft)
[+] [-] peterhunt|1 year ago|reply
[+] [-] AlchemistCamp|1 year ago|reply
I’ve had a number of database-driven sites hosted on $5/month VPS that have been on the front page here with minimal cpu or memory load.
[+] [-] mattgreenrocks|1 year ago|reply
[+] [-] psnehanshu|1 year ago|reply
[+] [-] rapind|1 year ago|reply
[+] [-] raitom|1 year ago|reply
[+] [-] boogieup|1 year ago|reply
[+] [-] dakiol|1 year ago|reply
[+] [-] cl0ckt0wer|1 year ago|reply
[+] [-] _vaporwave_|1 year ago|reply
[+] [-] renegade-otter|1 year ago|reply
Now, however, what is the point? To learn server config? I am running my blog with GitHub pages. A couple of posts made it to the top of HN, and I never had to worry.
Always bewilders me when some sites here go down under load. I mean, where are they hosting it that a static page in 2020s has performance issues?
[+] [-] fsndz|1 year ago|reply
[+] [-] k4runa|1 year ago|reply
[+] [-] graypegg|1 year ago|reply
Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one.
So even though you can build in any style with whatever technology you want:
Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific screen"
[+] [-] zdragnar|1 year ago|reply
Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly.
If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing.
I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).
[+] [-] globular-toast|1 year ago|reply
I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.
[+] [-] adsteel_|1 year ago|reply
[+] [-] andrei_says_|1 year ago|reply
[+] [-] philip1209|1 year ago|reply
Too many degrees of freedom can degrade an experience, if not used properly.
[+] [-] Sincere6066|1 year ago|reply
> Rails has started to show its age amid with the current wave of AI-powered applications.
Not everything needs to have bloody AI.
[+] [-] mbell|1 year ago|reply
Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).
We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.
[+] [-] btown|1 year ago|reply
A plug for Django + gevent in this context! You have the Python type system, and while it's inferior to TypeScript's in many ways, it's far more ubiquitous than Ruby's Sorbet. For streaming and any kind of IO-bound parallelism, gevent's monkey-patches cause every blocking operation to become a event-loop yield... so you can stream many concurrent responses at a time, with a simple generator. CPU-bound parallelism doesn't have a great story here, but that's less relevant for web applications - and if you're simultaneously iterating on ML models and a web backend, they'd likely run on separate machines anyways, and you can write both in Python without context-switching as a developer.
[+] [-] Alifatisk|1 year ago|reply
This has (in my opinion) lead to a false sense that if something is not hyped as often, then its not used either.
[+] [-] teleforce|1 year ago|reply
Go and Rust are amazing languages, but why can’t they produce a Rails-like framework?
Is it just a matter of time before Go/Rust create a Rails-like framework, or is something fundamental preventing it?
Perhaps this article by Patrick Li (author of Stanza language) has the answers [1].
[1] Stop Designing Languages. Write Libraries Instead:
https://lbstanza.org/purpose_of_programming_languages.html
[+] [-] dceddia|1 year ago|reply
I've heard this criticism a few times – the fear that LLMs will be bad at Rails because there's no types – and I don't think it's accurate.
At least in my experience (using the Windsurf IDE with Claude 3.5 Sonnet) LLMs do a very good job in a Rails codebase for stuff like "I want to create a new page for listing Widgets, and a Create page for those Widgets. And then add pagination.". I've been able to spin up whole new entities with a model/view/controller and database migration and tests, styled with tailwind.
I think the reason strong types don't matter as much as we might assume is because Rails has very strong conventions. Routing lives in routes.rb, controllers go under app/controllers, most controllers or models will look very similar to other ones, etc.
Type information is something that has to be presented to the LLM at runtime for it to be accurate, but convention-over-configuration is stuff that it will have picked up in training data across thousands of Rails apps that look very similar.
On top of that, the core Rails stuff hasn't drastically changed over time, so there's lots of still-accurate StackOverflow questions to train on. (as opposed to something like Next.js which had a huge upheaval over app router vs pages router, and the confusion that would cause in training data).
In my opinion the future of LLM-aided Rails development seems pretty bright.
[+] [-] gatinsama|1 year ago|reply
But everything old is new again.
Today there is better tooling than ever for these tools. I am using Django with htmx + alpine.js and sending HTML instead of JSON. Breaking free from JSON REST APIs is a huge productivity boost.
[+] [-] lenerdenator|1 year ago|reply
I worked at a company that, when faced with the choice between rewriting its Django apps in Python 3, and rewriting them in RoR, decided to go with the latter.
Now, I didn't like that since I was on an undermanned team that had literally just started a major update of a Django site, and it arguably wasn't the right way to go business-wise, but a lot of ideas that have come into Django over the years were ideas that existed in RoR.
I'd like to see that sort of innovation happen in some of the other spaces that Python is in, if for no other reason than to prevent monoculture in those areas. There needs to be offerings for Ruby in other areas, like scientific computing, machine learning/AI, and data analysis that get the same uptake that Rails does.
[+] [-] amazingamazing|1 year ago|reply
I base the above assertion mainly on looking at Who’s Hiring posts btw.
sidenote - is NextJS really the best “convention over configuration” approach for react? I’d love to just use ember, but most of the community has moved to react, but I really enjoy the opinionated approach
[+] [-] Axsuul|1 year ago|reply
https://github.com/inertiajs/inertia-rails
[+] [-] cjk|1 year ago|reply
[+] [-] globular-toast|1 year ago|reply
The main problem I have is the mixing up of low-level logic like web and database etc with high-level logic (ie. business rules). The easy path leads to a ball of mud with duplicated business rules across views and forms etc. How are people dealing with this? Does RoR fit into a larger application architecture where it does just the CRUD part and some other systems take over to do the business part?
It always seems to start well, you have your models, and views just doing CRUD stuff. But then someone says "I don't want to have to create an author before I create a book, let me enter new author details when I enter a book", and then the whole thing breaks. You need some logic somewhere to create authors but only in certain cases and of course the whole thing needs to be one transaction etc. Then you end up basically undoing all the simple views you did and essentially fighting the system to handle logic it was never designed to handle.
In essence, these systems make the easy stuff easy and the hard stuff even harder.
[+] [-] luketheobscure|1 year ago|reply
[+] [-] jes5199|1 year ago|reply
[+] [-] hrdwdmrbl|1 year ago|reply
Rails isn't the right tool for every job, but I find that it's the right tool more often than not.
Rails is architected really well. Many decisions don't need to be made at all, and everything has a place. Plus, it's very friendly to extensibility and has a healthy ecosystem. It's mostly about the code that I don't need to write. It's really years beyond most other frameworks. Next will get there, but it will take it another 5 years. No shade on others, but Rails is just well built software with many years of learning and improving.
For highly reactive or "dynamic" systems, it probably isn't the right tool. Building a Figma or Notion. As @graypegg said in their comment, most websites work best as "CRUD forms". Though I would have said the same about email, but Hey.com exists so YMMV...
[+] [-] mostlysimilar|1 year ago|reply
A feature, not a bug. Rails will continue to be good for building things long after the AI boom has died down.
[+] [-] usernamed7|1 year ago|reply
[+] [-] xpe|1 year ago|reply
[+] [-] hombre_fatal|1 year ago|reply