Add environment-level function config #69
Conversation
|
|
||
| if (!isObjectLike(environmentOverrides)) return { ...rest }; | ||
|
|
||
| const overrides = environmentOverrides[environment]; |
There was a problem hiding this comment.
More a thought process than a change request,
I'm wondering if there are overrides we should think about not allowing.
First I would think is cloud, it seems unlikely anybody would require functionality to change from the parent providers cloud provider. (Though I'm not sure AWS actually made it in to Cloudseed?)
I am wondering if type would be another? Would there ever be a use case for a differing trigger/type between environments?
Not a blocker, and I'll approve but it did cross my mind when looking at the PR. Whats your thoughts?
There was a problem hiding this comment.
@AndrewBarber I thought about that too while writing the code, but then I thought "why?".
There's no technical reason why that wouldn't work. The overrides are applied during esbuild, so once you get to generating infrastructure, it's as if that value was set at the global level. So we'd only be limiting the overrides because we think that something wouldn't make sense to do. That is until we end up with a project where we want to do exactly that and then curse ourselves for putting an arbitrary limitation in 😂
So I decided to not put any limitations in. If someone wants a function to be http triggered on staging, but queue triggered on production, they're welcome to try it out. They can decide if that makes sense or not for their project!
That, and also the configs are completely untyped at this stage, so I didn't really want to mess around with them too much and introduce an inconsistency on what TypeScript types allow and what's actually validated at runtime.
There was a problem hiding this comment.
Yeah thats completely fair, thank you for sharing the thoughts on it 😃
If someone wants a function to be http triggered on staging, but queue triggered on production, they're welcome to try it out. They can decide if that makes sense or not for their project!
Internally at Space, we need to ensure that this is considered. So that various teams are aware (QA, Support, Squad) of the difference in environment, and decisions documented in the confluence spaces. I can actually think of reasons why this might be a 'good idea', however, it could quickly become a divergence in how we QA work and what the end result is.
Hopefully you agree! (?)
Upon the announcement internally, can you mention the above please? 🙏
There was a problem hiding this comment.
Yep, 💯 . Will do!
No description provided.