DEV Community: Tanisha

How to add Role Based Access Control (RBAC)

Tanisha — Mon, 17 Jul 2023 06:19:56 +0000

Introduction

Canonic is a low-code platform for building tools and automation. You can create tools end-to-end without writing any or very little code. This helps you save countless hours and allows you to focus on the more critical tasks at hand.

Internal tools are often tightly secured with role-based access control and different users might have access to additional features and pages. It becomes essential to have an easy way to maintain access to the tools that you build.

In this tutorial, we will go over adding access control to your internal tools on Canonic. We will use the user authentication addon to enable role-based access control in a few short steps.

Let's begin! 🚀


## Adding login workflows and pages

We will use the login addon to add authentication. It comes bundled with all the pages, workflows, and tables required to add role-based access control.

**Create a project**
First, let's create a project. If you already have an existing project you would like to add auth to, you can safely skip this step.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xnv1t5ki3mg0ntunixfv.gif)

- Login to Canonic
- Click on +Project to create a new project
- Select Start from scratch, and don't add anything else.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cc9gleqw91ra330k1niu.gif)

``
**Add the Login addon**
To add the login addon, press ⌥ + A to open the addon browser and select the login addon. Hit + Add to add the addon to your project.

If the addon was added correctly, you will see a couple of new pages, endpoints, and tables. The login addon should now be configured.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4gll2x63tcfrfjam2lb7.gif)

**Creating a user**
It's time to create a test user! Before we can create a user, we need to deploy the project. Once that's done, you can create a new user using the Create user page. This page is only available to builders and can be used to create new users on demand.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2nneyhwqawc066h83msg.gif)

- Go to the create user page.
- Add a dummy email and password and click on the create button.
- A success alert should indicate that the user has been created successfully.

Configuring Roles
Roles allow you to determine different access levels. Roles and their names differ based on tools so Canonic allows you to define your own roles.

For example, a user with a read-only role should not be allowed to edit any data on the tool. This role might be called viewer or read-only.

Add roles
To add a role, navigate to the newly created user table. This table should be under the data sources section in the left-hand navigation.

Click on the roles field in the user table. This is the field that stores what role each user is assigned. Let's add a few roles. We can also set the default role for each user.

**Assign roles to users**
When a new user is created, the default role is assigned unless manually specified. You can always change the role for a user by navigating to the CMS.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zl2tibt80rq9yzouwbwg.gif)

``



**Adding Access Control**
At this stage, you should have a fully working login page. However, how do you implement access control?

> Access control allows users to have access to only certain pages and functionalities based on their role.

**Make login your default page**
Let's make login the default page to open when loading the app. It should redirect to the actual homepage if the user is already logged in. Let's configure that:

- Right-click on the login page and select Mark as homepage
- Open the page settings for the login page. Under Access Control, add a new rule to redirect to the homepage once logged in. (This should already be configured if you've used the addon)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5zclt5778lo93bw8jq8w.gif)

``
**Configure access to pages**
By default all pages that you create are public. Let's use access control to redirect users to the login page if they don't have the right permissions.

- Open the page settings for the page you want to add access control to.
- Add a role check in the condition endpoints.authenticate.role.value === "ADMIN"
- This will check to make sure the user's role is admin.
- Trigger a redirect to the login page if the check fails.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ff1zu8xrwcp7in82n8ci.gif)

``

**Configure access to components**
Sometimes you want to show certain components based on the user's access. For example, you might want to show the Refund button next to orders only if they have refund access.

- Open configuration for the component you want to access control
- Scroll down to the hidden field, and add your role check there.
endpoints.authenticate.role.value === "ADMIN"

That's it, you should have access control working for all the pages you configured.

``
**Test the implementation**
Let's quickly test the implementation.

- Deploy the project.
- Open the link to your deployed app. It should open the login page by default
- Enter the credentials you created in the earlier step. It should log you in and take you to the homepage.
- Try opening this URL in incognito, since you're not signed in there, you should be taken to the login page

``

Conclusion
That's all folks. As you can see, role-based access control is incredibly easy on Canonic despite being a complex feature. It's always important to maintain access control rules for all your internal tools and dashboards to ensure that only authorized users have access to your data.

Canonic never stores your data and all authentication data is encrypted at rest for maximum security.

As usual, let us know your feedback in the comments, and feel free to reach out to us at hello@canonic.dev

Onwards & upwards 🚀

``

How to Create a Database Tables in Canonic

