I have been playing around with several iterations of what is next for the APIs.io search engine. I have a v2.0 of the search engine and supporting APIs.json index almost reading to replace the current live v1.0. It is all an experiment and work in progress when it comes to API discovery, but a mix of prototypes that eventually I will work to harden based upon usage and interest. Steve and I feel pretty confident that there is a huge need for a public API search engine, and working to fill that need with APIs, but a big part of the need for an API search will depend on what is available locally and on-premise for enterprises to use without any strings attached.
v2.0 of APIs.io is a simple Jekyll static site that will run on GitHub pages. It is an implementation that has plenty of constraints, but works well as a GitOps-driven approach that is YAML driven and has free hosting. Eventually my APIs.json Artisanal index will outgrow this approach and I will shard based upon some dimension. I am already looking to share the search engine based on the APIs that have OpenAPIs and those that don’t—-other bounded contexts will emerge in the future. My goal isn’t to provide a massively scalable monolithic solution. I am looking to be a massively scalable federated solution using APIs.json and API Commons as the engine, and APIs.io as the search. It is cheap, low budget, but also modular and requires minimal infrastructure investments to operate-—we will see how that plays out over time.
I am scaling up the infrastructure that will process my APIs.json Artisanal index and generate the explore edition of the APIs.io search engine, but the actual site itself is pretty static APIs.json, OpenAPI, and other artifacts rendered using Liquid and Jekyll running 100% on GitHub Pages. I will be also beefing up the APIs.io Search API to search based upon APIs, but also the tags, rules, and properties I’ve added to v2.0. However, I am working on putting a property in the configuration file for the APIs.io search engine that would allow for searching using the local static JSON index, or via the dynamic APIs.io Search API. On second thought, I’ll just build it into the interface, so users can choose what they want to search by, with the default being APis.io dynamic search. Regardless, allowing for localized search would make the API search engine self-contained.
Since v2.0 of APIs.io runs 100% on GitHub Pages, anyone can fork and run in their own GitHub organization in the cloud or on-premise. They can reverse engineer how we are using APIs.json to index APIs and begin adding their own APIs, as well as remove those they don’t want from the public index. Not everyone is a fan of Jekyll as a CMS, but since it is baked into GitHub, it provides a pretty rich way for distributing the APIs.io search engine with minimal development. Now that I have v2.0 of the search engine almost ready for publishing after some more cleanup, I can just do some work to expand the search, and document how you can fork and run via your own GitHub organization. Then see what people do. I will keep building in the features I need to power the APIs.io public search engine, but I can start iterating based upon feedback from on-premise users.
I will add a local search, and add the visible switch between cloud and local search. Then I will better document the new folder structure I have created, but I think I’ll incorporate some of the learnings I have uncovered while profiling leading APIs and evaluating how they use GitHub to manage their own OpenAPIs. I want this version of APis.io to federate using the includes property, and allow for easy navigation across multiple APis.io instances that are sharded based upon property or tag, and search to work in a federated way. You should never have more than say 2500 APIs or 2500 tags for any individual instance, and I’ll work on better defining the bounded contexts for sharing of Apis.io search engine instances. I envision there being individual API, team, as well as line of business editions, as well as partner or public GitHub implementations. What I am building is designed to be a team, line of business, or external partner and public API search indexes. I will work on a separate blueprint for individual APIs, which plug and play into the more aggregate editions.
I played around with a Backstage generator for APIs.json to easily generate Backstage YAMl from APIs.json indexes. This is work I’ll likely revisit soon, but I feel like a simple static and federated API solution is a little more interesting, and potentially game changing. We need an API search engine for public APIs — APis.io is working to fill this gap. We also need an API search engine for within the enterprise—maybe APIs.io can work to fill this gap. IDK. We will see. I don’t think API search needs to be 100% centralized like web search was. I think we have to be more creative when it comes to how we monetize APIs, than we were with the web. Federated using open specifications is the only hope, with acceptable and trusted service providers overlaying value across different stages of the API lifecycle. Alright, back to work on putting the switch for search from local to cloud, and get documenting the solution for forking and running on your own. Then, maybe in April I can swap out APis.io with v2.0, and let folks begin forking and running it locally—I am hoping people reverse engineer and begin to learn more about why APIs.json indexes are superior to anything we have today.
