Thinking of a Domains API Future

I had a thrilling followup meeting today with Jim, Lauren, and Taylor to talk more about the potential of a Domains API and how we might use it. This is a concept that it feels like Jim and I have batted around every few years almost since the inception of Reclaim Hosting. In December of 2014 we brought Kin Lane to Fredericksburg to sit with us and map out conceptually what an API could look like for Reclaim Hosting's current and future offerings.

This was an exciting milestone for Jim and I not only because it was absolutely thrilling just a year and a half into Reclaim's existence to be able to pay a voice in the community to consult for us. But it was also exciting because even in 2014 we were playing with Docker and containers, thinking through APIs, and trying to understand what the future of hosting could be.

The API conversations would come up again at the annual University API Workshop put on by BYU that both Jim and I took the opportunity to attend several times. The work BYU has done with APIs for their community was always inspiring and we'd often find ourselves wanting to talk to them and the others at the conference about an API for Domain of One's Own.

There are so many other key points in the history of these discussions from our experiments with Sandstorm and Cloudron to discussions we've had with Zach Davis around potential future dashboards and applications for containerized hosting services. You'd think I'd be sick of it by now but for whatever reason I still get a lot of energy from this type of forward thinking, and when the team got together in Nashville in October of last year to thinking about goals for 2022 and beyond, I returned back to the idea and with the hiring of Taylor in an instructional technology role at Reclaim (a first of its kind), Jim and I agreed that it made a lot of sense to see if we could move it beyond just an idea and into a true proof of concept.

Conceptually my mind is all over the place and our first meeting in December was an attempt to just capture some of that. I had been playing with WordPress post types, thinking about the language of the API and how we might use more generic terms "Register Domain" or "Install Application" that then map on to particular services reducing our dependency on any one service or product when building any future application on top of this API. We took some time the past few weeks to start looking at the services we use and ensure that APIs were available and flexible enough to meet our needs. What I appreciate about Taylor is that he quickly wants to move from conceptual to practical and find the smallest viable product to move a project like this forward. I often need that because this stuff can be big and heavy and easily lose priority over the day to day. So we left the meeting today with him focusing on the frontend UI experience and what functions would be necessary to accomplish a basic signup process that includes installation of an application and potentially a domain choice. On my end I'll be looking at creating a basic version of the API that will translate those functions from their generic terms to the services we use. While I know ultimately making the API pluggable so that different services could be enabled like plugins to handle functions like domain registration or application installation, I'm focusing on hard coding things for what I need given I'm not a developer and this doesn't need to be done perfectly right now, it just needs to work and we can refine it from there (and truthfully it's not like we change domain registrars every few months or something, having it be pluggable would make it useful should we decide to make the software available for others to use).

This process has also pushed me to use Postman more, a service and application I've used on and off for years for basic testing of APIs but have started to see real value from for sharing collections across a team (and any company that is smart enough to scoop up Kin Lane as their lead evangelist is good people in my book). I hadn't realized until diving in today that Postman could also generate documentation based on collections you build, so I've been mapping out an architecture for the Domains API in there and documenting as I go which has proven to be awesome and should make Taylor's work easier as he can see the docs for the API calls he'll need to use in realtime as they update.

This was also an opportunity to flex a new service we've been working with: Cloudflare Teams for Zero Trust Access Control. I've used it to setup SSO internally for a few products of ours and this seemed a natural way to ensure only specific users on our team have access to the API for now and doing it via DNS with Cloudflare meant I could punt on figuring out an entire auth layer for the API itself and just secure the entire domain.

I'm looking forward to sharing more as this project develops and it helps ground me in ways that I can still play a role in the future of Reclaim Hosting which is exciting and stretches my mind in different ways from the work I do at the arcade every day.