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 Back-end or full-stack developer. Skills required: Build: medium to long. Deploy: long until you automate it. Time: Build: time and material for developer. Cost: depends on where you want to host it. You will need to do this yourself. Hosting: Use your favourite framework to do the heavy lifting Other comments: .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 Coding, understanding how APIs work, knowledge of the services offered by the IaaS platform and how they interact. Skills required: Build: medium to long. Deploy: fast. Time: Build: time and material for developer. Cost: depends on IaaS platform, usually pay for use. Hosting: 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. Other comments: 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. Have coded before or have a clear understanding of coding concepts. Skills required: Build: fast. Deploy: fast. Time: Low-code platform. Build: time and material for developer. Cost: Often included but depends on platform. Hosting: Low-code tools like or are good choices when time is of the essence or you do not have access to a back-end or full-stack development team. Other comments: Outsystems Linx This is a for the popular API developer tools defined by category and use case. BONUS RESOURCE: great site 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 further; you can make a case either way. low-code vs code 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.
