Rodauth VS sequel-activerecord_connection

Rodauth provides first class support for passkeys, implemented on top of the excellent webauthn-ruby gem. It enables using passkeys as a multifactor authentication method, or for passwordless login and registration. In addition to routes, views and database storage, it also provides the complete JavaScript part that interacts with Web Authentication API for zero configuration.

I can recommend rodauth: https://github.com/jeremyevans/rodauth It ships with a ton of things. Check out the features section.

In general, even though the Hanami ecosystem lacks any "plug-and-play" solutions such as Devise, you can use many existing libraries not tightly coupled to Ruby on Rails. For authentication, you can use Warden, OmniAuth or Rodauth. For uploads there is Shrine. The pagination is built into ROM. Integration with exception catchers such as Rollbar is easy.

While Devise provides a convenience layer around OmniAuth, it does nothing to actually sign the user into your app. When I started writing the OmniAuth integration for Rodauth, I wanted to go one step further and actually handle things like persistence of external identities, account creation and login, while still allowing the developer to customize the behaviour. That's how rodauth-omniauth was created. ✨

You can find the list of possible error identifiers here.

You probably meant the webauthn_login, which already supports passwordless.

When Rodauth came out, I was excited to finally have a full-featured authentication framework that wasn't tied to Rails, given that existing solutions required either Rails (Devise, Sorcery), or at least Active Record (Authlogic). Even though I mainly develop in Rails, I want other Ruby web frameworks to be viable alternatives, so I'm naturally drawn to generic solutions that everyone can use.

I wish there was the equivalent of this lib in go https://github.com/jeremyevans/rodauth

For the integration to work, I would need to make Sequel reuse Active Record's database connection. I discussed this idea with Jeremy Evans (the lead Sequel maintainer), and he provided me with some guidance, thanks to which I was able to come up a solution. It was a Sequel extension that retrieved Active Record connections, kept transaction state and callbacks synchronized between Sequel and Active Record, integrated SQL instrumentation, and reconciliated adapter differences (see my previous article for more details).

Our Rails app at work is using Active Record, but I started non-apologetically using Sequel for any features I'm missing from Active Record, because I don't have the patience for Active Record to catch up. For our analytics database we're using only Sequel, because AR was missing too many features (see my article), while for our main database we're using it in tandem with Active Record, reusing Active Record's database connection. I'm pretty happy that the latter is now possible, as it gives people the opportunity to try out Sequel without any overhead.

The way I look at it, a pure Active Record implementation could never be fully complete. That's why I instead chose the path of making Sequel integrate seamlessly with Active Record, by sharing a database connection as /u/honeyryderchuck said, hooking into Active Record's query instrumentation, and also by making Sequel transactions interoperable with Active Record's. It's also worth noting that core Sequel is significantly lighter than Active Record.

the main impediments to my using sequel in Rails are: authentication - which has largely been solved. Janko has written a gem allowing for rod auth to be used with rails, easily. https://github.com/janko/rodauth-rails - i believe he has also written another gem to make it easy to use sequel in a rails app https://github.com/janko/sequel-activerecord_connection

From a user's perspective, I've always found the fact that rom-sql uses Sequel under-the-hood as a big advantage. For someone who is familiar with Sequel it lowers the barrier of understanding how rom-sql works. And it's possible to leverage many of Sequel's useful features that rom-sql might not support OOTB (including performance optimizations such as sequel_pg), even if that requires dropping to the Sequel database level. When I announced sequel-activerecord_connection, one of the questions I received was whether that will work with rom-sql too (and it does).