Skip to main content

5 posts tagged with "fahim"

View All Tags

· 4 min read

If you ever need a GraphQL API for your next project or trying to explore how GraphQL API works then Apito is a perfect place for you. You can create free GraphQL Api in Apito Easily.

Todo GraphQL Api

First, Create your project

Once you logged in to Apito Console you will a Project Space like below. You can use this space to switch between your projects or create a new one. Click on the Start a new Project button to initialize your project creation.

Apito Console

Using a Project Template (Optional)

You can jump start your project with a project template. Data and models will be prefilled on those templates based on your selection. You can also start fresh by selecting an EMPTY PROJECT. But for this project we will select a project tempalte called Todo Note

Apito Create a Project

Fill Up Your Project Details

In this step, Enter your Project Name and description and click and On Database option select Apito Cloud option to create your project faster.

info

Apito Cloud is a managed database and free of charge. If you select other options, then you have to provide your own credentials.

Create A New Project

Congratulation! your project is being build. Once it’s done you can click Explore new project to switch to your newly created project.

2. Add Models

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. Explore Both GraphQL & REST API

Our Application API is ready. To explore our API lets goto the API from the top of the navigation menu. You will be able to see two tabs.

  • GraphiQL Explorer
  • Swagger (REST)

If you are looking only for GraphQL api then dont worry. RESTapi is a bonus. Use it only if you want to.

Go to the GraphiQL Explorer and Let’s run our first query. We will now Find all the task with 'INPROGRESS' status. Now click Run and as you can see its filtering the result form the content. Now your is ready for integration.

Todo GraphQL Api

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

Todo Note Swagger Rest API

· 4 min read

Although headless content management systems are becoming more popular, you might be unsure if they are right for your upcoming project. I listed the benefits of the new strategy above conventional server-side CMS. Thus, you will be able to decide for yourself if Headless CMS will help your project succeed or not.

What is a Headless CMS?

Simply said, it is a separate admin panel that is just responsible for managing and storing content. It offers front-end (the presentational portion of the website) access to the material through API. By doing this, we assign the Front-end framework and CMS different roles in terms of delivering and storing material. Everything will carry out its finest function.

It is comparable, for instance, to a Wordpress admin panel without a direct link to the website. There, you solely keep track of your posts and page information. While the front end is distinct and uses the CMS's data exclusively through its API,

Better Performance

What benefits would a greater performance have for you first? More than 53% of consumers would abandon a website if it takes longer than three seconds to load, according to Google's research. Imagine that if your mobile site is sluggish, over half of your readers will stop visiting. And according to additional Google data, the majority of websites take more than 3 seconds to load. In order to differentiate yourself from the competition, go fast.

The study was illuminating. The visual material above the fold took longer than 5 seconds to load on 70% of the mobile landing pages we examined, and it took longer than 7 seconds for all visual content above and below the fold to fully load.

The installation of the front-end is completely under your control, which results in the high performance of websites powered by Headless CMS. Headless CMS is not overloaded with additional presentational logic code at the same time. Therefore, coders just use what is required and omit the extra. The majority of optimizations are also handled by contemporary front-end frameworks.

Lower time to Market, Faster Development

Your chances of success increase the quicker you test your ideas and bring them to market.

Since you don't have to spend time on finding workarounds and addressing issues in order to incorporate a not trivial feature, developing websites using Headless CMS is often faster. Without being constrained by the CMS, you create the front-end in your own style.

Front-end With the use of frameworks, high-quality websites may be created quickly. The support, editing, and scaling of websites created using frameworks is simpler.

Highly Customizable & Flexible Front-end

You have control over how users interact with your site thanks to the flexibility of the front-end solution. You may now build features that server-side CMS just couldn't support. Your website's UX may be customized to support your objectives, whether they be more readers, subscribers, or customers.

Due to the division of labor between your front-end display and headless CMS, websites are able to be more flexible. Because of the numerous limitations of traditional CMS, developers must frequently discover workarounds to add functionalities.

Cross-platform content Delivery

