Any ideas/best practices on organizing ion deployments

Our ion project is rapidly growing and has reached the point where it’s starting to make sense to break it into multiple projects/repos. It’s so far not that clear on how one would manage this. push/deploy seems to expect the :app_name in ion-config.edn to be the same as the target system, as opposed to identifying an ‘app’, grouping of functions, etc. that’s in a given system. Anyone tackled this?

Hi @eoliphant,

I know you and Stu discussed this in Slack. I wanted to cross post in the event someone finds this thread via google. Please feel free to add any details I’ve missed. I am going to copy out his responses to you in Slack below:

You can set the application name when you create a system, see Ions Reference | Datomic. If you have N library projects and 1 app project, the app project should have the ion-config.edn file.

An Ion app is 1-1 with an AWS CodeDeployment app, which is the unit of deployment to a compute group (not a system). When we release query groups (see Datomic Architecture | Datomic) you will be able to deploy a different app to each query group in a system, if you want.

We are currently working on query groups, but this requires a new CloudFormation template which represents coordination with AWS.

I am recommending “popup solo system per dev who needs isolation”, query groups will provide another axis here.

1 Like

Hey @jaret, thanks. Yeah, I think you guys have cleared up what’s available and what’s coming. As as Stu and I discussed, given the newness of it all, we’re kind of developing the patterns as we go. Working on an effort that’s relatively small and ‘appish’ at this point, but has a relatively long tail, so trying to game out the longer term patterns that will be required.

The app/query group sounds more or less like what would do the trick. Moving from clojure/datomic microservices that are db per service but use a single transactor, so this would more or less map directly to that pattern.

Until we get the query groups, just noodling through the best way to divvy up app vs lib code, support testing, etc. Will post updates, and certainly keep an eye out for what other folks are doing.