source-monday: new connector

[JustinASmith]

Description:

This is an initial version of a connector to capture Boards, Teams, Users, Items, and Tags from Monday's GraphQL API.

There are GraphQL/API limitations worth mentioning:

• Individual queries have a complexity limit of 5M / Minute. Complexity defines the load that each call puts on the API.
• Queries have a max depth limit of 7, therefore, deeply nested items can sometime be challenging to obtain.
• Limit on number of queries that can run per minute and day.

Currently the streams are set up on a 5 minute interval. However, the API still produces HTTP 429 (i.e., Too Many Requests) even with this interval since each binding try to execute concurrently. The HTTPSession class is already set up to handle rate limiting, back off, and retry. This has seemed to work okay, but Monday.com also has a way to check the current complexity budget and complexity cost of a query. I have a function that can be used to check the current budget and wait until the complexity budget next resets. We may either need to use the complexity checks or extend the CDK to have some sort of queuing mechanism for requests so that we do not exceed complexity or requests per minute limitations.

Workflow steps:

(How does one use this feature, and how has it changed)

Documentation links affected:

(list any documentation links that you created, or existing ones that you've identified as needing updates, along with a brief description)

Notes for reviewers:

Tested on local stack. Confirmed:

• OAuth works as expected in the UI when setting the redirect_uri to localhost:3000 for the OAuth app in Monday.com.
• flowctl preview shows valid results in standard out.
• flowctl raw spec
• Currently running into SpecFailed errors again when installing connector in local stack.

OAuth2 Enhancements:

• Added AuthorizationCodeFlowOAuth2Credentials class to support authorization code flow in OAuth2.
• Modified TokenSource to handle AuthorizationCodeFlowOAuth2Credentials in the fetch_token and _fetch_oauth2_token methods. [1] [2] [3] [4]

---

This change is 

[williamhbaker]

Looking really good so far! No major issues that I can see, and not even really any minor issues from a quick look.

Some general thoughts:

• There's a balance between query complexity & usefullness of information we get back. Get more information is good but more expensive. I'm not saying anything needs to change with the queries, but one thing to keep in mind is that it is much easier for us to modify the connector to add new fields in the future, rather than removing them, from the standpoint of backwards compatibility.
• I advised you to try to use our standard HTTP backoff mechanism...I think that's probably still a good idea, but considering what you've found about how restrictive the API limits are, I think it is very likely we are going to want to rig this up to processing bindings in a serial fashion, rather than all of them concurrently. We can wait and see if its an actual issue that user tasks encounter though.
• It would be worth sharpening the pencil a little bit on some of these streams to see if a practical incremental strategy exists for them. That would prevent us from needing to manage compatibility issues in the future if we found that we wanted to make streams incremental and such a thing was possible, where the collection key would need to change as a result (from _meta/row_id. If we could make any of these incremental it should also help with how much of the complexity budget they use too.

[JustinASmith]

Partial self review

[JustinASmith]

Limitation(s) identified:

• Renaming a subitem does not register in the activity log as an event.

[JustinASmith]

@williamhbaker I have moved this to ready for review. I have made the minor changes we discussed in Slack and on our previous VC.

[JustinASmith]

I am checking into CI failure now. I tested locally and all worked fine, but I had my test.flow.yaml slightly changed to use custom config instead of config.yaml

[williamhbaker]

Made some inline comments below!

A couple of more general things:

• I recommend enabling a type checker and fixing anything it flags if you haven't already done that. I mention this in one of my comments as well - I pulled this PR down and pylance flagged a few things that I think are legitimate issues to resolve.
• The graphql.py code could benefit from some more explicit data modeling. Ideally we'd have pydantic models to represent the shape of the API responses, and could use those in place of more dynamic typing and dictionary lookups. I am 100% sure how practical this will be do to so this isn't a total blocker, but if you're able to make any improvements there I think it would help the maintainability of the code.

[williamhbaker]

Not sure what this does?

[JustinASmith]

This will rebuild the model schema, which I think is needed since subitems is a Forward Reference and Python cannot know what Item is at class definition time for this subitems field.

[williamhbaker]

Hmm we have lots of examples of using forward references that just put the class name in quotes. What happens if you get rid of this Item.model_rebuild line?

[JustinASmith]

Hmm you are right. I guess I did not need that after all. I will update to remove that line since I just tested without and everything worked as expected!

[williamhbaker]

LGTM

One remaining tiny question, but overall the updates look good!