REST API is used by Headless CMS to give data. Thus, it is not dependent on a certain tech stack. Using the same technology, you may even include material into an application that has already been created.

Regardless of the program you use—web, desktop, or mobile—you can access your material. This can help you save time and money.

Conclusion

Undoubtedly, there are many benefits to adopting a novel approach to website development and content delivery. But that does not imply that it is always the best option. With this knowledge, I hope you can make an informed decision and select the finest technological solution for your objective.

Just to be clear, I prefer utilizing headless content management systems and front-end React frameworks like Next.js or Gatsby to construct my websites and the websites for my clients.

Enjoy your day and create awesome websites!

· 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

· 9 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


On Using Both!

Apito Console generates both GraphQL & RESTful apis from the model you specify. Both rest & graphql has their own pros and cons. there is no general rules on if you are using graphql then you cant use rest api in your application! One example here where both is usable is the use of media. if your app has a media/file uploader then graphql is not build to handle multi-part data. In that case you can use graphql for content and rest api for file/media upload.

Thx to Apito you have the power of both. Use accordingly.

Working with REST APIs

The endpoint, HTTP method, header, and body make up a REST request with An endpoint includes a URI (Uniform Resource Identifier), which aids in online resource identification.

The type of request made to the server is described by an HTTP method. As follows:

  • GET reads a representation of the source that is supplied.
  • POST Creates a new resource.
  • PUT replaces or updates all the collection's resources.
  • PATCH changes the resource.
  • DELETE is used to remove a resource.

A RESTful API employs HTTP methods to carry out CRUD (Create, Read, Update, and Delete) processes while interacting with data. In order to facilitate caching, AB testing, authentication, and other processes, headers offer information to clients and servers.

The body houses data that a client wishes to transmit to a server, such the request's payload.

What is GraphQL?

Simply, A GraphQL is used to answer queries with already-existing data. GraphQL is an open-source data query and manipulation language for APIs. GraphQL is mostly maintained and developed by the GraphQL Foundation and has been used widely across many industries and use cases by businesses like Twitter, Expedia, Shopify, and Github, to mention a few.

Advantages of GraphQL APIs

Let's go through some of the fundamental benefits that make GraphQL unique.

Data Fetching, Filtering and Queries

Overfetching and Underfetching are two of REST's most frequent default limitations. This occurs as a result of a client's dependence on endpoints that only deliver fixed data sets in order to download data. It's incredibly challenging to create an API that can provide users the precise data they want.

Overfetching means getting more information than you need. For example, if the endpoint holds data on a user employed at a company, you’d hit the /profile endpoint in case of a RESTApi, and instead of only getting the names that you’re interested in, you will get everything that endpoint has to offer - including age, pictures, address, and lots of personal information etc which you might now need. With GraphQL, you’d simply need to dictate what you want in a query:

{
profile {
name
avatar {
url
}
}
}

You would receive a predictable dataset to work with based on what you asked since your response wouldn't contain any more data that the endpoint might be able to offer.

Typed Schema and Type Safety

A highly typed system is used by GraphQL to specify an API's capabilities. The GraphQL Schema Definition Language (SDL) and/or code-first are used to create a schema that lists all the types that are available in an API.

Now that the GraphQL API is typed, frontend teams can work with it with confidence, knowing that if the backend team makes any changes to the API's architecture, they will receive immediate feedback when querying it from the frontend.

The code for queries and modifications may be generated automatically from your codebase's GraphQL query files using well-known tools like the GraphQL Code Generator. As a result, development is sped up and production faults are avoided.

Faster Product Development

When using REST APIs, it's usual practice organizing the endpoints into groups based on the views that are present in your app (for instance, /author, /books, /orders, etc.). This is convenient as it enables the client to obtain all necessary data for a certain view by only contacting the associated endpoint.

This method has the downside of not allowing for quick iterations. There is a chance that the amount of data needed will increase (or decrease) depending on the UI update being made.

In order to accommodate those additional data requirements, the backend must also be modified, which is counterproductive and slows down the product development process.

