Sure thing, David! Anything, in particular, you’d like to know?
The idea for Cloud Canal came from a personal need of mine. I absolutely adore Webflow’s designer, but I wanted to do more than was possible with the Webflow CMS. In particular, a lot of the features I could think of that would be necessary for a web app revolved around permissions and access to the CMS data. I’m aware that there are some third-party tools out there that focus on building membership sites, but I needed to go beyond what they were capable of for my own projects.
As a result, Cloud Canal was born. I built it so that I can connect any site I make in Webflow to any REST API. Cloud Canal isn’t a front end or a back end; instead, it’s the glue that sits between the two.
The nice thing about this concept is that not only can you hook up to any existing API out there, you can also hook up to ones you’ve built yourself . Now I’m not sure what your level of expertise is in creating APIs, but for a truly low-code approach, you can do what I did for the Cloud Canal web app: use Bubble.
Bubble is a codeless platform for building APIs. You can also build a whole web app right in it, but I personally find the Webflow designer significantly more polished and easier to use. I used Bubble to handle all sorts of things in the Cloud Canal app, including my users.
The role of Cloud Canal is then to generate “connectors” that make it really easy for your Webflow site to communicate with your API. It’s more than just one-way communication because you can actually take the response from your API and update your site, set cookies (to store info like an authorization token, for example), and more. This is all accomplished by data attributes that are generated for you by Cloud Canal, as well as a script that you include in your site.
Your Webflow Site -> Cloud Canal -> Your API -> Your Webflow Site
Let’s go over an example of how I built the login functionality for Cloud Canal’s site. In Webflow, I created a modal and an interaction that makes it pop up when the login button is pressed on the page. The modal contains a form with a “data-cc-endpoint” attribute that will send the contents of the form (email and password) to that endpoint. The endpoint id was generated in the Cloud Canal web app.
Now when the user submits the form, the Cloud Canal script that’s included in the page will route it to the endpoint I set up in Bubble. That endpoint checks to make sure the credentials (email and password) are correct and returns one of two responses:
- Correct credentials: returns 200 status code and an authorization token, or
- Incorrect credentials: returns 400 status code and an error message.
To handle the first case, I use a “data-cc-http-200” attribute to handle the positive response by setting a cookie to the authorization token and redirecting to a different page.
To handle the second case, I use a “data-cc-http-400” attribute to show the error message.
I know many people (myself included) learn better by seeing and doing than just by reading, so stay tuned for a video tutorial series! In the meantime, you can get started by going over the “Overview” section of the documentation.
Please let me know if there’s anything that isn’t clear!