Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
APIs have an accessibility problem. Could a low-code API approach make them more inclusive and accessible for citizen developers?
Most software today integrates with third-party SaaS. TomTom for geolocation. Stripe for payment. Twilio for SMS. Kairos for facial recognition. AWS for NLP … the list goes on. Whatever function you’re looking for, there’s probably an API for that.
These specialized utilities help software teams avoid reinventing the wheel for things outside of their core competency. They’re standardized, too — most services are programmable following REST or GraphQL guidelines. Serving integrations over HTTP aids in decoupling the business logic from the client interface. Furthermore, OpenAPI Specification, now part of the Linux Foundation, has risen as a standard description format, making APIs more defined and interoperable.
However, for all this progress, there’s still friction in the integration process, even for seasoned developers. Each API is a bit unique. It takes time to read through the documentation to authenticate and discover methods, parameters and accepted fields. It requires effort to test requests within Postman, decipher error messages and set up calls within your unique environment. On top of all this, downtime and breaking changes are legitimate concerns for over-the-wire dependencies.
APIs require effort and maintenance, and just integrating third-party APIs alone won’t build you a fully functional application. Yet, organizations find themselves scrambling to find and hire engineers, and increasingly the onus is on non-tech folks to create new digital workflows. Naturally, companies are currently searching for even more low-code solutions.
So, what’s the glue holding together API products? How can we better connect APIs to the software applications we’re already building and allow citizen developers to reap the benefits?
My theory: If low-code platforms decrease the API integration hurdle, more problem-solvers can stitch together business utilities to create more advanced internal applications. Making third-party APIs more inclusive for citizen developers could boost the API economy at large and enable creative solutions to flourish throughout enterprises.
The Need for Low-Code API Integration
Perhaps the best way to demonstrate the need for low-code is to scare you with some code. Let’s say you want your application to initiate a direct deposit into a bank account.
You don’t want to build a financial service from scratch, so you turn to Stripe API. You set up an account, grab a key, and dig in to the ‘Getting Started’ materials. You peruse their comprehensive documentation, and find out how to create a payout.
The docs demonstrate a sample HTTP curl request for creating a payout. Other parameters to pass include destination, methodor source_type.
curl https://api.stripe.com/v1/payouts \
-u sk_test_4eC39HqLyjWDarjtT1zdp7dc: \
-d amount=1100 \
-d currency=usdIf there are no errors with the request, the response will be a payout object, formatted in structured JSON. It details the balance, data created, currency type and other fields. It looks something like this:
{
"id": "po_1HmNKQ2eZvKYlo2CuRNBRWUW",
"object": "payout",
"amount": 1100,
"arrival_date": 1605116514,
"automatic": true,
"balance_transaction": "txn_1032HU2eZvKYlo2CEPtcnUvl",
"created": 1605116514,
"currency": "usd",
"description": "STRIPE PAYOUT",
"destination": "ba_1HmNKQ2eZvKYlo2CzlT6m5gk",
"failure_balance_transaction": null,
"failure_code": null,
"failure_message": null,
"livemode": false,
"metadata": {},
"method": "standard",
"original_payout": null,
"reversed_by": null,
"source_type": "card",
"statement_descriptor": null,
"status": "in_transit",
"type": "bank_account"
}Now, you can parse the response into data your application can ingest. You can also send other requests to update, return and cancel this payout object.
For specialists familiar with HTTP calls and JSON, this is pretty straightforward. Stripe docs typically generate sample requests for many languages, like PHP, Ruby, Python and others to help within your own environment.
But what if your users are more comfortable with UIs? Integrations are pretty opaque to the non-technical. Even for seasoned developers, APIs can quickly become too dense, and not all have a great developer experience.
Hurdles In API Integration
There are many issues preventing non-tech-savvy users and novice programmers from inserting API-driven business logic into their applications:
- Onboarding time: Setting up an account, acquiring authentication, reading docs and testing calls to familiarize yourself all takes time.
- Data Types: Data passed in headers must conform to explicit data types, or else requests may fail.
- Parsing: Responses are often too verbose; developers must parse the JSON object responses to retrieve the data they need.
- Programming language: Each language handles network communication differently, meaning requests look different in every language.
- Breaking Change: Third-party services change often, so if you’re not actively maintaining an integration, you may face breaking change.
- Differing formats: There are various API standards. REST, SOAP, GraphQL all are designed a bit differently. Plus, webhooks, event-driven and publish-subscribe patterns have nuanced communication models.
- Security and legal: If APIs aren’t appropriately secured, hackers could easily steal user data or cause outages.
As you can see, a simple programming task like “make a bank deposit” becomes extremely complex the more closely we look at the logistics of actual implementation.
Furthermore, just because you’ve made an integration work, that doesn’t mean you have a fully-functional application, securely deployed in the cloud, with a friendly UI that’s universally accessible. A single application may have numerous integrations, meaning the integration process must be duplicated for every external service you connect.
API Categories
Overcoming these challenges is a lot to ask of non-professional developers, who may not be comfortable consuming business applications from the command line. This issue is further compounded as integration extends beyond public APIs, too.
In a recent interview with Divyesh Kharade, co-founder/CEO at DronaHQ, he identified three main API categories:
- Ready-made SaaS APIs: Microsoft Teams, Slack, Sendgrid, Twilio, Google Sheets, etc. These are the connections to third-party operational business utilities and applications.
- Connecting to databases: Many companies require secure connections with custom internal databases or legacy internal MySQL databases.
- Internal custom software: These are private or partner APIs. They may be new API-first microservices or custom-built legacy internal apps. Such middleware may expose many APIs.
If a low-code application wants to become a holistic software development add-on, it must anticipate all potential environments. This includes integration realities for various scenarios.
Citizen Developer vs. “Non-Tech”
So who, exactly, benefits from more accessible integrations? The term citizen developer is often used to refer to any non-professional software developer with minimal programming training. “When most people speak of citizen developers, they mean functional guys that can build tech,” says Kharade.
As I’ve said previously, fostering a culture of citizen developers is becoming a bigger priority amid dwindling developer talent and a combination of other forces impacting software development requirements.
Yet, citizen developer tends to means something a bit different to everyone involved in the low-code space. Kharade seems to prefer the term “non-tech.” Non-tech users may include designers who may not have a software background but the relevant UX/UI knowledge to assemble workflows. “Design is a big part of any application,” said Kharade.
Masking the Complexity of APIs
If low-code tools mask complexity and make APIs more accessible for these non-engineers, it could inspire many creative solutions. With low-code, “creativity is limitless, and integrations really help with that,” said Kharade. “Once they see that power, they aren’t going back again.”
For example, if an internal application requires chat functionality, Slack could be a great addition. Low-code layers could hide complexity in the backend, to the point that it “doesn’t feel like a request in background,” noted Kharade.
The solution works both ways. Utilizing low-code platforms to manage data and expose APIs could enhance visibility and extensibility. Kharade described an industrial manufacturing use case, in which shift workers manually entered machine operations data on paper. That was before COVID; once lockdowns were mandated, the company started digitizing this record-keeping process.
Access to real-time data, and the ability to filter and organize historical data, is already beneficial. “Six months down the line, they may consider how to make this data accessible using APIs,” said Kharade. “The journey has just started — it will only get smarter and better.”
Trigger-Based Workarounds Were A Start
Of course, tools like IFTTT and Zapier have already been making APIs accessible to laymen for years. These platforms use friendly, UI-based front ends over the foundation of complex integrations, allowing users to set up trigger-based automation. If this particular service does this, this other service should do that.
These are cool tools for stitching together service-service communications. However, these workflows are a bit isolated from the larger application development picture. For example, an application for hiring employees may require more than connecting a form API’s input to a Google Sheets field. This could require a custom database, a way to upload documents and the ability to deploy an application to the cloud.
Since low-code already has standard components for drag-and-drop, adding a common method to insert third-party API integrations feels like a natural feature enhancement for these platforms.
Making Integration More Accessible
ProgrammableWeb records 23,000 APIs as of this moment. Clearly, many innovative, programmable SaaS offerings are ripe for the picking. Some paid, some open, all with slightly different integrations.
“It’s difficult for a non-tech user to register and interact with an API,” said Kharade. Figuring out authentication, OAuth, headers, payloads and responses requires expertise. Though a professional developer may be required to “register them once,” says Kharade, once third party integrations are set up, they “should be drag-and-drop and click-to-use.”
Solving integration problems is just one of the many arenas where low-code platforms could shine. If platforms can successfully establish (and maintain) connectivity, consumers could more easily access the core logic they are searching for. Democratizing robust solutions for traditionally non-tech companies is especially important amid the COVID-19 crisis.
To be clear, I don’t believe it’s the API provider’s job to cater to end-users. Instead, they should focus on creating excellent developer experiences. Naturally, the type of business application you are trying to construct and your access to software engineering talent will, to an extent, determine a project’s technical stack. The JAMstack style, for example, may be a better fit for your team’s makeup and project objectives.
That said, there seems to be room in the market for additional low-code layers to open up integration. In the same way APIs avoid reinventing the wheel for specialized utilities, low-code layers could standardize the pains of integration itself.
