In this article I will try to share what I learned and what I found out when developing the API wrappers I have done for Adobe. As you may have noticed I have developed some wrappers for the solutions I am working with.
First I would like to say that these development came mostly from outside my current job I have. One of the most common question I received from people is if these wrappers are the official Adobe python API wrappers. This is not the case, this is just because I wanted to have side projects to learn coding in python and also because I felt that other people may find it interesting.
They have been mostly done to help ME on my work and I shared them as I feel more intelligent people can use some shortcuts to develop their own API wrappers.
JWT Authentication
This is the basis of any Adobe IO API but this step has proven to be quite difficult for many persons I know. I personally spent hours trying to understand the way to encode the whole JSON element and retrieve the token to access the different API.
The good news is that once I have created that, I was able to re-use that code in all of the other Adobe IO APIs I am using.
Actually I have even created a blog post on this specifically and it is one of my most popular blog post so far. So definitely, JWT authentication is something that most people are struggling with.
Adobe has also provided some guidance on this but I would recommend that instead of following my tutorial or Adobe one, you try to create something on your own and therefore, you will better understand the logic of this method.
This will be super useful for other API connector you are going to create.
Adobe Solutions
From some time now, Adobe has started to be API-first oriented. What do I mean by that ?
All of the new solution developed recently by Adobe are using public, or semi public API to communicate and the rendering is done independently from the engine.
What it means is also that when the APIs are being exposed to the public, you are technically doing the exact same things than the Adobe solution itself. This can provide a very good way to learn the possibility of the Adobe solution you are developing but it can also enable you to expand the possibility of the Adobe Solution.
Per Example, for Launch API, one common use-case I am doing with the API connector I developed (pylaunch), is to create an extract of all of the rules that are using Adobe Analytics Extension.
What I can do after the extraction is to researched for specific pattern in my rule components. Any of them.
Example : It could be that a condition is actually using the correct script or where are located specific eVar elements.
Testing libraries
To say that I learned tests when I developed the Adobe APIs would be a lie, I knew them beforehand but because I am a marketing guy doing mostly hacky JavaScript or Python scripts I never looked into it with real interest.
When developing my APIs and trying to share the libraries with other developers or enthusiast it was quite challenging to tell them what I was doing or expecting from the different methods.
The problems with the APIs is that it actually requires the response to actually go forward most of the times. You request data and from that data you actually request something else.
Without access to these APIs it is quite hard to follow and the usage requirement and see the different steps.
One way to do it (other ways exist – including reading the API doc 😉 ) is to have test implemented so you are checking that the output are correct from new implementation.
I discovered that, or more correct; I faced it when trying to work with another person on a big library that would encapsulate the full Adobe IO connection (Analytics, Admin Console, Launch, even Audience). It was impossible to work without having some expectation on the outputs of the APIs wrapper.
Multi-threading, Decorators and other advanced topics
One of the thing I discovered and apply directly on my APIs was the usage of a decorators. Decorators are functions that run on-top of methods in a class.
These functions are quite useful because you just need to write them once and they are applied to anywhere you put them.
These functions also exists in JavaScript and when you develop your own little program, I can definitely imagine using it more often.
At the same time, I understood and applied the multi-threading process on some API wrappers and this was very interesting.
I remember that I was thinking that I would never really need this kind of development and this was so far away… It is what real developers are doing, not me… I was wrong.
Overall developing the APIs has proven to be a very interesting sandbox for me applying “advanced” topics so I will definitely recommend that to improve your coding skill.
What I still need to learn / apply
I know that I need to be more consistent with Github commit more often, lots of the time I am publishing when finished with my changes. I may need to be more efficient on scoping my improvement.
As I said, I need to get more test on my APIs. At the moment, there is no test and python provides some interesting library that I should use more often.
I need to start using formater as black as it is apparently quite hard to follow up with my code structure. This is not a issue for me as I read myself pretty well but if I want to attract more people and more ideas to the different APIs wrapper I am building, I may need to do that as the next first steps.
Engaging more with the community, or with users of the tool would really help better understand the use-cases required to develop it. I had the chance to have some valuable feedback on the Launch API wrapper and Analytics 2.0 API and I could improve both of these but Admin console is actually not really use, an Excel tool (BAAM tool) exist for Audience Manager so less people see the need for them.
Also, python is an easy language but the “cool kids” are doing JS and the “real analysts” R.
In the future, with Adobe Experience Platform coming, I can imagine myself quite busy with some API wrappers. So I hope my learning wasn’t in vain.