Anyone have an opinion on doing a resource per file or group

Question

Anyone have an opinion on doing a resource per file or grouping resources into a component file For example if I have a project deployed to kubernetes We have the `Deployment` several `CronJob`s `Service` `VirtualService` istio `HorizontalPodAutoscaler` `PodDisruptionBudget` a CloudSql database database users etc Would you recommend app ts contains the resources deployed to kubernetes AKA the application database ts contains the resources to create the database and the users index ts requires the other 2 Or would you recommend app deployment ts app virtualService ts app podDisruptionBudget ts cronJobs cronJob1 ts database instance ts database user1 ts

gorgeous-egg-16927 · Answer

I usually prefer to manage related resources within a ComponentResource class and I split up the files by class rather than resource So closer to option 1 than option 2

gorgeous-egg-16927 · Answer

But the real answer is whatever works for your team slightly smiling face

cool-egg-852 · Answer

How long are your files typically

cool-egg-852 · Answer

Like I have one right now that is around 1000 lines And navigating between resources is more of a burden because of that

gorgeous-egg-16927 · Answer

Rule of thumb I try to keep them under 300 LoC

gorgeous-egg-16927 · Answer

But there are always exceptions to that

cool-egg-852 · Answer

What would you do though in this situation where it needs to be this Trying to figure out the best architecture Right now I m considering mirroring the helm style of one resource per file

cool-egg-852 · Answer

I do kind of wish there was a recommended standard way to handle this all in pulumi Obviously nothing works for absolutely everyone but a general recommendation Lot of the examples are just `index ts` which doesn t seem like a real world scenario

gorgeous-egg-16927 · Answer

The main tradeoff to consider is how easy it is to reference any variables you need Splitting up the files requires more planning on which variables to export Usually I start with one big index ts file and then split out components as it makes sense

gorgeous-egg-16927 · Answer

For example if you have a Deployment + Service that references it it requires more work to sync up selectors labels ports etc if they are in separate files

cool-egg-852 · Answer

For us I think that part is actually rather easy We ve built up and are continuing to build up a configuration object that is used for every application A large part of our infrastructure code is the same We haven t gone the way of a ComponentResource because right now it s a bit easier to have the flexibility We just finished getting to a configuration object from the old flat structure

cool-egg-852 · Answer

Though it is my goal to make more use of ComponentResources in the future so we can achieve better grouping

cool-egg-852 · Answer

I appreciate the input We ll have to keep on investigating

swift-painter-31084 · Answer

One of the pros of using ComponentResource is that you get namespacing and hierarchy among your Pulumi resources Pulumi s resource graph visualization looks prettier but I m pushing for this more internally and haven t found other pros of this approach aside from component reuse Idea

cool-egg-852 · Answer

I wish there was an easier way to do the namespacing and heirarchy to be honest

cool-egg-852 · Answer

It shouldn t need to depend on ComponentResource

cool-egg-852 · Answer

Introduce new options in the `options` parameter of every resource ```new Resource name namespace namespaceName ```

cool-egg-852 · Answer

Or something like that The downside to ComponentResource is that it s more of a hassle to use Always have to remember to set `parent this` the constructor etc etc Much easier to just work with raw resources

cool-egg-852 · Answer

This could just be a downside to the TypeScript SDK but that s generally a reason we don t make use of it code reuse aside as we may or may not even want code reuse in some cases as we like to explicitly see a lot of our resources