With GraphQL's flexibility without requiring additional server effort. Clients may declare their specific data needs, thus there is no need to modify the backend when the design or data requirements on the frontend change.

Schema Stitching

The capability of stitching schemas is a significant differentiator. To make numerous schemas accessible to the client, GraphQL may merge them into a single schema. For instance, combining the Burgers API and Nutrition API schemas by combining the information from several sources about a certain menu item's nutrition information.

{
books(
where: { name: "harry"}
)
# from Menu endpoint
title
description
price
# from Recommendation endpoint
similar {
books {
id
title
}
}
# from Order endpoint
inStock
}

GraphQL vs. REST

The primary distinction between GraphQL and REST APIs is that the former is an architectural framework for network-based applications, while the latter is a query language standard.

Strongly typed GraphQL is ideal for reducing development time since it interacts with code generation tools, is self-documenting based on schema types and descriptions, and is strongly typed.

In very basic terms, the ordering of hamburgers can help us understand one of the most well-known distinctions: the variations in expected answers to inquiry. Although the GraphQL burger meme has been around for a while, the explanation it offers still makes the fundamentals easy to understand.

https://api.com/cheeseburger/

You may "have it your way" using GraphQL by expressing how you want that cheeseburger to be made. You may now order a cheeseburger (reaction) without a bottom bun, with a bun on top, a patty, pickle, onion, and cheese (unless you're vegan).

query getCheeseburger ($vegan: Boolean) {
cheeseburger {
bun
patty
pickle
onion
cheese @skip(if: $vegan)
}
}

Your GraphQL answer is formatted and scaled precisely as you specify. Nothing more, nothing less, and nothing different about your response from what you asked for or desired.

Conclusion

For network-based applications, a REST API is a "architectural notion." On the other side, GraphQL is a query language and collection of tools that work with just one endpoint. Additionally, during the past several years, REST has been utilized to create new APIs, whereas GraphQL has been primarily focused on performance and flexibility optimization.

You would most likely receive whole "datasets" as a response while utilizing REST. You would need to make x REST API queries in order to get information from x objects. Your inquiries may take the following form if you're looking for product details for a menu website:

Request menu for burger names, descriptions, ingredients, etc. in one request in another Request prices for prices pertaining to that menu and in another request images for menu shots from another dataset... and so on

In contrast, if you wanted to gather data from a particular endpoint, you couldn't restrict the fields that the REST API returned since, when used without further parameters, it always overfetches the whole data set.

The request may be tailored to exactly what you need, from many objects down to individual fields inside each entity, using GraphQL's query language. GraphQL would require the x endpoint, and it can do a lot with that data, but you must first specify your goals for it.

The request would be limited to getting the same endpoint's menuItem, menuIngredients, menuImage, and menuPrice in a single request, using the same example. The database's other material wouldn't be returned

Similar to the earlier burger analogy, GraphQL allows you to customize the cheeseburger you receive through REST to include exactly the amount of your choice of toppings.

Choosing GraphQL over REST or in conjunction with it is a very individualized choice that is greatly impacted by the use-case. It's crucial to remember that GraphQL is neither a substitute for REST nor an alternative. Here are some crucial distinctions to assist make that choice easier:

GraphQLREST
A query language for solving common problems when integrating APIsAn architectural style largely viewed as a conventional standard for designing APIs
Deployed over HTTP using a single endpoint that provides the full capabilities of the exposed serviceDeployed over a set of URLs where each of them exposes a single resource
Client-driven architectureServer-driven architecture
Uses caching automaticallyLacks in-built caching mechanism
Better API versioning SystemComplicated API version Support
Response supports only JSONXML, JSON, and YAML
Offers type-safety and auto-generated documentationDoesn't offer type-safety or auto-generated documentation
Allows for schema stitching and remote data fetchingSimplifying work with multiple endpoints requires expensive custom middleware
Build in Validation based on SchemaNo Build In Validation
Single EndpointMultiple Endpoints

· 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.