Production ready?

[schonert]

What an absolute banger project! This approach just makes sooo much sense and the way you've managed to butter everything into existing tooling is just amazing.

You seem to be the primary driver for this, which is quite impressive. I'm curious, however, to how stable and robust the whole thing is in a real world running production apps.

Not much information or references on this. You mentioned it started out for your self - however, this seems quite solid.

Would you say this production ready?

[trevorturk]

I'd say Falcon is in the early adopter phase, but I'm using it in production quite happily along with many others. You should peruse the discussions to see if there might be any gotchas for your use case (#186 for example) -- likely this issue should be converted to a discussion as well, but please feel free to post additional/specific questions as you consider Falcon for your project!

[ioquatix]

I think falcon is close to being production ready. As @trevorturk helpfully pointed out, there are still a few areas that need polish.

As for falcon itself, I'm currently doing a rewrite of the command line and configuration systems. This has been on the cards for a long time, and once it's done, I think we'll be close to a 1.0 release. I would say, once we have a 1.0 release, that would be a strong indicator that we are production ready in general. All things considered, it will be some time this year but I don't have a firm feeling as for when, sooner rather than later I suppose would be great.

Some parts, like complete support in Rails, is outside of my control, but looks to be progressing well. As far as I know, there will be a Rails 7.2 release which continues to improve the fiber-per-request model. While Rails 7.1 was the first release to technically support fiber-per-request, some parts of Rails need additional work to make them "great".

• PoC: Add an option to disable connection checkout caching rails/rails#50793
• Action Cable server adapterization rails/rails#50979

Supporting the above pull requests with feedback and reviews would probably help.

[schonert]

@trevorturk @ioquatix Thanks for getting back to me! This is quite useful - and it appears to be more robust then I first anticipated.

I'm not used to being deep in the engine room of web servers so for me there are quite a few moving parts. It also seems like there might be some edgecases hiding the corners.

So altho the two of you are confident in your setup - I'm personally still a bit hesitant. I'm afraid small edge cases will take me exceptionally long time to figure out and it in the long run will slow down our momentum.

Currently this project feels like a powerful toolbox for experienced craftsmen.

For general builders, like myself, more documentation and insights into configuration will help make it less intimidating. An example would be that I tried following the rails and the deployment guides - however there is no clear guidance on how to best migrate from my Puma configuration to a solid Falcon configuration. So I never felt confident in what was going on. I felt like I was not handling CORS properly or I'd run into session errors down the road. It also took a while to understand why it was forcing me to use https locally, how to work around that so I could test it and once it finally was running I noticed the port was not respecting the PORT environment - which again make me feel uncertain about how things were configured.

These are all small things - but for me they added up.

I'm purely a passenger looking for a free ride - so this is not critique at all, just sharing my journey.

I would love to help make the wheels turn and to see this production ready sooner then later. Please let me know if there are any low hanging fruits I can contribute with. Hoping to be able to add some steps to the documentation once we've got our newest product out of beta.

[ioquatix]

I think trying things out and seeing how it works and giving feedback can be extremely useful.

Regarding documentation, that's all extremely useful feedback and I think we can improve the documentation in that regard. If you have time to make PRs to improve the documentation based on your experience, that's also useful.

[trevorturk]

Some hints about Rails configuration and Heroku compatibility are here as well, but agreed we can improve the READMEs more to start and eventually have guides.

socketry/falcon-rails-examples#1

Of course documentation improvements or just issues/discussions about specific things you run into are always helpful!

FWIW I'm in the same boat w/r/t being an early adopter but mainly wanting to build apps as opposed to building open source libraries, but I think people like us are still really valuable toward these efforts if we contribute where we can!

[travisbell]

FWIW, we've been using Falcon on a medium/large scale production service (~10,000 rps) for around 3 months now and haven't had any issues. Mind you this isn't a Rails app, so naturally YMMV. But Falcon is solid.

We took some time to async-ify what we could like our Redis and external HTTP calls which helped out a lot.

With regards to config, it's pretty straight forward:

bundle exec falcon-host config/falcon/production.rb

require "falcon/environment/rack"

service "web.localhost" do
  include Falcon::Environment::Rack

  count ENV.fetch("WEB_CONCURRENCY", 1).to_i
  health_check_timeout 60
  preload "preload.rb"
  rackup_path "config.ru"
  url "http://[::]:#{ENV["APP_PORT"]}"

  endpoint do
    Async::HTTP::Endpoint.parse(url)
  end
end

Now that I think about it, perhaps this is actually one of its greatest strengths. Outside of fiddling with the number of workers we found worked best for our app and infrastructure, there's little to no configuration required. It just works.