Working on a component design. Need to add a parameter which will store a single event type, like user-created
. But with software systems being what they are — where what you’ve built is worth twice as much as what you’re planning to build — there’s always a chance that this simple value will be extended in some way. Say that it needs to be a list of event types (user create and delete events) or characteristics of the events will need to be configured (are we interested in getting all user create events, or only those for users of a particular type). What to do?
I could go with JSON right now, making the value something like {"events": ["user-delete"]}
. But that feels like overkill at this time. There’s no guarantee that what we’re building will ever need something as advanced as this. And the price of locking us into JSON now is that it’ll make configuring and reading these values more tedious than it needs to be.
So I’m opting for a simple string value now. If it needs to be extended to something more structured, I’ll use something like comma separated values. Sure it’s one more “ad-hoc mini-language” that’ll be added to the pile, but I think there’s value in keeping things simple now. The effort that may come from building a customer parser for comma separated values seems like a cost worth paying now. And if it does ever get unwieldily, we can always move to JSON down the road.
And just from a personal perspective, part of me is resisting the immediate turn to JSON whenever we need to represent structured data. It feels like no-one builds mini-languages anymore. And yeah, I see the reason why: no need to build parsers, and “everyone” knows how to work with JSON. Still this lack of diversity feels a little sad.