The DX for deploying SQLite apps to Fly.io is rough. I'm a few hours into trying to get a production Rails app booting, but running into issues getting the database to initialize, migrate, and become writable. The root of my problem was the eager loading of a gem I wrote, but there were several layers of runners above it that made it hard to diagnose.
I wish they'd put a bit more effort into the DX here, but it probably doesn't make much sense from a biz PoV since big customers aren't going to be running these kinds workloads.
Curious if anybody here is deploying SQLite apps to production and what host they're using?
Every time I deploy something, it spins up 2 instances that are in some suspended state. I have to restart them like 3 times before they actually boot? And why can I never just pick one instance when launching an app.
Apps will randomly go into a suspended state, without explaining why. Contacting support says they ran out of capacity, but didn't automatically start them back when capacity was available?! That's the whole point of Apps (vs Machines), you keep my app running...
Fly is set up to be the best compute provider, but there are too many reliability and ergonomics issues.
Please stop updating flyctl every time i go to deploy an app
>The DX for deploying SQLite apps to Fly.io is rough. I'm a few hours into trying to get a production Rails app booting, but running into issues getting the database to initialize, migrate, and become writable. The root of my problem was the eager loading of a gem I wrote, but there were several layers of runners above it that made it hard to diagnose.
What's the Fly.io issue here? Aren't the issues you're describing in Rails not Fly.io?
I run several Go apps in production on Fly.io[0, 1, 2] and I've never had an issue with the Fly.io + SQLite part of it.
SQLite + Litestream makes things slightly more complicated, but again, I've never had issues with Fly.io specifically making that harder. I use a custom launch script in my Dockerfile that starts litestream with the -exec flag to start my app as a child process.[3]
I tried to go the litestream route on Fly.io, but there is too much that needs to be done to get it working. Specifically I was hoping scaling would be a lot easier, but master election kept breaking for me causing the whole app to not be able to come online. I just moved to Fly's managed postgres and called it a day.
Their managed postgres has gotten better, but its still a little sparse, so after about 6 months using it I am going to just take my DB to either Supabase or Planetscale.
Yeah, something that’s messed up that they don’t think is messed up is running `fly console` fires up another instance, which isn’t attached to the same volume, so you have to run `fly ssh console —pty`
It’s certainly not intuitive. It would be awesome if they sweat these details, but their deal is “here’s a bag of sharp knives”, which is good for some use cases.
I setup a fresh rails 8 app on Fly last year, using PG for the main data store but using SQLite for the ancillary solid stack dbs.
Only fuss I remember encountering was with fighting with rails migrating solid queue properly, but this seemed like a rails unit issue and don’t remember it being a Fly issue.
I’ve been contemplating migrating my pg primary to SQLite too. Anyways don’t have much else to offer other than an anecdote that I’m happily using fly with partial SQLite.
You don't have to drive it on I-94; in fact, for many years it was faster not to, because of insane bottom of the lake traffic. You can take the Dunes Highway instead (and then keep off 94 up the Michigan shore; there's good stuff up there).
I'm speaking up for Indiana here but honestly if you're looking for those dunescapes and beaches, western Michigan is the better bet. Road To Perdition was filmed around Saugatuck, just an hour into Michigan; that part of Michigan really is worth a trip to see (you'd want book a place to stay up by the lake for at least a couple days; it's not so much a sightseeing deal as a chill-out-by-the-lake deal).
The whole stretch though from Chicago up to Traverse City is basically where Chicago vacations.
Check out sleeping bear dunes park in Michigan especially if you can get out to the islands. Also Three Oaks Michigan is also a nice spot to stay and explore for a day or two. Journeyman distillery and a few nice restaurants are located there.
Honestly, I think it's a good thing it's insulated by a couple miles of hills and trees from I-94. The relentless noise of the highway would be absolutely terrible for the beach.
I actually stopped to stretch my legs and bag another national park at the Indiana Dunes National Park last Friday on my way back to Michigan from Wisconsin. Maybe AI was in a sour mood due to my poor decision to drive through Chicago from 3 to 6pm on a Friday, but I wasn't that impressed - Holland, Muskegon, Hoffmaster, Silver Lake, or Ludington State Parks up the Michigan coastline are all superior.
It only looks fantastic though a Chicagoan or Hoosier perspective because the rest of the area is a rust belt.
There's no part of Chicago that really looks all that impressive from any of our interstates. If you want to drive fast through Chicago and actually see it, you have to get yourself onto Lake Shore Drive.
There’s a lack of transparency playing out compounded by a poor job rolling out would should be the equivalent of boring corporate security bureaucracy.
Usually when this kind of stuff is rolled out, it’s agreed upon in some form and documented. Then when people are surprised, it’s a matter of pointing to the section in the doc that’s relevant and everybody goes on their way.
From the outside it appears this had none of that, so people are understandably surprised, sad, or angry. Since there’s a lack of transparency, people are filling in the blanks.
Ruby promised programmer happiness and delivered programmer warfare.
Predating the current hostile takeover: •••the vitriol directed at early critics like Zed Shaw •••mysterious departure of _why the lucky stiff •••the contentious Code of Conduct •••DHH •••uneasy truce after the toxic tribalism of the Rails vs. Merb
There's more, but the linked article can send you down more interesting rabbit holes than more bullets on my list
I wrote a book on Merb and was an active contributor. Before that I had developed several apps with Rails.
That said, the Rails vs Merb era was mostly good natured competition and I don't view the Rails vs Merb period as itself having been problematic.
Merb devs believed we could make app development both simple to start (as a single file like Sinatra) and easy to evolve (into a modular codebase with Rails-like conventions). Existing outside of the Rails ecosystem allowed Merb to pursue that distinct vision.
The Merge between Rails and Merb, accreted many of Merb's modular architectural enhancements to Rails, but sadly deprecated the overall Merb vision. To me that was a shame, but I still wouldn't describe any of it as toxic.
> I wrote a book on Merb and was an active contributor.
It might be a situation where you see it differently because you were involved or benefiting from the way things unfolded
> That said, the Rails vs Merb era was mostly good natured competition [...] wouldn't describe any of it as toxic
Competition can be healthy, Rails vs Merb was anything but. Quotes from Yehuda himself:
••• "I was just so blinded by tribalism that I never even bothered to check how fundamental the disagreements really were."
••• "waging an all-out war against Ruby on Rails from inside of a company that makes its money selling Ruby on Rails deployment is a pretty bad life strategy"
••• "It's so easy for our brains to turn disagreements about priorities into value conflicts. It takes a lot of effort to see past that mistake."
Engine Yard's management took several strategic missteps over the years. One of them was stifling Merb. The quotes from Yehuda describe his difficulty in making the best of a forced merger.
Ezra's vision for Merb and DHH's vision for Rails were distinct. Both warranted development. Over time, I assume they would have collectively strengthened the Ruby community. It was a mistake for Engine Yard's management to have instead framed it as zero sum and forced a merger.
There’s been a ton of that, yes, but for most people who are building applications and websites with Ruby, it’s been stable, productive, and prosperous.
No, I'm saying there's a lot of people who won't even know this happened. Fewer will know that it happened, but they'll view it as a scenario where the ends justify the means.
I'm on the record saying RC did a poor job rolling out these changes and treated the maintainers poorly.
There will be a lot of amazing Rubyists that leave, which is terrible, but it won't be "the shadow of a community left" because there's way too many people who depend on it to feed their families.
> No, I'm saying there's a lot of people who won't even know this happened.
In the world of "I'm sorry to that man" this seems like a given about literally everything.
Not knowing something happened is called being uninformed, and it doesn't change things or make the person right just because they don't know about something that occurred.
> There will be a lot of amazing Rubyists that leave
We agree. Listen, WebObjects still has a somewhat active community. Ruby's community won't be helped by recent events, but recent events happened because the Ruby community has been backstabby for a long time and no one has stopped it because there's too much money to be made in the meantime to care about things like people.
Ruby's status of having, like, two companies that are big and known to use Ruby (Shopify and 37Signals) is the reason why this was allowed to happen (three if you include Github, but my understanding is that its used less-and-less there). I have doubts that anyone could name another company or group most people have heard of using Ruby in any significant capacity. Its a dying language that does not have the legs to survive this drama.
Many if not all of these companies are, to my knowledge, companies like Github which might still have some legacy parts of their system running Ruby, but aren't building significant new code in Ruby; and if they do have Ruby, are trying to reduce its prevalence in their system.
Square was originally a single RoR monolith. We spent a decade burning it to the ground with a Java and Go microservice architecture.
Some product surface area remains Ruby, but Ruby was chased away by most teams.
Square brought in a lot of Xooglers over the years to lead the transition, so you see a lot of Google tech: protobufs, gRPCs, at one point a pre-Kubernetes Borg clone, etc.
Your claim would have more standing if 1) it made sense vs. the news and recent yearslong turn away from Ruby development, and 2) if you included any sources or information other than "nuh uh"
_why's departure had nothing to do with the Ruby community, as far as we know (unless some new info has come to light recently)
Zed Shaw, sure, but that's a single person (though a very vocal one; I always liked his work, but he was pretty outspoken and that got under people's skin)
DHH - yes, opinionated to a fault and outspoken like ZS, prone to create division, but that was always more about Rails than Ruby (this is not a comment on DHH recently, which I know nothing about; I stopped being active in Ruby/Rails community over a dozen years ago).
Rails vs Merb - again I think you're conflating the Rails community with the Ruby community
If you don't realize the overlap in the Rails and Ruby on Rails community, I'm not sure what corner of the Ruby world you've been hiding in.
Someone can shush away any behavior if they want, like you have done. Feel free to provide an alternate history or context for the current Ruby community upheaval if you want, but just dismissing the problems of the past doesn't help anyone.
I'm not dismissing the problems of the past. I just don't think they were as big problems as you make them out to be. It's not like I wasn't around or unaware, I just didn't let it bother me - and was happy with how things were developing despite some arguments around the fringes as in any community.
> I'm not sure what corner of the Ruby world you've been hiding in.
I did say that I haven't been involved for the past dozen years. Before that I was definitely there when Rails burst onto the Ruby scene and its early years. I realize the overlap but they were still pretty distinct -- though maybe that's changed in the past decade.
"it didn't affect me so I didn't care" is a common and valid feeling up until you are aware of what is happening
I developed with Ruby from the beginning and loved Ruby on Rails for many reasons. The community's backstabbing nature and callousness toward people who put a lot of work in was not something I ever admired and it's led us here.
You’ve made a lot of comments in this thread, and they come across far more subjective than objective. For people who have just been getting along and making things, they’re unlikely to be all that persuasive.
"Actually, the Ruby community ripped itself apart a decade ago and has never changed and still suffering from the consequences except with the recent thing with the founder" is not a strong argument
No, but listing things that happened over the course of over a decade, some of which are well resolved and others (like why’s leaving) are questionable how they’re an indication of drama.
He left public programming, including Scratch, entirely.
Ha yep. I remember a lot of this drama from my early days working with rails. But my impression is that none of this mattered and has long been water under the bridge. (I didn't know until reading about this current episode that there is new DHH drama.)
I was 3 miles from the epicenter. By far the strongest I’ve felt since I moved here 15 years ago. Hard to imagine what a 6+ would be like on the Hayward fault.
* Get appointed as paid managers of a non-profit
* Get advice from legal
* Legal suggests removing long-term maintainers without liability contract the same way people get fired: immediately and instantly, and screw the consequences. "Open-source? Never heard of it. Protect your entity legally"
* Instantly follow the advice of the lawyers to the letter.
Mozilla is toast. It basically exists as a tax writeoff for Google at this point, and serves no recognizable purpose beyond that, and maybe nostalgia.
How MBAs aren't synonymous with leeches by this point is the most amazing ongoing PR campaign in history. They do nothing but suck and suck and suck, and they keep sucking, and they will never stop sucking until their host dies, and then they just move on.
Oh wow. I'm absolutely alarmed after reading that. To be honest, I had been wondering if some of the PR disasters this year could be laid on Rhiannon's shoulders, but it sounds like the rot is coming from the top.
Yikes! At least they'll have someone "results-driven, client-focused," and "driving stakeholder engagement", because that's really what a software repository needs.
You have to be lucky to get a sunny day though. Of course it's Barcelona so that's pretty likely. But on a sunny day the colours are much deeper. The best lighting you get near the end of the day when the sun is low and shines the colours right across the whole church. It's an amazing kaleidoscope.
> The best lighting you get near the end of the day when the sun is low and shines the colours right across the whole church. It's an amazing kaleidoscope.
I wish they'd put a bit more effort into the DX here, but it probably doesn't make much sense from a biz PoV since big customers aren't going to be running these kinds workloads.
Curious if anybody here is deploying SQLite apps to production and what host they're using?
reply