Low Code & No Code API Solutions - Are they Right for You?
Explore the practicality and trade-offs of no/low code APIs, including tooling and categories, for efficient API development, including: Strapi, Contentful, Sanity, AWS Amplify, DreamFactory, Firebase, Airtable, Zapier, Make, and Pipedream.
Recently I introduced the idea of using low/no code solutions to avoid designing/building APIs, highlighting the practicality and trade-offs of these approaches. This article is going to dig into that concept a little more, and explore the different categories and showing off some of the tooling available.
API developers are a funny category. Are you a standard software developer who sometimes build monolithic backend applications which might spit out HTML or JSON? Are you a Full Stack developer who builds an API to communicate data from your database to your frontend? Are you a DevOps person who dabbles with a bit of code.
Your API needs to live somewhere, and it has to be built somehow, but those different groups all have different needs and motivations. The full-stack devs might not want to spend ages building that backend, and the software developers might not want to get stuck into infrastructure setup. If you're anything like me you'll get a migraine just thinking about spinning Amazon Web Services up, and if I don't have a team with me for a project I'm probably looking for alternatives.
What options are there apart from "do everything yourself"? No code and low code are two brilliant emerging categories which are helping API teams, taking over various amounts of the infra/config/functionality, and letting you either click your way to a functioning application, or write a little bit of code to help out without needing to write everything.
This is a long article, so feel free to hop about to the bit you're most interested in.
No Code APIs
There's a few different types of No Code API, from the simple headless content management system, to "Mega Spreadsheets" like Airtable which do absolutely everything you could ever think of.
No Code Headless CMSs
Content Management Systems used to be the king of the Internet. They still power 64% of the internet, but it felt like everything outside of major corporations started by installing a CMS. In many ways that was a much simpler time. You would install a CMS on your server, and it would give you Blogs and Pages. Eventually everything because a Page or Entity with custom data making them even more powerful.
It was only a matter of time until these CMSs started adding HTTP/REST APIs for that custom data so you could do whatever you wanted with the data. Users would disable the default server-side generated frontends, and build entirely custom interactive frontends with JavaScript. This happened enough that some CMSs ditched their server-side frontend altogether, and exposed data purely over the API.
Content management systems that focus on providing an API are known as "Headless CMSs" and they come in all shapes and sizes, with some supporting REST, some supporting GraphQL, and some support both.
Let's take a look at some no code headless CMSs that you can use to create an API and backend with minimal setup.
Strapi
Strapi is one of the most popular headless CMS around. This beautiful CMS comes in open-source or enterprise flavours. You can host it yourself, or host it on Strapi Cloud if you really don't want to handle the hassle of hosting/configuring the code, database, email provider, and CDN.
Everything is a Content Type. Build collections and single types. Pick all the fields, and it will build everything up for you. Unlike some similar systems, instead of everything being purely configured by the database, it will build a bunch of code for you in the filesystem, giving you the opportunity to edit and customize that if you like. This could put Strapi in the low-code camp, but I've left it here as it's optional.
- API: REST & GraphQL
- Webhooks: ✅
- Self hosted: ✅
- Cloud hosted: ✅
- Database Support: PostgreSQL, MongoDB, SQLite, MySQL & MariaDB
Contentful
The focus for Contentful is clearly completely on developing your content, and not having to worry about where it's going or what it's doing. They have developed infinite integrations and extensions, so you can link it up to popular web frameworks to build out a frontend with minimal effort. If that's no good you can use their Content Delivery API or GraphQL Content API to build your own integration, which is especially helpful if that content needs to go somewhere more complicated than onto something like a Gatsby site.
Define content types, create entries, assign tags and relationships, and build up everything you need without having to write any code.
- API: REST & GraphQL
- Webhooks: ✅
- Self hosted: ❌
- Cloud hosted: ✅
- Database Support: ❌ (It's cloud hosted and they do not permit connections to their database)
Sanity
Sanity is apparently not a headless CMS, it's a "Composable Content Cloud", which walks and quacks a lot lot a headless CMS. Whatever, people come up with fancy marketing terms all the time. When I was building a headless CMS there was a whole phase of calling them Content Management Frameworks, then the even fancier people called it a Content Management Platform... it's all the same thing.
Use the open-source Sanity Studio tool to structure your content, then all the data lives in a Content Lake which is accessible via various types of API. It's got loads of CLI helpers and image management logic, asset libraries, etc. and can take care of a lot of boring nonsense for you.
- API: REST, GraphQL, and GROQ
- Webhooks: ✅
- Self hosted: ❌ (you can host the studio but not the API/data)
- Cloud hosted: ✅
- Database Support: ❌
Do You Need Database Access to a Headless CMS?
Most cloud hosted headless CMSs will not let you access the database directly, and will have you read from the content API, and manage content through the interface or some other content management API.
Self hosted headless CMSs will need you to host the database yourself, so you do get access, but the list of database engines they support might not include your favourite. Even if your database platform of choice is included, the CMS will tightly control how that data is structured.
This might be absolutely fine, for two reasons:
- Maybe you don't care how your data is stored. You aren't a database admin, and don't want to have to think about the pros and cons of normalizing to the nth degree. You can assume this CMS has probably set it up to work in a sensible way, and deferring control to them is one less headache.
- Maybe you can just connect to the DB directly to do particularly complicated things like sweeping up loads of data for crunching stats, data warehousing, syncing to another system, or building a partner API later.
So long as the API the CMS produces is usable (or you can configure it to be useable), a headless CMS can get you a long way with minimum effort, especially if it is just making some CRUD content for use elsewhere.
No Code Application Platforms
Another approach to building no code APIs is to use a hosted solution like Airtable. In the previous article in the no/low code series I wrote more about how Protect Earth used Airtable to build our "Tree Tracker", saving us a huge amount of time, and money we did not have.
Airtable can handle creation of tables, which have all the common fields you would expect: string, dates, numbers, ranges, emails, images, relationships, etc. Then with no code you can configure views, like grid view for images, table views for data, and user facing views allowing you to generate data entry forms to gather more data. This is really helpful, but fundamentally Airtable positions itself as an "application builder", that just so happens to have an API.
The Airtable API is not particularly beautiful, but it let our iOS developer upload trees planted from the field, and upload images easily. We needed a little bit more flexibility on the JSON output and there was no ability for us to customize it, but as with most of these APIs you can simply code a thin proxy API which pulls in data from the main API, then smushes the JSON around a bit, and puts it out in whatever format you like.
It's entirely cloud hosted and there's no access to the data other than through the API, so complex queries are not possible. You'll need to sync the data down, which is cumbersome and frustrating, then query that data, making it no code for some, but code heavy for more advanced use cases, and may only be a matter of time until you switch away. Maybe that's ok, but you'll need to be thinking of an exit strategy when you start using it or you might get stuck.
- API: REST only
- Webhooks: ✅
- Self hosted: ❌
- Cloud hosted: ✅
- Database Support: ❌
There are other cloud platforms like Notion (which I use extensively for project management, knowledge bases, etc but it's not quite so good at this sort of use case).
If you'd prefer a self-hosted open-source Airtable clones, there are loads:
Some folks will love these sorts of tools, but the more techie you are the more likely you are to want some code involved, which takes us onto the next category: Low Code.
Low Code APIs
What about low-code? There are a few low code headless CMSs around which provide all the functionality of the no code headless CMSs but with a bit more configuration required. We've talked enough about this type of tool so I'll just list a few off you should check out:
- CraftCMS is a popular PHP-based headless CMS that you can self-host and extend, that lets you get a whole load of work done without writing any code. It offers GraphQL out of the box, but does not have REST out of the box.
- Payload CMS - A free and open-source dev-first TypeScript headless CMS.
Where the low code API world really gets interesting is a whole category of tools that are an interesting balance between application builder and configurable API-centric infrastructure.
AWS Amplify
Most software engineers will have come across Amazon Web Services at some point, and it can be a huge headache to work with. People will shout "it's simple!" but they're people who have spent enough time grinding through it all to become an infrastructure person, and everyone else will shuffle around making expensive mistakes and misconfiguring security holes in everything.
AWS Amplify aims to rectify that situation, helping beginners build full-stack apps, and mobile apps, but for this audience the most interesting part is the ability to create scalable and secure APIs. Using a GUI you can set up databases, file storage, authentication, authorization, and continuous deployments. This eliminates the need for manual configuration and reduces the risk of security vulnerabilities, ensuring that the APIs are robust and reliable.
Amplify also offers a wide range of prebuilt components and integrations, making it easier for developers to add functionality to their APIs. These components include features like real-time data synchronization, user management, file storage, and more, most of it being powered by extensible services like Amazon S3, AuraDB, etc. under the hood. By leveraging these prebuilt components, developers can save time and effort, as they don't have to build all this out from scratch, or glue a bunch of stuff together.
The API logic in Amplify is powered by another AWS service called AppSync, which helps you spin up APIs with a single command.
amplify init
amplify add api
From there you just define some GraphQL Types and you've got a GraphQL API. If you want REST then you're out of luck, but if this is only being used by your frontend or some internal clients that might not be an issue.
Unlike tools like Airtable, you've got a much better escape hatch here, because you could blow away all of the frontend logic and API logic, and all of your data is still sat in a perfectly useful hosted database that you could connect to from any other server where your new API runs.
DreamFactory
I really like the idea of DreamFactory, which takes the opposite approach from most of the other tools we've been talking about.
Instead of helping you define a bunch of content types, making you a database and helping you hook it all up together with content types and modeling done just to create the database structure, DreamFactory does the opposite.
DreamFactory is a hosted API platform that makes the assumption you've already got a database full of data. When you sign up you point it are your database, then you can expose that via a REST API to another team as an internal/private API, without needing to grow an entire API/infrastructure team to be responsible for all the complexity of designing and building an API, handling authentication, authorization, deployments, setting up an API gateway, email, push notifications, and even generates API documentation. You just get all of that out of the box.
DreamFactory sits in the low code camp, because whilst it does all this for you, it's not just a dumb data-in/data-out system, it lets you run attach Javascript, PHP, and Python, to handle whatever business logic or other transportation you need. This sets it apart from other "database as an API" tools and platforms, because vomiting out an entire database as an API is rarely useful. You want to control what data is output, and how, and evolve that over time, which DreamFactory will let you do with code.
DreamFactory also easily has the largest database support out of any of the tools we've talked about so far. You can hook it up to MySQL, SQL Server, Oracle, PostgreSQL, MongoDB, and IBM DB2, SQLite, memSQL, Snowflake, CosmosDB, CouchDB, DynamoDB, Cassandra, RedShift, Firebird, SAP SQL Anywhere, Alloy DB, Maria DB, Azure DocumentDB, and some other databases I've never even heard of.
Setting it up was incredibly easy, and with a few clicks I had connected to a test database, had an API key, and was making calls to my data via curl.
$ curl -X GET "https://greenturtle.apps.dreamfactory.com/api/v2/phils-test-db/_table/departments/" -H "accept: application/json" -H "X-DreamFactory-Api-Key: <token>" | jq .
{
"resource": [
{
"dept_no": "d009",
"dept_name": "Customer Service"
},
{
"dept_no": "d005",
"dept_name": "Development"
},
{
"dept_no": "d002",
"dept_name": "Finance"
},
{
"dept_no": "d003",
"dept_name": "Human Resources"
},
I'm pretty sure with a few more clicks I could have pointed this up to the Protect Earth database hosted on AWS with a SSH Jumpbox, but I'm over 2,000 words in and there's one more tool to talk about.
Google Firebase
Google Firebase is another powerful platform that lets developers focus on building the core functionality of their APIs, while leaving the infrastructure and backend management to the platform.
One of the key features is Firebase Cloud Functions, which allows developers to write serverless functions that can be triggered by events or HTTP requests, eliminating the need to set up and manage traditional server infrastructure.
Those functions can then be secured with Firebase Authentication, with a variety of authentication methods, including email/password, social media logins, OAuth 2.0, and OpenID Connect.
Seeing as this is another "Toolbox that can do a million things" it can initially be a bit confusing as to how and what you're meant to do, but Geekflare have written an excellent tutorial that takes you through building an API with Google Firebase. The API you build can be REST, but if you want GraphQL you'll have to build a wrapper.
For database storage you've got Firebase Realtime Database and Cloud Firestore, two NoSQL databases that provide real-time synchronization and offline capabilities. This makes you a bit more tied to Firebase for your data storage, which is less flexible than DreamFactory, and is slightly less helpful than AWS which has hosted MySQL databases, but it's a good enough escape hatch if you compare it to the cloud hosted headless CMSs or platforms like Airtable.
Honorable mentions
Tools which would have been mentioned in here if I wasn't running out of time:
Automations
We've not had a huge amount of space to talk about Automations, but all of these tools come with a whole load of extension points. You can either write webhooks to trigger events on other systems via HTTP calls, or link them up with Zapier, Pipedream, Make, or other similar tools, so you don't need to worry about not being able to control the code entirely, just glue stuff together.
Summary
There will always be the developers who want to build literally everything completely from scratch, but thankfully those developers aren't usually the ones making business decisions, because nothing would ever get done.
For public APIs being presented to end users, you might want to have full control over everything, and that makes perfect sense. Headless CMSs have made breaking changes to their API layers in new versions of the API, and you don't want that sort of implementation detail being leaked out to important client integrations.
For internal and private APIs there will likely be very different requirements. Sometimes your team want to rapidly iterate on an idea without a huge amount of funding and an infinite amount of time to work on it. Maybe you just need to get data from one place to another, another department, a partner who needs rapid integration, or want to validate an idea before massively investing in it.
API Design First is still absolutely amazing, and seeing as some of these tools support OpenAPI you can actually combine the approaches. Low code and no code are not the opposite of design first, they are the opposite or writing all the code yourself. You can use the design first mindset to plan an amazing API, then build that API with these tools instead of writing all the code.
Ideally you can be familiar enough with these various approaches that you can recommend the most appropriate one, especially when it seems like your team is about to rush into something that is going to cause problems. If you pizza when you wanna french fry, you're gonna have a bad time.
