Is using a cloud API really any different than any other client/server API? If you have developed with the Vault API, then you should already be familiar with many of the core concepts. Things like latency, user permissions and multi-user environments all still apply to the cloud. So is the cloud just a larger scale version of client/server programming?
No, there are some fundamental differences. Differences that need to be accounted for in your code.
Frequent updates, whether you want them or not
When a new version of PLM 360 goes live, customers have no choice but to accept the new version. For the end-user, this is usually a good thing. At the API level, it adds an element of instability. Gone are the days where you get your customization running and breathe a sigh of relief, knowing that things are working and stable for the next year or two until the next upgrade.
PLM 360 upgrades are about every 4 weeks, and everyone gets the update. These upgrades are not something you can plan for like with installed software. For example, a typical Vault upgrade involves the admin testing the new version, then planning when the upgrade should take place. PLM 360 is not like that. It updates without warning, so you can’t plan for it. And you definitely can’t pick the date.
Sometimes a Vault upgrade will go wrong and the customer will decide to stick with the older version for a while longer. Which brings me to my next point...
You can’t go back
Once the PLM 360 upgrade happens, that’s it. You can’t go back to the older version. In fact, the old version doesn’t even exist anymore.
This fact adds an extra complexity to debugging. If you notice a new bug, it’s hard to determine if it’s because of a PLM update or if it’s a bug that was always there, and you just never noticed. With a desktop app, you could always install the prior version and get a definitive answer, but you don’t get that with the cloud.
Sometimes it’s not a bug, but your app is... different. For example, the data is being displayed differently or a command has different results than before... you think. Again, it’s hard to know if it’s because of the PLM update or old age.
Tips for working with the cloud
Here are some pieces of advice for working with a cloud API. If you have an more advice, let me know in the comment section.
- Forward Compatibility - Your code should always expect the unexpected. Avoid assumptions as much as possible. For example, PLM 360 currently has 6 types of workspaces. Next week, it may have 7. You code can’t crash if it comes across a workspace type it has never seen before.
- Smoke Tests - Create an automated test of your app’s functionality. The advantages are numerous. You have an easy way to spot issues before users do. You have a mechanism for pinpointing the exact failure. Saving the smoke test results gives you a document of how things worked in past PLM 360 versions.
- Documentation - Be thorough in documenting your app’s behavior. Record videos if you can. If not, then take lots of screenshots. Again, the goal is to have something to reference if you believe there is a change in behavior.
The Autodesk side of things
Obviously, we here at Autodesk also want your apps to be as stable as possible. Here is what you can expect from us.
- Backward Compatibility - Just like your app needs to be forward compatible, the PLM 360 API needs to be backward compatible. Although content will be added to REST v2, existing content will not be changed or removed. If a situation arises where the data model needs to change, that new model will go into REST v3.
- Defect Fixing - If you believe there is a defect in the API, let us know. One of the major advantages of the cloud is the ability for us to fix defects quickly.
- Developer Services - We are working on some initiatives that should alleviate some of the pain points that I mentioned. But, I can’t say anything more at this time.
Subscribe