Tanisha — Tue, 31 May 2022 12:53:33 +0000

Canonic:The simplest way for agile teams to build internal tools.

You can model your database in form of tables. The Graph tab is the default page that will pop up once you are inside your project. Working on a graph with Canonic comes at super ease with a mindmap-like interface.

Let's look into the various aspects of building a table, the required setting, and more.

→ Once you are inside your project in Canonic, you will see something like this:

Step 1: Create a table for your database

Click on the + icon on the left-hand side panel. It will give you the following three options to choose from:

+TABLE
+ENDPOINT
+TRIGGER

While we will look into each of them in our upcoming articles, in this one we will explore the table section of the graph.

Select the first option - TABLE to create a table to hold all your fields.

Name the table and select the type:

Individual Tables: Stores a single piece of content for the graph that you define.
List Tables: Stores an array or a list of content entries for the graph that you define.
Identity Tables: A unique type of User table that enables you to manage and store your users' data as well as support multiple login providers.

You'll also have to define the KEY, a unique identifier that is used in APIs

Step 2: Explore the Table settings

This is what the setting section looks like on the right-hand side panel:

The first option you get is to select the Type that fits best the data requirements, within which you've three options:

LIST
STANDALONE
IDENTITY

→ Use LIST: If multiple data points can be defined

→ Use STANDALONE: If there's only a single data point per project

Next, you've to give the NAME & KEY for your project:

NAME - Choose a name that best describes the table
KEY - The unique identifier (used in APIs)

How to Modify your generated Tables:
If you wish to edit your created tables:

-> Editing Table - The table can be edited by clicking on the table and an editing panel will appear on the right side. There is a properties panel at the bottom of the table where all the necessary fields can be edited.

-> Deleting a Table - You can delete a table by right-clicking on it and selecting delete. All fields and fieldsets within the table will be deleted permanently.

Generating Endpoints for your database table
The last option in the table setting is 'GENERATE ENDPOINTS'. Here, you can select the endpoint that you require. In Canonic, you can generate default CRUD endpoints for the table:

CREATE, UPDATE, DELETE, GETALL, GETONE

Choose the one you require and hit 'Generate'. These endpoints can also be generated later on as you move ahead with your product development.

Step 3: Create Fields for your database table

When you'll click the + button next to the table node on the graph, you'll get three options:

Field - Choose when you want to create an individual field.
FieldSet - Choose when you want to group the fields.
Integrations - Choose when you wish to create an external integration.

Set 4: Exploring Fields and FieldSets

Fields define what data your table will contain and can be of different types such as text, image, file, date, time, etc. They directly impact how the CMS and the APIs work.

Click the + button next to a table or fieldset node on the graph to create a field. A new field will appear on the graph with the properties panel visible below it. Fill in the fields as needed and close the properties panel to save your changes.

When a table entry is created, all fields support setting default values that will be used if no value is provided for the field.

Field Validation:
By adding validations to the field, we ensure the correct data is being saved corresponding to the field.

FieldSets:
You can either use FieldSets to group together some fields based on semantics or to store a list of entries for that group of data. When you create a FieldSet, you'll see a section on the right that lets you select the type of FieldSet you're looking for:
List - To define multiple datapoints
Standalone - To define a single data point

Other than the type, you will have to give a 'Name' that describes the fieldset and the KEY as the unique identifier used in APIs.

FAQs:

1. How to link a database table to other tables?
Tables in databases are often linked together using foreign keys; in Canonic, this is done using Resource Fields, allowing the field to contain the information that's populated from your other tables.

How to create a link:

Make sure the table you're linking has been created.
Create a new Resource field that will act as the foreign key.
Now to create a Resource field - In the type properties of that field, select the table you wish to link to from the dropdown list.
Publish your graph.
You can now create CMS entries. Dropdown options for the field will be synced with entries for the table you linked to and will be presented as a drop-down in the CMS.

2. What are computed fields?
A computed field is the one that is computed whenever you request it. You can create a computed field by marking the input type as Computed while creating a new field. This computed field will always return an object and one can't directly set a value to these fields.

Learn more about computed fields here

And with that, you've modeled your database table 💃

Thanks for reading! We hope you're able to build the tables for your projects at ease.

You can also integrate your external databases with Canonic, know-how 👇
Integrating external databases with Canonic

If you have any suggestions, or feedback for us please feel free to reach out, it's always great to hear back from you.👯‍♀️
Give Canonic a try? 🚀

How to integrate external API endpoints in AppGyver

