Engineers are experts at finding ways to streamline complex technical tasks. We can spin up a relational database or allocate more nodes in a cluster with the click of a button in a web console, or scale infrastructure in and out via cloud providersʼ auto-scale capabilities. But what about APIs?
Thereʼs an understated art to building good APIs—ones that are easy to integrate with from a client perspective, that are operationally highly available, that offer readily attainable tracing and performance insights, and are easy to maintain. If a platform or tool allowed you to substantially reduce engineering time and dollars spent and still produce a high-quality API, would you use it?
Essentially—and perhaps intuitively—“low code” means creating services and applications using very little, if any, code. The goal is to build highly customizable software for humans, while remaining agnostic to the skill set of the human working on it. Low-code platforms also make it possible to plug in your own code.
Some of the most common use cases for integrating with low-code and no-code platforms are for small businesses and personal projects, typically to automate repetitive tasks like uploading data from a CSV file, triggering actions based on events in a calendar, or creating a workflow to replace the sign-up process for new customer onboarding. For example, instead of having an engineer write a Slack plug-in that sends a message to the team when something gets added to Google Calendar, you can automate that workflow with a low-code platform like Zapier.
The industry has a history of offering these low- and no-code solutions to accomplish certain, sometimes cumbersome, aspects of software development. It’s nothing new—consider Dreamweaver, developed in the late 1990s to allow both developers and non-developers to create websites without prior knowledge of HTML or CSS. Today, platforms like Squarespace and WordPress offer website curation and hosting without requiring the user to have any software development skills.
Another, similar example is the widespread use of data visualization software like Tableau and Looker (with Tableau gaining popularity as far back as 2013). Most organizations are not creating applications that host analytics or metrics dashboards from scratch. Instead, they opt for solutions like these, which allow anyone to create metrics charts and dashboards with precious little code written by their engineering teams, save for the initial engineering work to make the companyʼs data available to these tools.
Thereʼs clearly an opportunity for low-code services to reduce the time spent on API integrations, allowing developers to work on other aspects of your platform—if a solution exists and has proven better than reinventing the wheel, engineers will use it.
A plethora of low-code solutions
There are a few heavy hitters in this space, each providing varying degrees of flexibility, ease of integration, and pre-developed plug-ins. I’ll focus on two of the most popular, IFTTT and Zapier, as they are similar in functionality but vary in complexity and usability from an onboarding perspective.
IFTTT is one of the simpler platforms when it comes to workflow and onboarding. This low-code service allows users to set parameters for “if this then that” behaviors and offers a somewhat drag-and-drop solution. Premade applets, or small programs, can be triggered in response to an action, at which point they execute specific, predefined tasks. More specifically, applets can be triggered by changes that occur within another web service. For example, a business working to expand its social media reach could use a premade IFTTT applet to share social media posts across channels. Using IFTTT means developers don’t have to write integration code between their service and other backend web services’ APIs. The platform has hundreds of preexisting applets that are integrated with popular brands such as Ring and Wyze, but if none fits your use case you can create your own, so long as the app you’d like to integrate with already has a hook into the IFTTT platform.
Another popular platform with similar capabilities but more customization options is Zapier. Zapier supports somewhat more complex applications, as you can have multistep workflows that trigger a sequence of actions based on predefined logic. Zapier leans heavily toward business-oriented applications and is arguably harder to master than IFTTT. It’s perhaps best known for its integration with Google’s G Suite, which, for example, makes it possible to send customized emails via Gmail when a Google Sheets row is updated.
For simple use cases, low-code platforms like IFTTT and Zapier offer obvious advantages, such as quick integration and the ability for non-developers to build solutions without prior engineering experience. But what happens when you want to build something the low-code platform hasn’t already conceptualized, or when your product requirements become more complex than the low-code platform can support? Or what if A/B testing is important for evaluating your product? How you integrate with a backend service can impact how you enable A/B testing and logging of customer engagement events.
Low-code APIs for prototyping
In 2011, when I was a young, greener-than-green engineer, my then-manager asked me to develop a web application using the Liferay portal. I understood why we had gone that route: Liferay had out-of-the-box LDAP integration, roles and users were seamlessly available for admins, and preexisting artifacts like the portal container sped up the time to production. But after months of working on the portal platform and building portlets that adhered to the JSR-286 specification, working with the platform became less than ideal. As Eric Spiegelberg explained in his article “JSR-286: The Edge of Irrelevance,” if you need to develop any kind of customization for your portlets, the portal architecture won’t be a good fit. The minute we had to build something that couldn’t easily integrate with portlet semantics, we found ourselves wishing we’d built a simple web app instead.
Portals and portlets are not the same as low-code or no-code services, but the similarities are worth examining because they’re both a means of quickly developing applications without having to build the end-to-end architecture. My team’s project eventually matured beyond Liferay; we built the next iteration from scratch, bringing more developers onto the team and using Angular as the JavaScript framework, Bootstrap as the CSS library, and Spring Boot as the backend framework.
Though we didn’t use it for long, Liferay allowed us to quickly demonstrate the application’s viability while we had just one engineer working on the project (yours truly!). From a product perspective, we confirmed the need for a minimal CMS-like application to allow the business to curate promotional rows for the content discovery experience in our TV-viewing platform. And once we knew it was a piece of software we wanted to invest in, we prioritized customization and overall developer happiness. (Many developers would rather not contribute to a platform that uses the portal architecture because it’s not something typical employers look for when recruiting. As Eric Spiegelberg wrote, “portal architecture will continue its well-established decline toward [and eventually over the edge of] irrelevance.”)
On the flip side, what if we’d started the project by spending a few more months building the application from scratch, then realized the product wasn’t what the business needed? Perhaps the most disappointing experience as an engineer is when you discover you’ve spent 10 months building a feature customers just don’t use. Low-code solutions can provide a salve for that disappointment, and an antidote to that wasted time, by making it possible to prototype a feature with little to no engineering effort and evaluate its reception before your organization invests too heavily in building the real, ideal feature.
The future of low- and no-code solutions
For most developers, writing integration code sucks, as it cuts into time that could be spent actually building your product. It’s a matter of preference, sure, but few find it truly interesting to write code that parses a downstream service’s API or handles the authentication to that downstream API. It might be more interesting, for example, to calculate the volume at which you’ll make requests to that downstream API so your connection pools are accurately configured, or to do things like capacity planning to ensure your platform can handle the load of integrating your new feature into the product. There will always be more problems to solve, and therefore arguably more interesting code to write.
This paradigm appears not only in low-code platforms but also in how we build and architect software platforms in general. We now write less repetitive boilerplate code, and opt for utilizing tools and frameworks that are more configuration-like. For example, building infrastructure to host your software or manage networking details such as DNS can be almost entirely managed via HashiCorp’s Terraform, which consists of configuration files that represent the state of your platform detached from your software application’s codebase. Compare this to alternative solutions prior to the advent of tools like Terraform that consisted of manually managing scripts that were often copied from one project to another but slightly tweaked to fit a different use case.
Similarly, one of the leading web service frameworks, Spring, has conventions that abstract programming concepts into XML files, which, after a certain point, feels a little like configuration. (In place of writing lines of verbose Java code, Spring enables the instantiation or creation of objects via configuration in an XML file.)
Both Spring and Terraform are widely used in our industry because they’re flexible, easy to get started with, and can extend to many use cases and platforms. And the less time engineers need to sink into complicated and increasingly unnecessary from-scratch infrastructure processes, the more time they can spend getting their product holistically right.
If low-code solutions for API integration come to replace writing authentication code, parsing logic, and the other (dare I say) mundane aspects of writing code that integrates with an external service, I’d venture the time saved could be transformative. We may well see an increase in developer productivity and developer happiness as engineers spend more time solving harder and potentially more interesting problems.
Who knows what the future will hold, but I’m intrigued by the possibility that low-code services will evolve beyond their use in personal websites and small businesses, offering opportunities for developers and teams to commit more time and heart to the parts of their projects they’re most passionate about.