VR startup considering Monday API to manage App Licenses

monday Apps & Developers
, ,
1

TLDR (By Chat GPT):
I’m looking for advice about using the Monday API to run software subscriptions. Its unconventional data structure and recent breaking changes raise concerns about long-term stability and frequent updates. While Monday’s front-end would benefit our Ops and Sales teams, we worry about the service’s pace of change. We aim to avoid recurring disruptions to our licensing feature. Guidance on the API’s reliability and its potential impact on our operations would be invaluable.

Hello everyone,

I’m considering using the Monday API to manage software subscriptions for Applications that my company develops and sells access to. I write seeking strategic advice more than technical instructions. Ideally, I’d also like to connect with a Monday product owner who’s interested in this use case, willing to vet it, and available for support or questions.

I’m a Director of Product and Technology at a small VR Training startup. While I’m relatively new to Monday, our team relies on it for various project management and operational tasks. Here’s a snap shot of my situation: we maintain four VR applications (Android / Unity /C#) and we own or manage around two hundred VR headsets worldwide, using an MDM system for access control. To accelerate our growth, we’re looking to implement a licensing system into our apps. Currently, we rely solely on the MDM for access management.

The license feature will work as follows: on first launch each app will report a unique hardware identifier, user-defined hardware name, and trial start date to a central repository. The repository will notify our teams, and our sales team will set appropriate expiration dates for each piece of hardware. Subsequent online launches will save the updated license locally. The sales team will update the repository are licenses get extended.

Initially, I considered running my own LAMP stack, then started researching CRUD services, looking for a stable cost-effective, user-friendly, back-end. Finally, I discovered that Monday might have the solutions I need. I’ve already created a fully functional prototype using the 2023-10 API through the API playground.

However, I’ve found the data structure for accessing values from specific items and columns to be a bit unusual. To retrieve the necessary data, I’m using expressions like “items[0][2][1][1],” assuming that the order of the table structure won’t change. I’ve also seen the notices about recent breaking changes. Additionally, support for the 2023-10 version, which was in preview just a few weeks ago, is set to end on April 1, 2024. And when I searched for API reviews, I found mostly complaints from a few years ago.

So, my question is: Will the Monday API become a recurring challenge for me? Will I need to constantly rewrite my licensing feature every six months? While the front-end provided by Monday would greatly benefit my Operations and Sales teams and the API seems to have good uptime, I’m concerned about its stability. We’re a small team. The functioning of this feature is crucial to ensure our users aren’t locked out of their paid applications, but I want to avoid frequent updates just to keep it running due to rapid changes from the service provider.

Your insights and advice on this matter would be greatly appreciated.

Thank you.

2

Whether it will be a headache for you largely depends on your (teams) experience with GraphQL. When it comes to stability of the API: we develop apps for monday from day zero. I think our AutoID Column app was the first in the marketplace. Over the last 3 years the change to 2023-10 is the only time there are many breaking changes. It took me only a few day to work through approx. 50K lines of code to make our apps 2023-10 ready

1 Like
3

I agree with Bas here. 2023-10 is an anomaly - and was driven mostly by the requirement to support the new mondayDB going forward and enable its capabilities, and fix some ancient oddities (like column type identifiers being different in different contexts!).

All of that said, how would your hardware communicate with monday without embedding an access token within the product? That’s a bad idea - because you’d be risking all of your customers data if someone extracts it somehow.

1 Like
5

Thanks @basdebruin , your response is speedy and helpful!

Noted about GraphQL knowledge, and my team’s GraphQL skills could certainly be stronger. (We’re mostly a C# shop that is focused on game Dev, not tons of API experience on the team.)

That said, with our business model, frequently the deployment is more painful than the Dev. So even a single breaking change that effects our query (And it’s really just one or two at this point) would be time consuming. We have lots of devices that may not touch network but once every 6 months, and I may not have a direct line of Comms to the device owner.

Does that additional context change your advice at all?

6

Thanks @codyfrisch! Great red-teaming. This is exactly the kind of help I was looking for.

If someone de-compiled our APK, our only real defenses would be obfuscation and compartmentalization within our Monday accounts. Not great.

It may be within my (move fast and break things) risk tolerance for now, but I’d like to pursue better. Do you happen to know of any Monday Apps with Oauth that I should review?

7

Many monday apps use OAuth but its not what you’re thinking. That said, I’d strongly consider the following architecture:

Use something like AWS API Gateway HTTP API + AWS Lambda to create some simple functions that do the monday interactions. (I am not going to go in depth here). Monday could be your database though. AWS CDK is a great tool for building out the infra and deployments. AWS CodeCatalyst is another tool thats good for managing deployments and development.

You’d create a registration page for the customer to register (AWS Cognito?), the customer would get a token to your licensing backend API. Then you’d make requests to your backend API, which would use the monday.com apps framework to invoke integration recipes to add and update items on the boards. The work being done to the boards would run on lambda functions (or azure functions, or just a vm, however you do it).

You’d need to use monday’s OAuth to give your backend a token though, so that it can do lookups of license data. However, you could implement a small database with license information tied to the hardware ID within the backend I’m describing. Then changes in monday use the monday apps framework to send updates to that database (and updates to that database get sent to monday?). Then you wouldn’t need to store any tokens in your backend.

But the reality is monday has no way to grant tokens that scope to specific items, nor can it issue tokens for anyone except paid accounts in your monday.com account. Which is why this isn’t an option for you.

But you can use monday as the database, build much of the automations you need within the monday platform, use monday for CRM purposes, etc. You just have to abstract the interaction with the devices to something non-monday and integrate that with monday.

I’d recommend a small database, NoSQL / key-value store is plenty most likely, which stores the essential licensing data the hardware needs, and mapping data for monday records (such as a monday item ID thats tied to a license in your DB).

Thats about as far as I can explain in the community - beyond that you’re getting into the realm of me actually developing your solution :wink: so thats out of scope.

1 Like
8

!!! Thanks @codyfrisch. You’re right anything else and we’d need to establish a consulting fee for you. :smiley: You’ve gone above and beyond. Will take some time to digest this, but in broad strokes I see what you’re saying.

9

Thank you all for the help provided here!

1 Like