Tanisha — Tue, 26 Apr 2022 09:43:36 +0000

With the advent of low-code/no-code platforms, building applications has become much easier. The AppGyver platform is one such no-code platform where you can develop applications without having to code.

Now that we have a clear understanding of the platform, let’s dive into the functioning and step-by-step guide to integrate external API endpoints in the platform.

How to integrate external API endpoints in AppGyver

Step 1: Open your Project in AppGyver & Go to the Data button
Once you are inside your project, go to the Data button at the top of the toolbar, to create new external data resources or to edit the existing ones.

Step 2: Add Data Resources
Once you’re into the data tab go to the Add Data Resources by clicking on plus sign in the top right corner, which will have a dropdown of 5 different options from which we will select — Rest API direct Integration to integrate external API endpoint.

Step 3: Base Configuration
The resource configuration is split into base configuration and method configurations for GET collection, GET record, POST, PUT/PATCH and DELETE.

Base Configuration:

Here, you define the base configuration:

Resource ID: unique ID for the resource in your app
Base URL: URL shared between all methods
Path variables: Use to make parts of the URL dynamic
Headers: HTTP headers to be included in every API call made to this external resource
Query parameters: Parameters to be included in every API call made to this external resource

Canonic for the Backend

Here, we will be using Canonic to generate all the required APIs endpoints that we need to integrate with AppGyver.

Canonic is the simplest way for agile teams to build internal tools.

In Canonic, you can directly get your Base Configuration by:
Going to your project in Canonic → Docs section → Copy the URL

Once you have your URLs ready, get back on AppGyver and place them at the required spot as shown in the picture below.
With that, you have your base configuration ready! 💃

Exploring the API methods

Now that we have our base config in place, let’s see how can we integrate all these different methods in our project.

Get Collection (GET):

The base URL will automatically reflect in all other tabs. So, all you now have to do is fill in the Relative path/ Response key and Test API call response.

For Get Collection, there’s no specific id required because we are retrieving the collection of data from a server.

Thus, will go in with the Relative path and Response key.
Response key — The JSON response from an API might include the actual data we are interested in inside a key of the main response object.

Which in Canonic’s case is data:

If you’ve correctly followed and tested, you’ll get something like this:

Similarly, all you have to do is copy the required URL which you get readily available with Canonic, put them in dedicated fields.

GET RECORD (GET):

GET method is used to retrieve data from a server at the specified resource.

Now to retrieve some data, we need to specify which data we are required to fetch, and hence we’ll need to pass the id and Access Tokens (represent the authorization of a specific application to access specific parts of a user’s data).

Go to Canonic — Select Product (GET) — Copy the URL from the endpoint section.

As the base URL is already set we will just paste /products/:_id on AppGyver’s Relative path section.

Now, we need to pass the id, which you can get by following:
Canonic → Project → CMS section → Under the CMS entry title you can see the id (shown in the image below).

Copy the id and pass in the Relative path of Appygyver

Access Tokens: This broadly has two steps
1. Creating Access Token in the backend:
As we are using Canonic as our backend, the access tokens can be created within minutes.

Go to settings→ AccessTokens → Create A New Token → Give it a name and provide access → click on create → copy the value.

2. Embedding access Token in AppGyver:
In AppGyver, the access tokens need to be embedded in the HTTP Header section, where you’ll require the below fields:

In the config tab of AppGyver → Http Header → On the right-hand side panel fill all the required details:

Key: The exact key name of the authorization Label: Name this as per your understanding Value type: Text Description: Description of the token

Go to the Test tab to run a test and in the URL placeholder, mention the id of the product that we copied earlier.

Once the access token is in place, run a test (here you need to mention the id as well) and that’s it!

You’ve successfully retrieved data from a server ✅

CREATE RECORD (POST):

A POST is used to create or update a resource on a server. POST data is sent to the server in the request body of the HTTP request.

Here, we will require to specify the data that we want to store in the server.

Let’s see how to do that 👇
Go to Canonic — Docs Section — Select Create product (post)- Copy the URL from the endpoint section.
Go to AppGyver -> CREATE RECORD (POST) → paste the relative path ****
As the base URL is already set we will just paste the required specific field on the Relative path’s section.

Sending the Payload
Now as additional steps to send the payload, go to the schema tab → Create record (POST) request schema
Here, we will specify our data requirements which are name and description with the input object.

Go to add Property → mention key as input and value type as object. Within which we will add the rest of the values, in our example’s case, name and description with key as name and description and value type as text.

