A Deeper Look at V2 API: a Restaurant Model

A Deeper Look at V2 API

‍

Restaurant ModelAs an API provider, Brick understands that API new versioning is inevitable since our knowledge and experience of a system keep improving. Hence, we are releasing the new availability of our next generation APIs, V2, which aims to bring more scalability, security, exposure, and decentralized payment experience to supercharge any fintech companies in Southeast Asia.    

‍

‍

Then, what is the difference with V1?    

‍

Technically, V1 is a synchronous update in which the called transaction waits for any updates that it produces to be completed. While V2 is an asynchronous update in which the update is lined after the other and the system does not wait for the updates to complete. These updates are then triggered by an internally scheduled job which then updates the data in the database.    

‍

Let's deep dive more into synchronous and asynchronous to help you catch a glimpse of Brick new API versioning, V2.    

‍

From description to the analogy    

‍

Synchronous and asynchronous, you may have understood both concepts, especially in Open API architecture. These oftentimes are used by developers to provide a way to make immediate or scheduled requests for resources, data, or service when available. Although they have the same function, each of them actually has different methods and deliverables.     Synchronous  This API call means that you call a web service and wait until it returns. In other words, all additional code execution and user interaction are stopped until the call returns.    

This can be pictured in a real-life example of a restaurant.    

When you order meals, you need to go to the counter to get served. The waiter will note your orders and pass it to the kitchen so it will be prepared. If you see the service took so long, you might choose to leave without any meals. But if you'd like to stay and get your dishes prepared, you have to pay for it in the end.    

After you leave the restaurant with the meals in your hand, the waiter will serve the next customer and begin the same process as yours. So does when you leave.      

‍

Asynchronous  Differ than before, the async API call means that user does not halt other operations while waiting for the web service call to return. Other code executes, then the user can continue to interact with the page (or program UI).    

‍

Do you often go to a fast food restaurant? If so, you may understand the similarities flow between fast food restaurants and the asynchronous API.    

‍

Let's say, you order a cheeseburger and cola at the counter. After you pay for it, the waiter passes the order to the kitchen and continues to serve the other customer while the chef prepares the dish. Once your meals are prepared, the chef puts your order down on the delivery desk. Now the take-away manager will be in charge and tell the waiter that the particular order is ready so that the waiter takes the order and serves it to you.    

‍

But in this case, where the async will be?    

‍

When you finish the payment and wait for the dishes, the waiter will use their empty time to serve another customer. The same process as yours, once another customer purchases the order, the waiter passes the new order to the kitchen and continues to serve the others.    

‍

‍

Benefits of Asynchronous API    

‍

Users tend to think that asynchronous API means greater performance and speed, while in reality, executing several tasks may not have a direct impact in these areas.    

However, a few benefits still can be found to asynchronous API which you can learn more below:      

‍

1. Scalability    

As async is a well-known syntax structure of many programming languages, it enables asynchronous to work with promises effectively. Meanwhile, promises are the objects that digest the behavior of an asynchronous operation.    

Both concepts are inherent to the idea of scalability, which can take place in two ways ; horizontally and vertically.      

Horizontally: Synchronous and asynchronous programs can utilize this scaling by adding additional servers to scale the service.  

Vertically: This process can be simpler than horizontal scaling. Asynchronous programs can take advantage of this process to authorize one server in adding the number of requests a server can handle.      

By plugging in an async function, developers can simplify programs that were supposedly synchronous before by using promise-based callback methods.    

‍

2. User Experience    

When we compare to synchronous, asynchronous has the ability to better improve user experience in a variety of ways. This can be seen in the way the API of a program can load at one time. Hence, it results to quicker responsiveness and minimizes page load delays.    

‍

Again, the failure of a thread will not have a crucial impact on the others to run or render. So that, there is more availability due to asynchronous applications. ***