keygen-api

This is interesting. I've been using my transactional email provider (Sendgrid) to manually [0] send newsletters to ~10k subscribers -- essentially the active accounts -- but I've noticed that my response rate has been super low the last year or so (relatively), so I'm wondering if my domain rating has taken a hit. This firewall is interesting. Maybe I should switch to a newsletter provider like this instead of sending as transactional email? I figured it wouldn't scale and that it'd bite me eventually... [0]: https://github.com/keygen-sh/keygen-api/blob/master/lib/task... p.s. it's a pet-peeve of mine when docs subdomains have no obvious link to the top domain!

Part of my "week of open source" [0], today I released union_of. This gem for Ruby on Rails allows you to create Active Record associations that combine other associations using SQL UNION under the hood. It has full support for joins, preloading, etc., because the UNION association is a real association. That also means it can also be used for complex through-union associations. I've been working on this gem for about the last year [1]. It took me around 9 months to implement in a performant way, and I'd say it's the pinnacle of my Ruby career. It's definitely some of the most complex code I've ever written, touching so much surface area of the Rails internals. It helped me successfully make it through one of the most complex data migrations I've ever had to do, and all without breaking backwards compatibility. Many failures [2], but ulti

I looked at SSPL, but it was really between BUSL and ELv2 for me. I ultimately chose ELv2 because it allowed me to keep my community edition and enterprise edition in a monorepo, where the latter edition is protected by license keys, i.e. ELv2 has a clause to where you can't remove or circumvent the license key functionality. Since Keygen was previously closed source, I didn't want to split the repo up into the ee/ directory structure that you commonly see in other open core and fair source projects. I deemed doing so as 'too risky' -- too much code churn for little benefit -- as those changes would have a direct effect on the SaaS. Instead, I opted for ELv2 because it offered me the ability to say, "hey, I'm making this fair source, do what you want with it, just don't compete with me or remove the license gates for the paid features." H

Keygen uses Keygen to license itself via license gates: https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53... (the EE edition requires a license key with entitlements to access the EE features).

I have a single code base [0] for the self-hosted editions and for the SaaS. I split features up across two editions: community edition (CE) and enterprise edition (EE), and then also two modes: singleplayer and multiplayer (single- vs multi-tenant). The switching is done via environment variables, KEYGEN_EDITION and KEYGEN_MODE. The SaaS offering actually runs the EE edition in multiplayer mode, and is right now the only instance of the EE edition in multiplayer mode (other EE customers are entitled to singleplayer only). I've been running this set up for about a year [1] and it's working well. Having a single code base was a requirement before I made the project fair source [2]; the fair source ELv2 license lets me add feature gates to facilitate this, while protecting me from forks giving away EE features for free (while still allowing

I don't have an Elixir background (though I envy Elixir in many ways), but I absolutely utilize pattern matching in my Ruby code bases: - https://github.com/keygen-sh/typed_params/blob/4e4982b7d2b26... - https://github.com/keygen-sh/typed_params/blob/4e4982b7d2b26... - https://github.com/keygen-sh/keygen-api/blob/36cd61db143cc1c... - https://github.com/keygen-sh/keygen-api/blob/36cd61db143cc1c... - https://github.com/keygen-sh/typed_params/blob/4e4982b7d2b26... I love it. I want even more pattern matching too, like defp: https://bugs.ruby-lang.org/issues/19764 (with original credit to https://zverok.space/blog/2023-05-05-ruby-types.html).

Honestly, I don't have many resources to provide. I read a lot of policy tests via GitHub search (e.g. path:spec/policies/*/*.rb), but couldn't find anything that looked like what I wanted. I wrote the DSL as-needed in order to fully test my app's authz while migrating from Pundit to ActionPolicy (while also introducing fine-grained permissions). It's not the prettiest when you actually look beneath the covers [0], but it does what I wanted -- providing an easy way to write exhaustive authz tests. Without the DSL, I probably wouldn't have written the tests. The PR for said migration was massive [1], and was a prerequisite to going open source [2]. [0]: https://github.com/keygen-sh/keygen-api/blob/master/spec/sup... [1]: https://github.com/keygen-sh/keygen-api/pull/647 [2]: https://github.com/keygen-sh/keygen-api/issues/644

> I personally find tests that have a ton of extra helper classes/functions to do stuff like set up fixtures or do assertions to be painful to deal with. I think it depends on the context. For example, I typically agree, but when I was writing authz tests [0], I ended up writing a DSL so that 1) I'd more more inclined to write the thousands and thousands of tests, and 2) I'd be able to focus on the actual authz assertion and not on verbose setup. I couldn't imagine writing those policy tests without that abstraction. I would have lost my mind with all of the repetition, and would have almost assuredly made mistakes. [0]: https://github.com/keygen-sh/keygen-api/blob/master/spec/pol...

Yes, I can see why you might make this argument. [1] [1] https://github.com/keygen-sh/keygen-api/blob/master/LICENSE....

Since when can you run heroku pg:upgrade to switch database tiers? I've been following an upgrade sequence I put together over the years [^0], but I guess Heroku automated this at some point? What would be really funny is if this had been possible all long... [^0]: https://github.com/keygen-sh/keygen-api/blob/master/.notes/d...

Composer makes it hard [0] to offer an artifact service for it because it authenticates per-domain, not per-package. For example, if you required 2 private packages from GitHub from php.pkg.github.com, you wouldn't be able to authenticate with both separately. You can only authenticate with php.pkg.github.com, not php.pkg.github.com/org-1/package and php.pkg.github.com/org-2/package. It's not ideal, but the workaround for this is to use subdomains: - org-1.php.pkg.github.com/package - org-2.php.pkg.github.com/package I wonder if that had any impact on their decision. [0]: https://github.com/keygen-sh/keygen-api/issues/490

typed_params is an alternative to Rails strong parameters for controller params, offering an intuitive DSL for defining structured and strongly-typed controller parameter schemas for Rails APIs. We’ve been using it (and iterations of it) since 2016 [0] and just recently extracted it into its own open source gem. [0]: https://github.com/keygen-sh/keygen-api/commit/fb9ade2cac60a...

I disagree. If I was trying to take advantage of it, I'd use the term "open source" everywhere like some other projects do. But I tried to find a middle ground so the zealots would be happy(ish). But in the end I'll never make everybody happy, regardless of how much I stress about words [0] [1]. [0]: https://github.com/keygen-sh/keygen-api/issues/644 [1]: https://github.com/keygen-sh/keygen-api/pull/668