Once done, Go to the test tab and custom object and mention the required name and description which will get updated in your backend, in this case — Canonic.

DELETE RECORD (DELETE):

Similarly to delete the record, we will need to pass a specific id (which we want to delete).

Go to Canonic — Docs Section — Select Delete product (delete)- Copy the URL from the endpoint section.

Go to AppGyver -> DELETE RECORD (DELETE)→ In the config section tab, paste /products/:_id on the Relative path’s section.

Follow the same pattern of updating id and custom object
(Ref above to get Product id from Canonic)

One all the fields are set, run Test API call response

UPDATE RECORD (PUT):

The same process will apply to PUT in which the method will search for the input if found will update it or will create a new record, quite similar to the steps we did in the POST method.

If you will follow the steps right, you will be able to external API endpoints in AppGyver with ease! 🚀

Voila, you’re done!✨

Yes, that was it. Here are all the links you’ll require:

AppGyver — A no-code platform, enabling you to build apps for all form factors, including mobile, desktop, browser, TV, and others.

How to Test Low Code APIs using Canonic?

Tanisha — Thu, 21 Apr 2022 07:19:56 +0000

Low-code programming represents underlying code and functionality visually in a graphical user interface. In a low-code API integration tool, users manipulate the visual elements in the graphical user interface to specify the functionality they want the integration to achieve. In the case of Canonic, the user interacts with the graph interface and builds a backend setup that they can deploy.

Why is it tough to test low code APIs?

Usually, with low-code APIs, the problem comes when changes are required in the API. Whenever any changes are made to the graphical user interface, in order for them to be tested they need to be deployed. When these APIs are deployed, all the frontend applications relying on them become vulnerable to any bugs that could've been shipped with the changes to the API. This could potentially result in downtime and is not ideal for a production setup.
To solve this problem of not being able to test changes before they are deployed, Canonic came up with the environment set up on their platform.

What is an environment setup?

Environments in terms of software engineering can be simply explained with the example of an isolated sandbox. Each environment is an isolated instance where you can run your software and consume APIs.
Here are some of the keywords about environment setup and what they usually mean:

Deployment : All the activities that make software available for use
Environment : The Operating System, API calls, and databases used by the software
Development Environment : The environment catering to developers for building software
Staging Environment : A replica of production environment where changes are tested before production deployment.
Production Environment : The environment catering to the end-user of your software

For now, we know we only have one environment available to us where if we deploy any new changes they are reflected in the APIs. Let's call this environment "production" (as seen in canonic).

How will an environment setup help me?

To solve the problem of not having a medium to test APIs for the project, Canonic allows you to set up multiple environments for your project.
Setting up an additional environment gives us a lot of leverage in terms of experimentation and pushing code changes to APIs without actually worrying about the side effects on production APIs and their consumers.

How to set up environments in my Canonic project?

To add an environment, you simply need to go to your project's settings and go to the environments tab. As you can see we only have one environment existing in our current setup which is production

Now we click on the + sign right next to environments, and we will see a new environment popup. As seen below, you can name this env staging or you can also name it development alternatively based on your preference.

Once you are done with the naming, click on + CREATE button as you can see in the attached screenshot.

Once the env creation is successful you will see a popup saying "Environment Created" as shown in the screenshot below.

This means now our project has a new environment that we can use to test our changes.

Till this point, we have created a new env, but we have not deployed it yet. To deploy it, we need to go to the Deploy button on the top right of the page and deploy the project again. As you can see in the below screenshot, we now have Staging in our list of environments, and it is not deployed, so we simply select staging and then click on the deploy CTA.

When the new env is deployed, you will see a deployment successful message along with the URL for your new environment.

And Voila! we have a staging environment setup to test our changes before they go live on production.

Thanks for reading! If you find this story helpful, please click the 👏 button and share it to help others find it! Feel free to leave a comment 💬 below.

Integrate Github with Asana to track issues in repositories

Tanisha — Thu, 16 Dec 2021 12:41:41 +0000

Over time the need for different services grows in a SaaS startup, from something as simple as sending out a slack notification to something more complex as Integrate Github with Asana.

In this case, maintaining and scaling these numerous Micro-services and Integrations is a huge developer overhead task.

Our previous guide covered sending a notification to Slack, and today we will move on to a bit more complex integrations ie; how you can integrate Github with Asana to track issues in repositories

Let's get started! 🚀

Step 1: Create a Asana account

