How API Connectors Work

What is an Application Programming interface? It's exactly what it says - an interface between two application programs, a piece of software that allows different apps to communicate with each other. In the same way that you use the black box pieces of code on a no-code platform to build an app, your app can use an API to create a connection to another application like Stripe or Facebook and exchange information with that service. The API itself is simply a piece of software installed on the server you want to access. 

When the two computers connect or "integrate" via the API, they have to agree on the set of rules (or "protocol") they're going to use to communicate with each other (similar to two people deciding what language to use to carry on a conversation). Since Hyper-Text Transfer Protocol (HTTP) is the most common protocol on the Internet, many APIs use it as their communication protocol.

Once a connection is established, the client (your app) sends a request to the other computer (the server) and receives one of three responses (an acknowledgment that the request was handled successfully, an error message explaining that the request failed, or the data requested by your app). The request sent by your app is made up of four parts:

• A URL that provides the location you want to connect to on the server. The URL itself consists of three parts:
• The address of the server (www.youtube.com).
• The specific location you want to reach on the server (/results).
• The query string parameters (?search_query=bubble.io).
• The HTTP method:
• GET request - Asks the server to retrieve a resource (a webpage, product, image, etc.).
• PUT request - Asks the server to update a resource (change the address in a customer record for example).
• POST request - Asks the server to create a new resource (e.g. create a new customer record with the data in the body of the request).
• DELETE request - Asks the server to remove a resource (e.g. delete an inactive customer record).
• Header records: Additional information to pass on to the server, such as the time of the request, the request authorization, type of content, and response cookies. 
• The Body: The body of an API request contains the data that your app wants to send to the server and that data has to follow a specific format that the server can understand. A typical API connector encodes the data in a text-based format called JSON (JavaScript Object Notation). Here's an example of data in JSON format:  { “First name”:”Gary”, "Last name":"Morrison", ”Company”:”Global Imports”, "Email": "GaryM@global.com", “Primary contact”:true}.

Most servers require you to send a unique authorization code (referred to as an "API-Key") that identifies you to the server. The third-party service will issue you an API-key (normally a long string of random-looking characters) when you sign up. There are several ways that an HTTP API-key can be included in your request:

• As part of a query string in the URL (?something+API-key). 
• In an HTTP header record.
• A user name and password (which act as the API-key) can be sent as part of each request.

Once the server receives a request it will try to fulfill it, then it will send a response back to the client. Similar to a request, an HTTP response has three parts: a 3-digit status code, headers, and a body. 

Status codes indicate whether the request was handled successfully or not. Common status codes include:

• 200 - Request succeeded.
• 404 - The requested resource doesn't exist.
• 503 - Website is currently unavailable.

There are actually five classes of response:

• 1xx - Request received, continuing to process.
• 2xx - Success (requested data delivered or requested action completed).
• 3xx - Redirection (additional processing needed to complete the request).
• 4xx - Client errors; the request isn't correctly structured or can't be fulfilled.
• 5xx - Server errors; the server failed to handle the request correctly.

Once the response is delivered, that round of the request/response cycle is complete. Any further interaction through the API is up to the client. 

That's the general idea of how an API works - but how do you make use of one on your no-code platform? Most no-code platforms have a way to connect to various APIs, either through some function that's an integral part of the platform, or through a plugin or a third-party integration service. For example, Zoho Creator has an easy-to-follow description of how to use its API service at:https://www.zoho.com/creator/help/api/v2/  

I'll go into a little more detail on the mechanics of API connections in a later post. Meanwhile, I hope you get a chance to experiment with including API calls in your app - API integration has become an important part of application planning, whether for traditional, low-code, or no-code apps.

Google's New No-Code Machine Learning Platform – Teachable Machine

