Noodle.ai’s Manufacturing Application Platform: An API-First Strategy
This blog is co-authored by Arijit Saha
Noodle.ai’s enterprise artificial intelligence® (AI) products are profoundly improving how the world makes and moves things — from factory floors, distribution centers, and retail stores to most everything else in between.
Our Manufacturing Application Platform enables the ease of data integration, collection, and management, and is purpose-built for AI and machine learning (ML) workloads that power the Noodle.ai Vulcan Manufacturing AI Suite. By combining the sheer scale and fidelity of industrial production data with the speed and flexibility of business systems, the Platform makes the entire enterprise L0–L4 data pyramid accessible.
One of the key components of the platform is the Application Programming Interface (API) portal, which provides a RESTful interface for all routines used in the platform. It follows OpenAPI Specification and uses Swagger as the API documentation interface.
What is an API-first strategy?
In an API-first strategy, the primary goal is to design and develop an API before the implementation of other software components like: web user interfaces, visualization dashboards, mobile clients, various microservices, etc. Often the API-first design and API-first development are referred to separately. In this article when we refer to an API-first strategy, we mean both the design and development.
Some of the other popular strategies are web-first or mobile-first strategies. In this approach, whenever there is a requirement of an integration with internal or external application, the API is developed as a separate channel; which is the case here. The challenge with this approach is that not only do two separate replicas of services need to be developed, maintained, and tested, there is also a chance that this API doesn’t satisfy all the optimizations during design and development.
The API-first strategy follows a contract-first development pattern which, in turn, helps optimize the development speed by enabling development in parallel.
When creating the platform, the teams dependent on each other (backend, front-end, and testing) independently made progress on the basis of a mutually agreed upon API contract. During the time when the backend team developed the services, the front-end team continued development with mock APIs. Similarly, the Quality Assurance (QA) team framed the test cases and prepared the automation testing scripts using a mock API.
In an API-first approach, gathering feedback at an early stage and iterating the design in an agile manner becomes much easier. When using mocks or API development environments, it’s easier to make the platform interactions accessible to developers, product managers, even sales and marketing. With API as the control plane, it’s much easier to plan the development & integration of a wide variety of end user interfaces like: Data Science Workbench or Notebooks, SQL Editors, Visualization Tools, Command Line Interfaces, Custom UI, etc.
Noodle.ai has a number of business applications in the Vulcan Manufacturing AI Suite. There’s a high degree of overlap in terms of the engineering functionalities. The API portal provides an interface to discover services used across different product modules.
Let’s take a simple example: one of the engineering components used across different product modules is the Data Connector. The Data Connector helps by ingesting data from customer data stores – on-premise and/or cloud databases, sensor data historians, file systems, etc. In the API-first world, it becomes extremely easy to reuse the ingestion component across multiple applications; it aids in avoiding human hand-offs as the teams are already aware of the request (payload) and response pattern.
This also helps enable the integration of third-party applications and dashboards, with the output of Noodle.ai’s predictive engine and helps in transitioning AI/ML applications in enterprise user workflows.
While the API-first approach sounds wonderful, it may not be easy to fully separate the interface design and development from the software implementation up-front, especially for large scale systems. Here’s some of what we learned from our experiences with API-first approach that will hopefully help others to embrace it when appropriate:
- Iterative Development Mode: Planning is fine, but planning can never supersede reality. So, instead of getting into “analysis paralysis” the team published the first version of the API using OpenAPI Specification and continued iterating based on incremental changes.
- Early Feedback: OpenAPI became a medium to communicate to producers and consumers and gather early feedback.
- Design Consistency: When there is a mesh of services maintaining a common design, it’s important to maintain a consistent pattern across the different services.
The team tried to maintain a consistent pattern in terms of API endpoint and payload.
The components developed today as part of any organization will be communicating with each other, if not today, then definitely in future. All applications are just enabling services which, if designed API-first, the system becomes agile, scalable, and can easily onboard new customers of existing services without having to stop the world to reconstruct yet another closed and monolithic system. As future changes and technology continue to evolve, designing APIs to support product journeys will improve the experience of services we offer.