We'll be setting up an automated pipeline to create tasks on your Asana project whenever a new issue is created on your Github repository. So make sure you have your you have an asana account, or you can create from here.

Step 2: Let’s begin with the integrations! 👩‍🔧

All you have to do is, go to this sample project and click on the top right corner to clone it.

This project already has Github<>Asana integration set up. So after cloning the project, we are set to move forward and get started.

Step 3: Explore the API tab 👩‍💻

In the same project, from the left-hand navigation bar, move to the API tab.

There on the left-hand panel, you’ll find different divisions like - Endpoints, Scheduled triggers, DB triggers, Integration triggers, etc. In the integrations triggers, you should find an integration setup!

Step 4: Setup GitHub Integration ✨

Let's see how you can modify this Github integration trigger that runs whenever the count of issues in the repository changes, i.e. Whenever a new issue is added to the repository.

Click on the GithubIssues trigger node and it’ll open up the Properties panel for it.

You can see that we've selected the ListRepositoryIssues API from Github here. It'll listen to any changes to the response of this API and will trigger your workflow if the changes match any of the filters you've added. For this example, we are checking the list of the issues returned from Github is changing or not.

Now add your own repositories details in the API Configuration Section:

Step 5: Setup Asana Integration ✨

Click on the Asana node and you can see the Create a Task API of Asana is already setup. Add API Key in the authentication section to connect with your account.

Move on to the Optional tab of the panel and add:

{{0.title}} in the name field
{{0. body}} in the notes field

Once you've reached here, you've successfully Integrated Github with Asana to track issues in repositories. 🥳

Now every time an issue is created on your repository, you'll have it on your Asana Project too!

Check out the sample project here

Conclusion

Hope this guide helped you guys to track issues in repositories in an optimized and faster way. You can also check out our other guides here.

Join us on discord to discuss or share with our community. Write to us for any support requests at support@canonic.dev. Check out our website to know more about Canonic.

Picking your tech stack - Canonic vs Strapi

Tanisha — Tue, 28 Sep 2021 13:01:09 +0000

Introduction

Canonic and Strapi are often compared as direct competitors. However, the two are quite different in terms of intended usage & audience. This article aims to highlight these differences from an unbiased perspective and help you choose the perfect tool for your particular use case.

Strapi positions itself as a developer first open-source headless CMS platform; essentially trying to make content management & subsequent development faster and easier. Canonic, on the other hand, positions itself as a low-code backend development platform trying to take care of all your backend requirements in a single place. The two platforms are, therefore, positioned differently which should give you a clear indication of the requirement each platform is trying to fulfil.

Pre Requisites

Strapi requires certain softwares to be pre-installed.

Strapi requires three softwares to be pre-installed on your computer before you can use the platform. These are Node.js, Npm/Yarn and a database (SQLite, PostgreSQL, MySQL, etc). As Strapi is "developer-first", these softwares do have a certain learning curve to them (if you're not a developer) on top of the minimal learning curve of the platform itself. However, the well maintained Docs section or these video tutorials can help you get started in no time.

Post the installation of the pre-requisites, you can get your Strapi Dashboard up and running!

Canonic requires no pre-requisites.

Canonic does not have any pre-requisites. Since Canonic is a web app, it can be accessed through any internet browser, removing the need to switch between applications. Everything created on the platform remains on the platform itself; therefore making it a complete backend development tool.

The only learning curve here is of the platform itself which can be navigated through by reading the documentation or completing the onboarding.

Canonic dashboard.

For anyone without substantial development experience, Strapi might be a little overwhelming to get started with, in comparison to Canonic. However, if you are a fully-fledged developer, there is a good chance that you already have the Strapi pre-requisites installed on your computer and can get your project up & running in no time.

Hosting & Security

Strapi projects are self-hosted.

Strapi projects are self-hosted which means that the data is hosted on your computer or your server(s). They do have a Cloud Server functionality coming soon; the dates of which haven't yet been released.
Due to the projects being self-hosted, there lies a hidden pre-requisite to use Strapi in terms of DevOps / deployment experience as well as the knowledge of hosting your server.

Canonic projects are serverless backends.

Canonic, on the other hand, is a cloud-based platform with a server-less architecture. The projects are serverless backends securely hosted on the AWS platform and your data is securely saved on your database; reducing the risk of losing data and allowing you to scale without worrying about the stability (in case of higher traffic or other such cases).
There is no hidden requirement of DevOps experience to use Canonic.

Platform

Both platforms utilise graphical interfaces. However, due to the differences in product orientation, the way data is represented varies immensely.

Strapi uses a list-based view to make content management faster.

Strapi uses a list-based view to show the CMS collection types (essentially folders or elements of your database). This is helpful while maintaining a large number of entries as Strapi is more focused on content management as a platform.

Canonic uses a graphical node-based representation for your database.

Canonic, on the other hand, differs completely. It uses a graph-like view to help see your database structure more clearly. With each table having separate nodes for fields, one can see the entire data structure in a single glance.

Therefore, a database with many fields of varying field types becomes faster to identify on Canonic as it is inherently a visual interface. The same can become a little difficult on Strapi.

An instance of this is to see what fields in a table are of the "linked" type in a database. Visual interfaces can afford signifiers, which in this case, Canonic provides with the help of a dotted line to signify a linked table. Therefore, time to locate specific fields is reduced on Canonic's visual interface while the same can become a little tedious on Strapi.

Linked table types (or Relational Fields on Strapi).

Linked field types on Canonic on the graph-view use a dotted line and show what table the field is linked to.

APIs

Both platforms offer auto-generated CRUD APIs with the added functionality of adding custom-coded business logic and creating your own APIs. However, here is where a major difference lies between both platforms.

Strapi uses a plugin to view APIs and is editable through your code editor.

Strapi provides you with a list of APIs by using a plugin built into the platform called Swagger. Since Strapi is developer-first, any modification/creation of APIs has to be done via your code editor. To aid this process, Strapi autogenerates folders inside your preferred code editor where you can meddle around with the APIs.

The APIs documented on Swagger show up like this:

API List on Swagger.

The APIs are then incorporated inside your code editor, as shown below:

Strapi autogenerates folders directly inside your code editor.

Canonic allows you to create/modify APIs all in one place.

Canonic works a little differently. Even though the platform has an SDK to integrate your project directly into your code editor, the true power of the platform lies in the platform itself. Canonic is essentially a one-stop platform for all backend requirements. Your database, CMS, APIs and documentation exists in one place: on the Canonic web app.

Each API and subsequent trigger/webhook is seen as an endpoint, again in a similar node-like structure. This makes it easy to see webhooks and APIs in logic blocks. However, this preference can be quite subjective.

The documentation for the APIs exist on the platform itself, as shown below in the screenshot:

Another point to highlight is that Canonic allows you to create complex workflows straight from the platform itself which you would otherwise have to write in code on Strapi or other headless CMS platforms.

Therefore, the difference between the platforms also lies in the requirement of DevOps experience. While Strapi requires you to build out your APIs inside your code editor, Canonic allows you to do the same on the platform itself along with the added functionality of creating complex workflows and triggers; all on a visual interface. Custom business logic has to be written in code for both platforms.

Pricing

Both platforms feature a free forever plan along with several paid options. However, because of the difference in functionality and what each platform has to offer, there are differences in pricing options.

Strapi is an open-source platform and has a "free forever" plan.

Strapi's free forever plan allows you to have a self-hosted Strapi project with unlimited CMS entries and API Calls with 3 default roles. The paid plans offer features to scale up your project with more custom roles and support.

Canonic features a freemium plan.

Canonic's free plan allows you to create 3 projects with one additional collaborator and 5000 requests a day. Paid pricing plans allow more API calls and CMS entries.

Conclusion

Based on the points above, it becomes evident that Canonic and Strapi are quite different in terms of positioning and what they're striving to do.

If you are a developer with knowledge about backend systems and DevOps, Strapi integrates into your workflow more easily. It sits inside your code editor; leaving you to dabble between your Strapi CMS and frontend framework straight from your code editor.

With Canonic, your entire backend system is in one single place complete with your database, CMS, APIs and documentation. This can be created regardless of development experience, making it a better choice for people who lack the knowledge or resources required to create a backend. While Canonic also allows you to use SDKs and incorporate your project with your frontend framework, the true power of the platform lies in the relative ease and rapid speed with which you can make a backend on the Canonic web app.

The next major point of differentiation is hosting. Strapi allows you to self-host your project which means that the data is only with you (your server) and not on any other place on the internet. Canonic, on the other hand, hosts your backend for you and you can even select the region of deployment. Therefore, API response time is faster and the risk of losing your data becomes next to impossible. A serverless backend also removes the hindrance of unstable systems as you scale up your backend, accommodating higher API calls and CMS entries.

Finally, the preference of Strapi over Canonic or vice-versa largely depends on your specific use case. If you are looking for a developer-first content management tool, look no further than Strapi. However, if you're looking for a fully-fledged low-code backend development tool, regardless of your development experience, Canonic might be a better fit for you.

I hope this clarifies some of the confusion surrounding the similarity & differences between the two platforms. Let us know which one would you prefer and why in the comments below. Godspeed to your backends and you!

Heading to Disrupt 2021

Tanisha — Tue, 21 Sep 2021 17:57:47 +0000

The past few months have been quite intensive at the Canonic HQ. We worked on new features, performance & stability improvements, an entirely new onboarding, multiple environments support and finally came out of beta through a Product Hunt launch in August 2021. And it's not over yet. This year, Canonic is headed to TechCrunch Disrupt 2021 and we can't wait to see you all there.

If you're new to Canonic, I recommend reading about our product and how we're trying to reduce backend development time and effort ,through an intuitive low-code platform, before you move on further to learn about our new developments for Disrupt 2021.

Getting ready for TechCrunch Disrupt 2021

Disrupt is unarguably every tech startup's dream place to be. A chance to show off your product in one of the biggest tech conferences, network with inspiring people around the world and play a part in shaping the tech of the future and the future of tech. We'd be lying if we told you that all of us aren't crossing off days on our personal calendars.

That being said, we know it isn't easy to leave your mark on the tech world without putting in some serious work. Don't worry, we've been preparing.

A scene from the office during a bug-identifying session.

Here are some new things that we've worked on:

Database Integrations: Import or link an existing PostGres / MySQL / MSSQL / Mongo database into your Canonic project and generate APIs for them.
Improved SDKs: New backend and frontend SDKs allow you to focus on your frontend code while building a low-code backend, without ever leaving your dear console.
Onboarding: With more tutorial projects to choose from and an improved experience, learning how to supercharge your backends with Canonic has never been easier.
Database & Scheduled Triggers: Automate your workflow by adding database triggers with Slack, Twilio and Mailgun integrations as well as adding scheduled triggers to trigger periodic or one-off events.
Multiple Environments Support: Let's face it, deploying changes for a large-scale project can be scary. Test out all your changes by deploying it to an internal testing environment before you make it live.
New Sample Projects: We've created multiple sample templates that you can replicate for your particular use-case. Want to build an Airbnb replica? Check. WhatsApp replica? Check. Twitter, Spotify, Netflix, Kindle? Check. Check out all available sample projects here.
Improved security, performance and scalability: Let's face it. Crashes and bugs can be annoying roadblocks on the way to productive nirvana. We've stayed up days & nights to ensure a smooth experience. Let's get to building that backend at lightning fast speed, eh?

The features saw a lot of positive feedback from the ProductHunt community. Furthermore, a lot of our recent weeks have been spent on testing and validation of these features; ensuring their functionality and ease of use.

ProductHunt comments post-launch. Check out the entire thread on ProductHunt.

The Canonic Booth @Disrupt 2021

This year, due to the disrupting pandemic (see what I did there), the event shall be held virtually. The Canonic team will set up a virtual booth where you can interact with the founders, take a demo of the product and check out one of the fastest backend developing low-code tools out there, all in real time. It's about time that the world gets to know about this tiny company based in India trying to make backend development easier, faster and more accessible.

If you've already grabbed your passes, do stop by at our virtual booth! We'd love to chat with you and help you make your backends faster. And if you still haven't purchased those all-important passes, what're you waiting for? The tech-world is at Disrupt; where are you?

Hello World! We've launched🚀

Tanisha — Thu, 19 Aug 2021 13:46:43 +0000

Hello World!

It brings us immense joy to announce that we are ready to get out of Beta. After 8 months of successfully launching our product, we worked on new features, bug fixes and great feedback from all of you. The result was a much stable and smoother platform equipped with features to help you build a production-ready backend in minutes without any knowledge of code.

We'd love to hear your feedback here - https://www.producthunt.com/posts/canonic-2

Wait! ….what’s Canonic?

Canonic is a low-code intuitive platform to build scalable backend and craft APIs for your web apps, mobile apps and microservices. It enables developers to ship production-ready backend instantly. All without writing a single line of code!

So what’s new in Canonic?

Execute Database and Scheduled Triggers without diving into cron
Integrate with external databases - Postgres, SQL, MySQL, MongoDB
Choose the region for deployment and keep your app secure
New Marketplace of integrations
SDK to help integrate backend with frontend

Accelerate Development time - With our intuitive interface, defining database models and crafting APIs becomes quick and easy. Logic blocks help you define your business logic. And it's all hosted by default! so you can instantly start integrating APIs with your frontend.

Single Touch point to manage your entire backend - Everything from hosting, to database, to APIs can be managed on Canonic, saving you the hassle of setting up and managing multiple services.

Deploy scalable backend - With instant deployments and serverless architecture, scalability stays high while keeping costs down. As your project grows, you can make use of built-in code editor to write business logic that require code.

Automate Events - Database & scheduled triggers help you achieve automation without diving into cron and scripts.

A much smoother and stable platform.
We’re excited for you to try our new and improved Canonic, and we hope that this tool will help you create an amazing backend. The Canonic Team and I are beyond thankful to our amazing and supportive Canonic community. Without the incredible amount of feedback and support we wouldn't be here today.

Let us know your thoughts! - https://www.producthunt.com/posts/canonic-2

Setup travis CI builds directly from the API

Tanisha — Wed, 30 Jun 2021 12:14:14 +0000

Executing a CI Build using an API built with no-code backend platform! These truly are craziest of times. The need for APIs triggering Builds actually eliminates a lot of hassle that often come with using tools like jenkins or travis. They offer a lot more CI features but are often difficult to setup & maintain for smaller projects.

If you have a SPA website hosted that depends on the content of your backend, well, you're in luck because you can attach a webhook to your API endpoint, which will trigger a build everytime the API is called.

Creating project on low-code tool

We head over to Canonic and sign in using our social accounts. Next, we click on Create New to create a project for our application. Click on next, then click on create to complete the process.

Create new project screen
A popup asking your first table name will appear. If not, you can click on the + icon in the header to create a new table. Let's name our first & only table for this project - RepoBuilds.
We create a text field named "Repo Branch" as we need the branch name against which we want to trigger the build.
We hit deploy on the top right, and we'll be provided with a hosted backend. a database & basic CRUD endpoints per table.
Click on the API tab on the left to start adding the Travis CI webhook. We select + button that's attached to the createRepoBuilds block in mutations. It'll open up a new webhook settings on the right hand side.
Select Build type → Choose Travis CI from the list of providers & you'll be provided with fields for settings.
API Key → This is the API key of Travis account.
Repo Url → Git URL for the Repo we want to trigger the build
Repo Branch → Branch to be selected for building
For Repo Branch → We want to trigger the build against the text found in the repo branch field of the API payload. So we can make use of Handlebars templates & simply write {{repoBranch}} in that field. This will extract the repoBranch field from the API payload and forward it to Travis.

And we're ready with our API to start triggering builds. Managing an API access is easier than managing CI access, so you can directly start consuming this API both by yourself & teammates.

Integrating our existing app with this API:

This will require a combination of things that we need for securely connecting our application with this API.

Access token for our API
Documentation for the API

Access Tokens

Click on Settings using left side menu. Go to Access tokens tab.
Click on Create a new token, and provide it a suitable name and permissions. Click on Create.
You've successfully generated an access token for your API. Copy it & save it some place safe as you won't be able to see it again.

Documentation

Head over to the docs tab using the left-hand side, and you'll find documentation for createRepoBuilds API (the API block where we added our Travis webhook).

Testing

After completing all the necessary steps, we're finally ready to deliver our first SMS using our Travis-connected API.

Let's copy the CURL command that was mentioned in the documentation. Fill in your access token and paste it into the terminal.

Our curl command will look something like this.

➜  ~ curl 'https://xxxx.hem.canonic.dev/api/repoBuilds' \
  --request POST \
  --header "Content-type: application/json" \
  --header "Authorization: xxxxxx-xxxxx-xxxx" \
  --data '{
    "input": {
      "repoBranch": "newFixes",
    }
  }'

A successful response will look like this:

{"data":{"repoBranch":"newFixes","_id":"60bf30ee2529700009fd2a4a","createdAt":"2021-06-08T08:57:18.316Z","updatedAt":"2021-06-08T08:57:18.316Z","__v":0,"id":"60bf30ee2529700009fd2a4a"},"error":null,"success":true}%

You should check on Travis, and you'll find the latest build in progress. Having an API saves a lot of trouble of maintenance and boilerplate setup while leaving plenty of room for rapid innovation. Find more information about this feature here - https://docs.canonic.dev/concepts/webhook-providers/travis-ci

You also add other integrations depending on your business needs like sending a message on slack, etc. Check out the slack guide here.