APIs vs No-Code / Low-Code

A new corner named NCLC, appeared at this year edition of API Days Paris : a strange-squared place with developers speaking on how to avoid developing…  but why this and what is hidden behind this acronym?

We all know what an API is, i.e. an Application Programing Interface. We are all familiar with the purpose of an API, to help share a resource, data, a process with an easy and secured integration. Whatever the gain for developers to use APIs, API is still a programing way to benefit from an “external” resource. You need developers to integrate APIs. The big trend in development for several years has been code reuse like with APIs. You search a library, a SDK corresponding to the function you want to use, you integrate in your code, you adapt to your case and that’s it!

As the world is lazy and smart, tools for doing simpler have been created: the NCLC is born! NCLC stands for No-Code / Low-Code. In other words it means that you can create programs without dealing with a line of code, just manipulating some functional components in a graphical tool.

The same benefits as with API are expected: quick, easy and secured integration. The gain compared to coding is probably the simplicity and inclusivity of the solution: you don’t need to be a developer.

As described by Fabien Vermot, Make (ex. Integromat), the challenges with NCLC are to bring productivity and efficiency, develop business agility. The impact is also organizational on companies: the programs are produced by a diversity of employees, not only developers.

On the paper the trend NCLC seems to be amazing:  more people doing programs quicker and easier.

But what is the reality? What would be the future of NCLC regarding APIs?

• Already 25% of applications leverage on No-Code in 2020. The perspective is 70% of apps by 2025.
• No-Code meets automation and easy integration, linking builder (Glide, bubble, weweb…), database (Xano, Airtable, Baserow…) and orchestrator (Zapier, make, n8n…).
• No-Code meets in theory a simpler maintenance compared to code review and dependencies management.

However what is the reality of NCLC:

• The objective is not yet fully achieved in terms of inclusivity. Mainly developers are the users of these solutions – a presentation was done by Manon Mercier from HEC Innovation Center about “no-code and diversity”, showing the path for including non-developers is not a success yet.
• The compliance between NCLC solutions is a complex topic. Probably the customer stickiness to a solution and only one is the result of some juicy business for NCLC solutions.
• The richness of a solution is the number of components you can play with to create your apps. We can observe on the market of NCLC solutions that some are specialized in business domains. The consequence is probably that companies must use several solutions to cover all their needs.

source: Frederic Fontanet, UML and API Designer

To conclude we can say that the move to NCLC is in rapid progress. The two key successes will probably be the capacity to create bridges between solutions and to transfer components from one solution to the other (a standard could help… ), and secondly the ability of these solutions to give access to non-coders.

NCLC could have a quick impact on internal APIs within the same company, evacuating issues like security, identity, external contracts, but of course after re-organizing the company’s apps production.

NCLC solutions would probably later evolve to expose components, apps, APIs  similarly to an API marketplace.

But in the end do not forget that you can create a REST API with No-Code 😊