This is Thomas – one of the dedicated developers behind APEER. We have all been working hard for the past 18 months to get APEER up and running. Now that it’s live and you are using it we get a lot of feedback which features we need to develop in the future and which parts are not as easy as they should be. One of those parts is the creation of modules itself. As software developers we often don’t realize things that are part of our daily business can be real hurdles to you. The three things you have to deal with if you want to build a module on APEER are
Today I’m very excited to tell you how we already solved the first problem in this list.
Those of you who already created a module on APEER will know that it is actually not that easy to access your inputs. Inputs come in as a JSON structure via environment variable called WFE_INPUT_JSON. This could look like this
That means your code has to read environment variables from the operation system it’s running on. In Python that could look like this
But this is not enough since you also need to parse that JSON.
Now you would be able to access your inputs in the json object
Congratulations you read one of your inputs. But that’s not all since you also need to provide your outputs as inputs to the next module, which you do by generating the above mentioned JSON structure yourself and writing it to the wfe_output_params_file. And you also need to know where to store the files you generate such that the APEER environment can find them after finishing your module. All in all that is too much knowledge you need to have about our system.
So that’s why we are announcing the APEER SDK Family. We have been working intensively on three open source APEER SDKs in the languages available as examples on APEER. These SDKs take away all the pain you might have had with reading inputs and writing outputs. All you need now is a single line of code for reading your inputs and a single line of code for each output. You don’t need to know anything about environment variables or JSON structures because the SDKs hide that away. All modules you can use as examples when creating a new module already use those SDKs. We currently have
In case you want to have a look into the code you can. They are all hosted on GitHub. And the best part is: They are all open source under MIT license and, of course, free. That means you can also contribute to them.
Let me quickly show you how easy module creation becomes with the SDKs. The structure and method names are the same for every SDK. So I’ll use the Python SDK as an example here. This can easily be installed via pip install apeer-dev-kit.
The main idea of the SDKs is that it keeps the technical code to communicate with the APEER environment completely seperate from your code. So you can concentrate on the actual image processing problem and test and use your code independently from APEER.
All our examples have a apeer_main file that serves as the entry point to your module and uses the SDK to read the inputs, writes the outputs and just calls your code, which we will just call your_code.py and assume it has a method run(input_image, threshold).
That’s it. That’s all the technical code you need to execute your module on APEER. You can know go ahead and implement your_code.run(...). It actually doesn’t matter how you return the results generated by your code but we recommend a dictionary.
Ok, there you go. We hope that you will have no more pain creating modules on APEER and can concentrate on the actual problem, like creating a machine learning workflow for Neuroscientists like the one we just published.. We will be working on more SDKs and also aim to solve the other two problems on this list. So stay tuned!
If you have any questions feel free to comment on this post.