401–410 of 569 posts
Earlier quoted context omitted.
With a single VPS, you're missing the DB backup that is probably the most important piece if the puzzle provided by heroku.
Depends on the DB size. For small side projects I do weekly SQL dumps, 7-zip them, and email as attachments to my GMail, where they get automatically tagged and marked as read.
Heroku has given us a ton of flexibility, and with that we’ve been able to become very opinionated and standardize on one stack. 12 factor design patterns (and the opinions of Django-cookiecutter) allowed us to stop arguing about how to do something and just get it done.
We use GitHub for source control and Heroku Pipelines for CI and testing. Every push runs functional tests, every PR spins up a “review app” with full dependencies and test data.
Heroku Postgres is our system of record database. Postgres is stable, fast, and full featured. With jsonb fields we’re able to store complex structured build log data and quickly aggregate on it. Heroku Data Clips are super useful for quick reviews of the data without building a report into an app.
Heroku Redis and S3 are the only other data stores. S3 stores build results and end user assets, and Redis handles anything in memory. We use Brandur’s transactionally drained job queue pattern (https://brandur.org/job-drain) to defer tasks.
The apps currently all render to plain ol HTML and for the most part take a document centric approach to front end. Additionally, our apps are all API first and we use CoreAPI to create CLI clients automatically. Those are usually our administration tools which help make sure we are API complete.
Earlier quoted context omitted.
With a single VPS, you're missing the DB backup that is probably the most important piece if the puzzle provided by heroku.
Depends on the DB size. For small side projects I do weekly SQL dumps, 7-zip them, and email as attachments to my GMail, where they get automatically tagged and marked as read.
For some reason people seem to constant doubt Ruby-ists and Rails Devs. I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood. But if youre talking about getting a functioning webapp up and running quickly ... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and…
I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost always outweighs any costs from it being slow. You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later. I’ve worked on all sorts of applications from corporate CRUD to mobile billing…
Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.
I write the server-side in Go, cross-compile to a Linux binary, and set that up as a service on a vanilla Ubuntu box (usually Digital Ocean). Deploying a new version is a matter of sftp'ing the new binary (and any templates, images, etc) over the top of the old one and restarting the service. If I need a database then I use Postgres, and the setup for that can be a pain, so I get it documented/scripted using Ansible.…
Your start is good but you add complexity on top of it. Install Golang on your VPS, clone the source code on it and compile it there instead of messing with cross compilation. Also use sqlite to avoid the pain of setting up a SQL server, there is no need for it. You can then easily get systemd to supervise your binary. This is how I host all my web apps, the main difference is that I don't use Go but Nim. If you want…
Earlier quoted context omitted.
>No cutting edge incomplete frameworks So what, you rewrite a templating engine every time you want to make an application that outputs user data? Or are you reliant on making damn sure you always call htmlentities every time you echo something to prevent XSS? Are you sure you've not slipped up anywhere? What about CSRF? Do you write your own filtering mechanism every time you make a web app to check for the existenc…
>>There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck. It’s totally OK for a prototype to be a trainwreck because its purpose is to give you the ability to launch it in front of potential users, show them a few features and get their feedback.
Earlier quoted context omitted.
With a single VPS, you're missing the DB backup that is probably the most important piece if the puzzle provided by heroku.
Depends on the DB size. For small side projects I do weekly SQL dumps, 7-zip them, and email as attachments to my GMail, where they get automatically tagged and marked as read.
Earlier quoted context omitted.
"Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better). One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done. That's not to say Rai…
Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases. Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
Earlier quoted context omitted.
If backend speed/scale is your concern I'd also throw a vote in for Phoenix. Lots of similar heritage to Rails but built on Elixir/Erlang instead.
Phoenix loses my vote for being quick to set up for a web application, because last time I used it, it didn't have a good authentication framework that worked with JSON APIs. What took ten minutes to set up using Devise in Rails took me two days using Coherence in Phoenix. Unless that's changed since I last tried Phoenix, I'd be hesitant to use it in the same niche as Rails.
For some reason people seem to constant doubt Ruby-ists and Rails Devs. I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood. But if youre talking about getting a functioning webapp up and running quickly ... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and…
Well, here's one reason: the amount of time saved when standing up a webapp on Rails is absolutely insignificant compared to the life of that webapp in all situations where that webapp is anything serious. Not to say that Rails apps aren't serious! I'm just saying that the time saved in standing up a webapp with Rails vs., say, Java, is miniscule compared to the develooment life of that application, overall. In short…
I'd describe my professional experience with Rails as: Rails optimizes for Day 1. Devise is a great example.
But I left Rails when I couldn't help but notice that it tends to break down over time without eternal vigilance. And even simple tasks required me to hold quite a bit of Rails trivia in my head.
These days I'm far less likely to give up simplicity so easily.