If you're interested in exploring the basics of machine learning (without having to learn complex coding methods), "Teachable Machine" can help you do just that. With Google's no-code “Teachable Machine” you can develop machine learning models and make them available to others without having to integrate them into an application. You can train models yourself to recognize certain images, sounds or poses (such as whether you're sitting down or standing up), and use them directly on the Teachable Machine website or in your own website or app.

(You can find Teachable Machine at: https://teachablemachine.withgoogle.com/ ).

To create a model on Teachable Machine start by gathering your samples and grouping them into classes or categories. Once you've done that you're ready to begin developing your machine learning model.

What can I train my machine learning model to do? By following the tutorials and examples on the website you can train your model to:

• Classify images, either from files or live, from a webcam.
• Classify sounds from short sound samples (WAV, MP3 file support coming soon).
• Classify body positions, using files or images from a web-cam.

Before you get started though, you may want to look through these frequently asked questions about “Teachable Machine”:

• What does Teachable Machine use to create the models? The models are built using TensorFlow.js, a Javascript library for machine learning.
• What method is used to train the models? The models are trained using a method called “transfer learning”. The image and pose models are taught from pre-trained mobilenet models, and the sound model is built on Speech Command Recognizer. In each case models that have already been trained “transfer” their knowledge to your model.
• Do I have to upload all my training data to the Internet? The training is done in your browser – your images, sound bites or other data stays on your computer.
• What if my model's predictions aren't very accurate after I finish training it? You can add additional samples and retrain the model in order to improve its accuracy. 
• What can you make with Teachable Machine? You can find a wide range of Teachable Machine projects (over 15,000 of them) at: https://experiments.withgoogle.com/experiments 
• How can I make my model available to others? Since Teachable Machine models are built with Tensorflow.js, they can be hosted on Teachable Machine for free or exported to any website, server, or machine that can run Javascript. You can also convert your model to TensorFlow or TensorFlow Lite and download it for local use.

To see a detailed step-by-step tutorial on how to train your model, do an Internet search for: “Teachable Machine Tutorial: Bananameter” by Barron Webster (November 7, 2019). The tutorial shows you how to use Teachable Machine to identify images of bananas that aren't ripe yet, bananas that are ripe, and bananas that are past their prime. Note: The same basic steps would work with any three objects.

One of the important points brought out in the tutorial is how much the model can be affected by using some images with a different lighting or background, images where the banana is between stages of ripeness, or images with a just drawing or photo of a banana, rather than the real thing. In general, the more types of images you include in your training the better the model will perform with real-life data. 

Barron Webster's tutorial should give you a pretty good idea of how to use Teachable Machine to train image classification models. In addition, if you're interested, the author has also created tutorials on how to make a audio model (“Teachable Machine Tutorial: Snap, Clap, Whistle”) and how to make a body position model (“Teachable Machine Tutorial: Head Tilt”).

And if you want to see additional tutorials, here are two more suggestions:

“An introduction to Teachable Machine — AI for dummies”, by Rafael Etereo, February 17, 2020. Creating a model to identify people's hand gestures.

“Teachable Machine 1: Image Classification”, The Coding Train, Nov 7, 2019 https://www.youtube.com/watch?v=kwcillcWOg0 

Finally, for a more in-depth look at how Teachable Machine works, take a look at: “How to build a Teachable Machine with TensorFlow.js”, Nikhil Thorat – deeplearnjs.org. Taken together, these tutorials should give you a basic understanding of what machine learning models are and how to build and train them.

Use a Simple To-Do List to Evaluate No-Code Platforms

A while back I posted about a simple to-do list built on Bubble and mentioned that it might be worthwhile attempting to add more features to it. In playing around with that app I learned a good bit about how to accomplish different things on Bubble, and it occurred to me that I could use the same approach to learn more about other no-code platforms.

You can build a simple to-do list application in a hurry on any no-code development site. Once that's done you can try adding some of the features Bubble suggests including in their to-do app (obviously not all of these suggestions will apply to every to-do app): 

• Highlight to-dos that aren't completed yet and those that are past their due date.
• Add the ability to edit to-dos - their title, description, due date, etc.
• Add a "completed date" to the to-dos if you don't have one.
• Add a "remarks" field.
• Include a search function so users can search for a specific to-do.
• The original app often shows just the current "to-dos". If so, try adding the ability to display completed to-dos with a create date that lies within a certain date range.
• Let the user set up recurring "to-do" items for regularly scheduled tasks.

There are also a couple of more complicated features that might be worth experimenting with:

• Add "Projects" to the app. Nest to-do tasks inside projects to turn your app into a project manager. That means modifying the existing to-do report or adding a new report to show tasks by project. It may also involve adding new fields like a project due date, project beginning and ending dates, and the person or persons assigned to the project.
• Modify the to-do app so that outsiders can use it too. Add a landing page, a login screen, and permissions so that a user can only see their own entries. All that will

  

  
  require a user table as well, where the user's id and password are stored.

OK, that's about it for my suggestions about an enhanced to-do list. It can be frustrating figuring out how to add features like these without a tutorial to follow, but you'll have a much better understanding of what you can and can't do on a particular development platform.

The Ongoing No-code vs. Low -code Debate

For some time now there has been a continuing debate about whether the future of programming lies with low-code platforms or no-code platforms. Right now the edge seems to belong to low-code development since it allows the programmer to add custom code directly in the app, which provides more flexibility than a strictly no-code platform.

However, there's an interesting statistic that may be a clue to why no-code will eventually overtake low-code. From 1980 to 2010 enterprise development times steadily declined as programming techniques and resources helped developers turn out software faster and faster. From 2010 to the present though, enterprise development times have trended in the opposite direction, even with the boost provided by low-code platforms.

Why is it taking longer to build new enterprise solutions? Part of the problem is the need to integrate new software with an increasing amount of legacy code and to maintain that legacy code. Low code platforms have helped relieve some of that pressure by proving applications that are largely composed of "black box" building blocks that require less maintenance and testing. However, low code software still includes custom code and that code has to be tested and possibly modified whenever changes are made to the application or to the programming language used in the application. 

No-code on the other hand is entirely (except in very special cases) "black box" which means that maintenance normally just consists of changing a few components or modifying the options associated with some elements in the software. in the long run that means that using no-code will be faster, more efficient, and require less effort than using low-code.

But what about very complex applications that can't be handled without coding? No-code supporters will argue that 10 or even 5 years ago no-code platforms couldn't produce software nearly as sophisticated as they can today - and it's only a matter of time until they develop to the point where you can build even the most complicated pieces of software.

So there's where the debate stands at the moment - what's your opinion?

Get Better Performance from Your Bubble App

Echo Lake Tech has a neat tip on how to speed up user response times for an app created on Bubble.io. The idea involves replacing pages that a user moves between frequently with "group" elements.

Every time you switch to a different page in your app you're accessing Bubble's infrastructure which slows things down slightly. If the user has to switch between certain pages often enough that slight delay can add up, slowing down the user's response time. Creating two or more "virtual pages" on a single page will avoid that interaction and help avoid any slowdown.

Go to https://echolaketech.com/2020/11/02/one-strategy-to-improve-your-bubble-io-no-code-web-apps-performance/ for a full explanation and video of how to implement "group pages". You most likely don't need to do this for all your pages, but it could be worth a look in order to make your app as efficient as possible.

Amazon Honeycode

In June 2020 Amazon introduced its no-code product, Honeycode. Recently we took another look at Honeycode and I would  recommend waiting for Amazon to add more features before spending much time on it. At this point you still have to use a work-around in order to simulate checkbox and radio button inputs. 

Anything associated with Amazon commands some attention, but Honeycode continues to feel like an unfinished product. Hopefully, the platform will get some much needed upgrades in the near future.

A Few Key No-Code Terms

No-Code Terms:

•  aPaaS (Application Platform as a Service) -  Cloud-based software services which allow you to develop and build applications on their platforms in exchange for payment of a recurring fee.
• API Connector - A platform feature that allow you to set up an API connection with an external service that you want to use in your app (a customer payment service for example).
• Business Process Automation - Improving business processes by automating repetitive manual tasks.
• Business Process Management - BPM involves designing, monitoring, and executing inter-related business processes. 
• Business Process Reengineering - Redesigning and rebuilding business processes to improve performance.
• Canvas Apps - Refers to applications created by visually designing and building a program by placing components on a blank screen or "canvas".
• Citizen Developers - People with no background in program coding who are developing their own apps thanks to no-code app platforms.
• Digital Transformation - Transforming services or businesses by replacing non-digital or manual processes with digital processes.
• Hyperautomation - Refers to the enhancement of business processes through the use of artificial intelligence, particularly machine learning models.
• Microservice Architecture - A software development method that looks at applications as a loosely connected group of self-contained pieces or "microservices", which can be developed quickly and efficiently on no-code platforms.
• No-code Apps - Applications created on development platforms that employ visual modelling to build software programs. Users can access a library of pre-built components that they can drag-and-drop onto a graphic interface in order to construct various web and/or mobile applications.
• Progressive Web Apps (PWAs) - Web-based application software built using common web technologies including HTML, CSS and JavaScript. PWAs are intended to work on any platform that uses a standards-compliant browser, including both desktop and mobile devices.
• Rapid Application Developement (RAD) - An iterative approach to software development that emphasizes rapid release of prototypes followed by modifications based on user feedback.
• Robotic Process Automation (RPA) -  Robotic Process Automation is the use of computer software to emulate (and possibly integrate) the actions of a human being in order to execute a business process.
• Template - A pre-built app that you can use as a starting point for building your own app.