Open source / SaaS split #1697
Open source / SaaS split #1697
Conversation
jorgemanrubia
force-pushed
the
open-source-split
branch
3 times, most recently
from
323b2bf to
49cf4d6
Compare
| @@ -0,0 +1,8 @@ | |||
| # This Gemfile extends the base Gemfile with SaaS-specific dependencies | |||
There was a problem hiding this comment.
Just a note that I had originally kept these dependencies in the Gemfile so that bundle install and bundle exec would work as expected if we have the SAAS env var set. My initial reaction is slightly negative, but I'm willing to give it five minutes.
There was a problem hiding this comment.
The problem with a single Gemfile and a conditional inclusion is that, whenever you toggle the mode, you end up with a changed Gemfile.lock.
I agree about the bundle install issue. To me, this was the lesser inconvenience in terms of dev ergonomics. You can use bin/dev and it will take care of setting the right Gemfile. And we could also add our own bin/bundle wrapper that takes care of that.
If you have a better approach in mind please share. I landed here by trying different approaches (conditional inclusion, gem groups, separated gemfiles), but not holding any strong opinion other than trying to make things as seamless as possible.
There was a problem hiding this comment.
Oh, I do like the idea of having a patched bin/bundle stub. But also I'm fine giving this five minutes and seeing if it's actually a problem.
jorgemanrubia
force-pushed
the
open-source-split
branch
5 times, most recently
from
398037f to
35bf35b
Compare
jorgemanrubia
force-pushed
the
open-source-split
branch
7 times, most recently
from
561c34d to
2bf333f
Compare
| ## CRUD operations from controllers | ||
|
|
||
| In general, we favor a vanilla Rails approach to CRUD operations. We create and update models from Rails controllers passing the parameters directly to the model constructor or update method. We do not use services or form objects to handle these operations. | ||
| ## Controller and model interactions |
There was a problem hiding this comment.
@flavorjones I reviewed a bit the style guidelines regarding controller and model interactions. I think it was emphasizing too much the enter/review pattern we used in HEY, and not emphasizing enough the general approach: clear model APIs directly invoked from the controller.
jorgemanrubia
force-pushed
the
open-source-split
branch
4 times, most recently
from
a6acb89 to
05b7ce6
Compare
| Use Sentry MCP tools to investigate production errors: | ||
| - `search_issues` - Find grouped issues by natural language query | ||
| - `get_issue_details` - Get full stacktrace and context for a specific issue | ||
| - `analyze_issue_with_seer` - AI-powered root cause analysis with code fix suggestions |
There was a problem hiding this comment.
@flavorjones I see you already placed a more compact prompt for observability/sentry in shipyard. I am removing these bits since these are not appropiate for the open source version. All the observability config resides now in the gem. If we need the specialization, I think we could move to the gem fizzy-saas and instruct in the prompt about it. But it is probably better if we can go with a single compact version of this at the shipyard level. What do you think?
jorgemanrubia
force-pushed
the
open-source-split
branch
from
eb08c11 to
67c0e90
Compare
This reverts commit 7d6ed4a.
jorgemanrubia
force-pushed
the
open-source-split
branch
from
fe66064 to
d561a64
Compare
Separate SaaS and open source versions of Fizzy.
The default version will be the open source one, that runs on SQLite. This is built on top of the work by @djmb in #1669. @flavorjones had done some previous work where the semantics was inverted (opt-in into open source). I think it makes more sense to have the vanilla open source version as the default, now that we are going to make the whole thing public.
This PR introduces a mehanism to enable the SAAS version of the app:
SAAS=1(this will enable the private gems and configure the MySQL adapter).tmp/saas.txt. There are rake tasks to touch/remove itbin/rails saas:enableandbin/rails saas:disable.(2) is meant for our own dev work, so that don't have to worry about passing the env var during regular daily work. The goal here is having good development ergonomics for everyone:
tmp/saas.txtand we are ready to go with our private extensions and MySQL, using exactly the same scripts vanilla users would use.For configuring the private gems, this introduces a separated
Gemfile.saasfile, that includes the originalGemfileand adds the private gems. In SaaS mode, it will configure the bundle file automaticalyl to use the saas one.(1) is meant to be set in our SaaS hosts via our SaaS Dockerfile, although obviously you are free to use that too locally.
This also moves several bits to the
fizzy-saasgem, which now lives in its own private repo:database.mysql.ymlanddatabase.sqlite.ymland, in SaaS mode, uses thedatabase.ymlfrom the gem. This way, we can keep our very specific MySQL setup outside of the open source version.bin/setupthat are specific to 37signals.Pending: