Skip to main content

· 4 min read

Apito is a Cloud based Service that helps you build API easily. You can think of it as a firebase alternative. This guide will show you how you can use Apito to build API for your next project or application.

Apito Console

If you havent already created an account in apito please go to this link and create one. Once you logged in to Apito Console you will a Project Space like above. You can use this space to switch between your projects or create a new one.

Now, for this quick started guide I will be creating an API for an ecommerce project, so lets gets started.

1. Create your project

Click on the Start a new Project button to initialize your project creation. Enter your project name and description and click Continue. On the next page select Apito Cloud option to create your project faster. Other Database options will soon be available. Congratulation! you project is being build. Once it’s done you can click Explore new project to switch to your newly created project and start building your API instantly.

Apito Create a Project

The first step after creating your project is to define your project models. The most important part of designing an API is Database Modeling. Let’s start by creating our first model. We all know Products and categories are a crucial part of an ecommerce API.

2. Model your Database with models & fields

Click on the Models Tab in the top navigation menu. Then from the left side bar, click on Add a model button. Now, write down the name of the model, in our case it will be product. Now click on the create button.

Database Model Creation

Next, we will add few fields to our newly created product model.

Fields

To add fields to a model click on the Add a Field button. First, we will add a title field of type text and we will set the attribute of the title to required. Then, a description field of type, Rich Text. An Image field of type, Media. A Price field of type, Number. And last but not least a Rating field of type, Number. Now let’s create another model named Category and add few fields in it. Those fields will be name, label and icons. Apito model & field builder is very versatile you can use it to design complex and nested model structure.

Relations

Next, we will create relations between them. For that you need to click on the Add Field Button and then select Relations. Your relation creation between models depends on your project requirements.

Database Relations

For now, let’s say, Product has many categories and categories has many products. Wow, as you can see, how easy it is to create entity relations between models in apito. Also, you can rename, delete and create fields & relations anytime you want. Now, that our database design of product and category model with relation is created, we are ready to insert some contents.

3. Insert your content

Click on the Contents tab and select your model. As you can see, Table and forms are auto generated based on your database model design. Let me insert few products and categories into our database. To add a new product, click on the Add a new product button, which is on the right side of the product content table. You will be able to see a drawer pops up from the right side of our table, which contains an auto generated specialized input form based on your model design.

Content Management

Let’s add our first product using this form into our database. Let’s add our first category into our database. As you can see while creating a category you can directly tag products with it. As you can see that product and category are now linked with each other.

4. Explore Both GraphQL & REST API

Our Ecommerce API is ready. To explore our API lets goto the API Explorer from the top of the navigation menu. As you can see, our GraphQL & REST API is ready for use. Let’s run our first query. We will now Search a product that contains blue in its name. Now click Run and as you can see its working! our ecommerce API is ready for integration.

GraphQL Explorer

You can also use REST API if you project requires it. Apito Generates a Swagger Documentation which is compatible with OpenAPI.

Swagger UI

· One min read

Recently GraphQL is becoming the buzzword in the developer community. Although building a GraphQL server was very difficult in the past, nowadays with overall community support and developer tools, I can say it's rather very easy to build one than to build an old-fashioned Rest API.

When it comes to choosing which protocol to choose for your next project, nowadays people often get confused between Rest API & GraphQL, I say, don't get confused and it depends. There are many aspects where using GraphQL is overkill and many cases where GraphQL will thrive over REST API. Let's discuss what's what throughout the post


Let's discuss what's what throughout the post



REST has some limitations.

  1. REST is rigid, requiring different endpoints for different responses.
  2. Teams with back-end and front-end devs need to coordinate any change, increasing the complexity of the development effort
  3. Endpoints have a predefined response - often returning more data than needed and consuming precious bandwidth.

Let's talk about the REST API first and why it's awesome!

· 6 min read

Internet is filled with tons of articles and tutorials that talk about building production-ready and scalable apps for both web and mobile. Developers often time get caught up trying to apply the same principle or guide but often time they ended up "re-inventing the wheel" Apito and Firebase both come with Backend as a Service (BaaS) APIs that help you develop your application faster. A key component of any BaaS is instant APIs over a database

  • once you define your database schema, you should get data APIs instantly.

Comparing Apples to Applesauce

Apito and Firebase both offer APIs over a database while both of them provide this solution on top of a proprietary database. We use nn optimized version of RocksDB. Soon Apito will be able to connect to several popular choices of databases including PostgreSQL, MySQL, Mariadb, Mongodb & ArangoDB. That is a topic of another discussion.

Firebase was originally designed exclusively as a realtime database. If your project does not need a real-time database then using it is exteamly difficult for modern application development.

Let me tell you why,

Querying & Filtering your data is very difficult with Firebase, wherewith Apito you can execute bulk queries with complex filters ( even geospatial queries ) Also, Once an application is in production, you will need to write complex queries, especially for the purpose of Analytics or Business Intelligence. With Firebase, you are restricted to basic CRUD queries. This is okay for rapid prototyping but does not lend itself to a production app.

Database Design, Migration & Content Management

This is probably one of the biggest gripes power users have with Firebase. On Firebase, you can only change data from the client-side. This means you have to write a script to perform a schema evolution (which is error-prone and risky if not performed in a transaction, or in sets of transactions) or handle the schema evolution in the app code itself!

But on the other hand, On Apito, Migration happens instantly once you modify your model and publish it. This is similar to the natural developer workflow of taking changes in dev and then applying them in staging/production environments.

Data modeling

Thanks to Apito's Versatile Model Builder, it supports various fields to model and structures your project, for example, Single Line Text Field, Date Field, Number Field, Fields within Fields ( Array of Object) and the Most important feature is the relation between models ( One-to-One, One-to-Many, Many-to-Many ) It is harder to model relationships between independent data models with Firebase's proprietary database (originally a realtime database). If you made a mistake early on in your modelling, migrating and changing to a new data model is hard.

Role based Permissions

Firebase permissions can only capture rules based on the data within the current 'path' (node).

On Apito, you can specify granular permissions based on roles. That can be attatched to any API endpoints & models. Read more here.

A Back-end for SaaS Apps

Firebase is a well-known backend-as-a-service. It has a ton of useful features that can all be tuned and tweaked to power the back-end of a SaaS application. That said, they've made a much larger effort to be the cloud back-end for mobile apps. As a developer building SaaS, you can configure Firebase services to suit your requirements, but it's always going to be extra work. With Apito, that's pretty different. 8base designed its platform to best accommodate SaaS apps from day one; with a GraphQL API for any web-client, or mobile, to consume. This naturally makes it ideal for developers looking for a backend-as-a-service on any SaaS project. Why? Because things like authorization, multi-tenancy, user administration, and a relational schema builder are all native to the platform.

To summarize our points, Apito has many advantages including

  • Easy Learning Curve
  • Versatile Database Modeling
  • Robust Content Management System
  • Complex Query & Filtering
  • Role based Permissions
  • Build In Support for Multilingual Content
  • Instant GraphQL & REST API Endpoints
  • Webhooks
  • Authentication Module
  • Cloud Functions

Apito vs Firebase Comparison

GraphQL or RESTful API? Why not Both?

Today, almost all apps are data-driven. Making sure a developer has access to the data they need when they need it, and as they need it, is super important. For the past decade, REST has been the API standard. While the world has benefited hugely from REST, it has some limitations. GraphQL, on the other hand, comes with some huge advantages when compared to REST. A single endpoint can support any query or mutation (a.k.a. update).

Queries get defined on the client-side, meaning no more endpoint updates done by backend developers. Queries only return data that the developer wants. Out of the box, Firebase lets users build REST endpoints. You can set up a GraphQL engine on Firebase, but it takes a lot of time and a lot of know-how.

Role-Based Security

Meanwhile, as everyone is out there building the sleekest, and most straightforward user interface that enchants the pants off users, app security is too often being overlooked. That's why Firebase and Apito have security built directly into their products. Firebase offers the ability to set up role-based security using custom functions that get stored as rules. Every rule is then validated against each API requests.

The developer can define all their custom authentication logic. Apito built role-based security directly into its platform, and expose that to developers through a configurable interface. It makes adding permissions and roles for specific actions on specific tables and fields super straight forward. It also supports role-based scoping of records using custom filters. Pretty much, if developers follow either platform's documentation around how to set up authorization, they won't have to worry about security. It's just up to them how long they want to take to get there.

Conclusion

There are millions of developers in the world, each with their nuanced preferences to specific stacks and tools. In the greater software ecosystem, 1000s of tools and services exist to help support developers in building amazing apps. Of all the tools, services, frameworks, platforms, and specifications, only a few stand out.

Apito gives developers a back-end they need when building modern apps, the way that they would have wanted to build it themselves. By configuring dozens of clutch back-end resources and offering them as a production-ready platform, you can easily write your project-specific business logic with cloud function Knowing the whole time that security, scalability, database management, and the like are future proof.

A developer is going to come across both Apito and Firebase when researching backend-as-a-service platforms. Both platforms are going to offer them similar features that are backed by different implementations. That said, the experience that the developer has when using either platform is the real acid test.