API Choice Overload

There are several ways to create an API. Which one you pick will depend on the skills you have available to you, the feature set you need to support, time and budget.

Here are some broad guidelines:

1. Code it using your favourite programming language

Skills required: Back-end or full-stack developer.

Time: Build: medium to long. Deploy: long until you automate it.

Cost: Build: time and material for developer.

Hosting: depends on where you want to host it. You will need to do this yourself.

Other comments: Use your favourite framework to do the heavy lifting

• .Net: ASP.NET: Open-source web framework for .NET
• Java: Spring
• JavaScript: Express
• Python: Django
• Ruby: Rails
• PHP: Laravel

2. Code and configure it on your favourite IaaS platform

Skills required: Coding, understanding how APIs work, knowledge of the services offered by the IaaS platform and how they interact.

Time: Build: medium to long. Deploy: fast.

Cost: Build: time and material for developer.

Hosting: depends on IaaS platform, usually pay for use.

Other comments: The basic building blocks of this type of solution are serverless functions like AWS Lambda or Azure Functions running behind their API management services. You might experience some limitations, especially when requiring integration with systems or data not running on the platform. A good explanation of this kind of architecture can be found at Serverless Architectures.

3. “Code” and configure it on your favourite low-code platform

In theory, low-code tools should allow for faster development of systems using skills that are more readily available at the cost of the tooling and the risk of the project failing due to tooling constraints.

Skills required: Have coded before or have a clear understanding of coding concepts.

Time: Build: fast. Deploy: fast.

Cost: Low-code platform. Build: time and material for developer.

Hosting: Often included but depends on platform.

Other comments: Low-code tools like Outsystems or Linx are good choices when time is of the essence or you do not have access to a back-end or full-stack development team.

BONUS RESOURCE: This is a great site for the popular API developer tools defined by category and use case.

Are you still thinking about code?

Since the software world is always evolving - but then the basics are still the same - selecting the best option is often the hardest choice. There are templates, components, frameworks, hybrid apps— and many other elements to consider.

Breaking down the case for low-code vs code further; you can make a case either way.

DEVELOPMENT

1. Requirements and Design

A design might be constrained by what the low-code tool can do but this can have both a positive and negative effect on the time spent on this stage.

Best value: Draw

2. Build

Low-code tools generally use bigger building blocks and commodity aspects like logging and metrics are usually included, all of which are major time savers. However, if functionality is missing or cannot be built with the low-code tooling then additional cost will be incurred on building workarounds.

Best value: Low-code

Risks: Cost of workarounds

3. Deploy

Low-code platforms make deployment much easier than the complex and fragmented options for traditional coders.

Best value: Low-code

4. Testing

Systems built with low-code platforms need no or very little unit testing as their building blocks have already been tested. All systems, whether low-code or traditional, need end-to-end system tests.

Best value: Low-code

Overall Score:

Best value: Low-code

Risks: Cost of workarounds

INFASTRUCTURE

With most low-code tools infrastructure costs are linked with the cost of the tool. Systems built with traditional coding can be deployed on the most cost-effective infrastructure.

Best value: Traditional coding

MAINTENANCE

The cost of maintenance follows a similar pattern to the cost of development. An additional risk is the continued support and maintenance of the low-code platform, something you are completely in control of when using traditional coding. On the other hand, low-code platform and infrastructure upgrades should take less or no time compared to doing it with traditional tools.

Best value: Low-code

Risks: Cost of workarounds, continued platform support

Considerations

While low-code seems to be a no-brainer barring the cost of the tool itself there are too many variables and risks to consider to just decide that low-code is the answer. Each project will need its own business case based on the

• Type and complexity of the system to be built.
• Skills available and cost of those skills.
• Suitable low-code tools available and cost of the tools.
• Value of time-saving vs. the risk of project failure due to tooling.

Fit for Choice

Good use cases for low-code tools are when the project is not super complex, your tool fits the system domain and:

• you don’t have professional developers specializing in the tech stack you need, or,
• time is of the essence, or,
• requirements are fluid and will likely result in several iterations before going live.

The sweet spot is when you have domain experts with coding skills, even if they’re not pro developers, using a tool compatible with the target domain.