Recently I switched jobs and started coding in Elixir professionally. I feel proficient enough at work where most things are set up and running, it’s relatively easy to develop and add new features. However, I wanted to get a better understanding of setting up an Elixir project and tooling from scratch. So I decided to start simple and to try and write an Elixir wrapper for a 3rd party API. I thought it would be a simple enough project to get up and running before jumping into a more involved project. I had recently seen an article about Alpaca, a service that allows you to “trade with algorithms, connect with apps, build services — all with [a] commission-free stock trading API.” So I took a look at their documentation and didn’t see an Elixir wrapper yet. I then did a quick google and saw one Elixir github project using it but it was years old and unfinished. Seeing as there weren’t any existing wrappers, I decided to give it a go. So I signed up for an account and started reading through their documentation. Alpaca actually offered a free sandbox environment for every account that you could use to issue API requests just as you would in real life, but with fake money. I thought this was fantastic, I could actually issue requests against an API without having to use real money. It cost me nothing, and could benefit countless developers in the future if I launch my API wrapper.
Why doesn’t everyone do this
This seemed like a win-win to me, but also something I rarely see in 3rd party software that offers an external API. Rarely is there a way for you to develop against an API unless you are already a paying customer. I’ve developed a couple of other language specific wrappers for API’s before and they always required signing some sort of contract or buying some sort of product before we could actually start developing against it. Wouldn’t it be great to not have to pay in order to test an API and develop against it? I think there are a few benefits of offering free developer accounts and a sandbox environment to developers
-
It allows open source developers to do your work for you. Sure you can build out wrappers for some core languages your team has expertise in, but there’s dozens of languages that people use and unless you are a very large company it is impossible to develop against them all. Why not let developers write wrappers for languages you can’t support. This could attract more customers for you in the end. Whether or not a language specific client exists for a given service could be the difference between choosing your service and another service (although obviously this is not always the case).
-
You get free debugging work. When adding new features to your API, developers can easily be the first to use it and find something that isn’t working as expected. Alerting your team to a bug hours, days, weeks, or even longer before you would have noticed it yourselves.
-
You get free security testing. Once again outside developers who have access to test accounts can perform security tests and penetration tests for you and find issues with your security way before you would ever find them. This is also possible in production but you open yourself up to even more rigorous testing with access to a developer account.
-
Create a larger community for your service. By allowing developers to have free test accounts you open up the community of users to not just paying customers but potential future paying customers and advocates. These developers may not need your service right at this moment but there may come a day in the future where their company needs your service, and they will know exactly who to recommend.
These are just a few of the reasons I can see why it would make sense to offer free developer accounts. Obviously though it does come with drawbacks. There’s the extra work of maintaining developer sandbox environments, however I think in general your own in house developers will already have this and if they don’t they probably should. Why not find a way to offer it to external developers in a safe way as well? Another drawback is that you may use this sandbox environment for testing new features, but this also could be something you would want external developers testing. Although you may not want them using new features right away, you can get free testing on beta features from external developers by allowing them to have access. You could also argue it’s a security risk, but I think an argument can also be made for the other side. That if you are doing it right there shouldn’t be a security risk. Your sandbox/staging environment should be completely separate from production, and accounts shouldn’t have access to each other.
Lastly though this may not make sense for every company, some companies do have incredibly complex products that would be hard to offer a staging environment for. I recognize that I am making a generalization, and yes this isn’t necessarily something every product or company can and should do. Nevertheless, there are a lot of companies that could offer such a service and would greatly benefit from it.