Not sure what can be done about it but as a developer I find extremely annoying when I get back a JSON response from your GraphQL API that includes a mix and match from both Lower Camel case strategy and Snake Case Strategy. Is there is any reason why you are not using a common property naming strategy? You can clearly see that attributes under the event path are with Lower Case while under the value attribute they are with Snake Case
Sure there are lots of inconsistencies. It looks like these changes are introduced over time and you don’t want to break existing apps. That also why an itemId is still called a pulseId in the events. That’s from the time monday.com was called daPulse
It doesn’t look that they will change this and we as developers has to live with it.
@basdebruin I appreciate the response and I understand this. With all of the respect though there is a difference when it comes to maintaining an integration contract versus making it difficult to work with it. I’ll give you another example.
When we get create web hook event the id is referred to as pulseId while when we get back an archive event we get back an itemId.
I understand the reasoning for this, but you either make consistent changes across your APIs or you introduce aliases BUT never break consistency as it makes it extremely difficult to work with.
I can’t complain, the API and webhook calls has been extremely helpful for our use cases but these small details end up taking time having to figure out why specific things don’t work. So yes +1 on backwards compatibility but again, use aliases or the least common JSON format within the same document. Honestly at this point I doubt that is possible to change it unless you introduce a v3 of it. You can definitely though add aliases on your documents so that you can support both items and pulseId and issue a sunset day on your next major version release
Fully agree that we are at a point where an V3 API is needed. Some of the current inconsistencies can be somewhat explained if you know the history, still there are lots of others (column type names as an example “status <> color”, number <> numeric"). You would also kind of expect (or at least hope) that the format of a (previous) value returned by a webhook can be used unmodified as a value to update an item / column through the API.
Concur, a v3 thats a fresh start would be great, along with that an enhanced apps platform which lets us define apps in code, aws-cdk style. Ideally with that, a series of epics related quality and craftsmanship in general. Polish, polish, polish - will pay off by making future feature development much easier.
Just wanted to update
That we aligned all our API for webhook event for create_subitem, delete_subitem, archive_subitem and now both of them returning itemId and pulseId when event is triggered
That is good news. Are the delete and archive subitem events also sending the itemIdParent and boardIdParent (as the crate and change events do)? Without knowing where the item was deleted / archived from it is hard to develop apps with full support for subitems.
That is wonderful. One little thing that costs me a few hours to find out.
create_subitem and change_subitem_column_value send (among others) parentItemBoardId
parentItemId
With this update subitem_archived and subitem_deleted send (among others) parentBoardId
parentItemId
Why is it so hard to be consequent? See: parentItemBoardId vs. parentBoardId