GMT Token

gmttoken

Coinbase is the largest cryptocurrency exchange in the USA. It’s called the industry’s unicorn and a leader in mergers and acquisitions with the biggest influence across the USA market. The platform is second only to Binance in terms of trading volume while adhering to the rather old-fashioned policy in the listing procedure, which is why Coinbase supports fewer assets than Binance. Over the years, there has been a trend noticed around Coinbase - when a coin is listed on the exchange and announced on media, this sharply moves its rate upward. But, does it always work so with Coinbase, or is this only a short-term trend? Let’s try to figure it out today. Incredible Growth But Only Temporary Let’s consider the example of OmiseGO (OMG) that was listed on Coinbase. We can see, OMG rate multiplied on the first day of listing on Coinbase, followed by a sharp drop right after it soared. The number of OmiseGO addresses increased by 99,6% a day before the listing, compared with the number of addresses fixed the day before. The total number of active addresses was the biggest since November 2018. On May 21, the number of on-chain transactions increased by 83,9% compared with the previous day, reaching the highest level ever. The same thing about Chainlink - the rate grew from $2,60 to $5,10 before the listing and dropped to $3,80 afterward. Similarly, with OmiseGO, the number of active addresses registered and transactions in Chainlink reached its maximum level on a listing day. Another example is MKR listing (the token of the DeFi project MakerDAO), we can see its rate skyrocketed 40% right after its listing was announced on Coinbase. It was followed by short correction of the price. The token’s rate went up just before the listing, reaching its all-time high of $730. However, the MKR price showed a downward trend right after the start of the trades. This phenomenon can be explained by too many rumors and hype around the coin before its listing, for all the cases we consider in this article are followed by sharp price growth right before the trades start, and the closer to listing - the bigger the price growth rate we observe. And in the end, harsh correction in all the cases. This phenomenon got the name “the Coinbase effect,” and it was noticed that it takes place simultaneously with increasing on-chain activity. Probably the loudest skyrocketing rate was noticed when Bitcoin Cash (BCH) was listed on Coinbase. It was in late 2017 - that was the peak of the crypto market when Bitcoin was about to reach $20 000 with a market cap of $800 billion. Once Coinbase announced support for the main Bitcoin fork, its rate soared to almost $4000, but the trades were ceased in a couple of minutes, for volatility was too high, and the growth was recognized as suspicious. Similar to the cases we mentioned before, the sharp upward rate movement followed after the Coinbase announcement. As a matter of fact, the BCH rate skyrocketed even higher up to $9500 from about $2400-2500 level on the former GDAX  exchange (now Coinbase Pro). The same drop followed once the trades ceased. A similar situation happened with XRP, Dash, Zcash listing, as well as many others, following with sharp price soaring and the same sharp drop afterward. Looking at such sharp volatility fluctuations on the listing eve and right after the trades are opened, the company’s CEO supposed insider trading might occur and promised to figure it out. The company even received a class action blaming Coinbase for insider trading during the BCH listing. No proof was found, though. One of the latest situations of unnaturally sharp volatility was fixed with the DeFi token Compound listing when the COMP rate fell right after the trades were opened. The asset trades opened at $400 and dropped twice. The reason may be that some early investors wanted to make money on the hype around COMP, for its rate was moving steadily up before the listing on Coinbase. When the trades were opened, there were 25 transactions fixed each for 2000 COMP to the exchange wallets. Listing on Binance This is the largest exchange in terms of trading volume, with strict conditions for listing which are not clearly defined in any source. The head of the trading platform says that they reject 97-98% of applications. Requirements for applications: -fill out the form on binance.com, providing the information about your project; -send the application and wait for the answer. The stage of the application consideration can be known on binance.com only, so it does not make sense to write to tech support or reach Binance management on their social networks. Criteria when considering an application: -applicants trying to put pressure on the Binance managers are dropped out; -promises to pay million dollars for listing will not work either - the company values reputation first and foremost; -the exchange is favorably disposed to projects and companies that used to help promote BNB - the native token of Binance. -when evaluating a project, the Binance team carefully analyzes its usefulness, applicability for solving actual problems, the audience interested in it, listing on other exchanges, and trading volume; -it does not matter how much you are willing to pay for the listing - it will not work. The developers of “shit coins'  would pay any amount of money for listing on such a large player as Binance, but they are out, so money - in any amount - is not a ticket to Binance listing. The exchange definitely charges some fee for listing, but there is no certain information about it, nor does the Binance head comment on this issue. GMT Token’s case GMT Token company is working to make it to Binance - the largest crypto platform that affects assets' rates equally or even more than Coinbase. According to our sources, in 2022, GMT will start to implement the next stage of its strategy. Besides using their mining capacities, the team will attract other participants in the mining market to place their equipment in the project’s ecosystem. New miners will be offered to place their equipment in GMT data centers. In return, miners will receive GMT tokens in an amount proportional to the power security. Part of the tokens will be burned, and the released power will be distributed among all tokens in circulation. If this strategy is implemented successfully, the token power security will sharply increase, and its value may reach $1.5 in the next 12 months. It is clear from the foregoing why the company did not rush to receive a listing on Binance and preferred local exchanges instead. Now listing on Binance looks quite logical in 2022. Other Factors However, the Coinbase effect seems to be overestimated, for, as a matter of fact, the announcements of new tokens to be listed on the exchange usually cause their price fluctuations within -1% - +14% related to USD, BTC, ETH. Experts estimated that the exchange announcements have no significant influence on general market trends of the assets announced. They studied 16 assets added to the exchange, and 6 of them showed a downward trend within 10 days after the listing, while only 3 raised less than 5%. So on average, the fluctuation was estimated at +4%. As for Coinbase announcements and their effect on the asset rates, here experts see the bigger reason is a general market trend happening along with short-term effects from the exchange announcements. For example, in 2018, most of the assets went down during the bearish market trend. In 2019 the rates moved up and down. So it appears that the dynamic largely depends on the market trend at the time when the asset was listed, while Coinbase news mostly bears a short-term effect on the assets rates. Most crypto assets did not maintain high prices and dropped in a few days after listing, which refers to the assets with low liquidity (LOOM, CVC). Some kept their prices at the same high level (GNT), while others skyrocketed (OMG, XTZ). The Block research shows the following dynamics on the day when Coinbase announced listing: The assets grew by 9% towards USD and 8%  to BTC on average. 14 out of 16 assets showed a positive trend. Then the rates dropped during 24 hours from the trades opening, 1%  towards USD per day on average. 5 out of 19 assets showed a positive trend. Within a week after listing, most of the assets kept on downward movement -3% towards USD and -1% to BTC on average. 2 out of 19 assets showed a positive trend during the week, especially Chainlink we have mentioned before. In a month after the listing, the drop was estimated at -6% on average: 5 out of 19 assets grew towards USD and BTC, especially Zilliqa, which did not show an upward trend the first day after the listing. Wrapping Up We can’t put it all on the Coinbase effect and blame it for those impulse assets fluctuations after the listing, for there may be several reasons, and the biggest might be a general market trend. The upward trend of new-added coins on the exchange is usually of short-tern nature, and it does not last long if the market is bearish. Besides, we should also keep in mind the level of assets’ liquidity, which also plays an essential role in future rate changes. Trying to grab coins and wait for the rate boost, trying to make a big deal of fortune, we should bear in mind that such trading activities are pretty risky, and we should be especially careful and remember that there are plenty of factors influencing the prices and behavior of the asset. So, to some extent, those huge rate fluctuations might be caused by the Coinbase effect, but it would be naive to think it's all about the exchange announcements. It is recommended to make a big deal of research across the cryptocurrency and the factors that might be crucial in its rate changes before investing in this or that digital asset.

What is the Coinbase Effect and is it Worth Relying On

Crypto mining has garnered a lot of popularity in recent months, and it is for both right and wrong reasons. The growing crypto buzz has so much shifted the attention of most people to the end-product, and every few people care to know how these digital assets come about. Today, different governments are clamping down on mining due to its environmental impact. The is currently cracking down on crypto miners, and the resultant effect has reverberated across the crypto space. Although other countries like Thailand are also cracking down on crypto mining, China stood out because Chinese government more than 60% of miners are based in China. On the other hand, the government of is working on utilizing volcanic energy to mine bitcoin. This will be a total shift from the use of non-renewable sources of energy that is harmful to the environment. For those of you who might be wondering what crypto mining is, adding transaction records to the blockchain protocol is the process of adding transaction records. In order to add the record to the blockchain, the miner must have to solve a computational puzzle. El Salvador Mining is essential in the crypto space for many reasons do not just add any transaction record to the blockchain network; these transactions are vetted and verified to be correct. Therefore, without the mining process, there will be no way to ensure the integrity of the blockchain protocol. With their power-intensive computers, these miners can listen to transaction requests across the entire blockchain network and sort out the valid ones. Crypto miners Just like bank tellers, these miners check to ensure all things are in place before validating a transaction. Miners lookout for two things while validating a transaction. First, they check to make sure that the digital signature of the recipient of an input proves that they are the right person to get the input. Secondly, miners also help to make sure that the recipient is yet to use that input. Crypto mining helps prevent a problem known as “double spending,” a form of high-tech counterfeiting. Imagine a user say Dave has $10 and gives it to Jane. Can Jane be certain that she has received $10 from Dave and is not fake? It would have been easy in real life, but it is not that simple in the digital world. Upon validation, if transactions fail to check due to counterfeiting, miners will not record that transaction, and the fraud will be averted. Although crypto mining has lots of benefits, two major problems have cast a big shadow on mining The computational puzzle that miners need to solve before adding a block to the already existing blockchain requires enormous hardware. This hardware is known as Application-Specific Integrated Circuit (ASICs), and they consume a lot of energy. According to the , bitcoin has the same energy consumption rate as Argentina. This means miners spend a lot of money on energy to power their equipment. Cambridge Bitcoin Electricity Consumption Index The doesn’t come cheap, and you will need hundreds of them to execute a mining process. With this expensive AISC equipment, not everyone can get into the business of mining cryptocurrency. However GoMining is already the problem of the high cost of equipment -  the company has created a token (GMT) that allows holders to earn income from mining without having to own any ASIC equipment. Therefore, instead of owning the expensive and energy-intensive ASICs to mine bitcoin, holders of the GMT token can share the mining income generated by the company's fleet of devices. Application-Specific Integrated Circuits solving There are other companies also seeking to offer a better solution to the problems of mining. Gryphon Digital Mining platform is planning on creating the largest bitcoin miner with little or no carbon footprint. Another company that is working to solve the high energy consumption rate of mining is Mercuria. According to the CEO, , the company is seeking to partner with crypto miners and supply them with renewable energy for their mining processes. This will help reduce the emission of carbon (IV) oxide emission associated with non-renewable energies. Marco Dunand Conclusion The concept of mining is integral and essential to the future of cryptocurrency and blockchain networks. Government should be more diplomatic in its clampdown on crypto mining. Instead of shutting down a mining site, there should be a roadmap that miners should follow in order to achieve a robust and environmentally friendly. Also, more crypto projects need to rise to the occasion in tackling the problems of mining.

The Rising Popularity of Crypto Mining

Using Firebase Authentication with the Latest Next.js Features

সর্বশেষ Next.js বৈশিষ্ট্য সহ Firebase প্রমাণীকরণ ব্যবহার করা

Verwenden der Firebase-Authentifizierung mit den neuesten Next.js-Funktionen

Uso de la autenticación de Firebase con las últimas funciones de Next.js

Utilisation de l'authentification Firebase avec les dernières fonctionnalités Next.js

नवीनतम Next.js सुविधाओं के साथ फायरबेस प्रमाणीकरण का उपयोग करना

Usando o Firebase Authentication com os recursos Next.js mais recentes

Использование аутентификации Firebase с новейшими функциями Next.js

Firebase Kimlik Doğrulamasını En Son Next.js Özellikleriyle Kullanma

Sử dụng Xác thực Firebase với các tính năng Next.js mới nhất

将 Firebase 身份验证与最新的 Next.js 功能结合使用

Hey everyone! I recently tackled the task of integrating Webflow OAuth into my app, and as someone who doesn't code, I wanted to share my approach using Xano as a backend and Webflow as a frontend. If you're a coding pro, please bear with me—no throwing rotten tomatoes! This is one no-coder to another, hoping to smoothen your journey a bit. TLDR: I've compiled every step into a video for those who prefer visual learning, but you'll find a detailed text version of the process below. https://youtu.be/bTUatl6eTec?embedable=true Understanding OAuth Let's quickly grasp the fundamental concept of how OAuth operates. Picture this: you're on holiday and want to rent an apartment in a foreign country. You find an apartment building where you can rent a unit. Upon arrival, instead of being given keys to all the flats, the owner sends you a one-time code to access your specific flat's key lockbox. You use this code to open the lockbox and retrieve a key card, granting you access to the apartment during your stay. In this analogy, Webflow represents the apartment owner, the one-time code serves as an access code, and the key card is analogous to an access token. If you need access to any information about a user's Webflow projects—such as lists of pages, assets, collections, or forms—you'll require an access token. This token is used with any API requests sent to Webflow on behalf of the user. In the example below, I'll demonstrate building a simple Webflow app that displays information about the user's project without storing the access token in my database (although in real-world scenarios, it's advisable to store tokens associated with users). Step 1: Create a New Webflow App Navigate to your Webflow dashboard's "Apps & Integrations" tab and create a new app. Provide general information about your app, including its name, description, and home page URL. Specify the required permissions—I'll use a data client app in my example, granting "Read" access to "Sites." You can adjust these permissions later if needed. The crucial pieces of information we need here are the and , automatically generated for your app. Leave the Redirect URL field blank for now; we'll revisit it in the next step. Client ID Client Secret Step 2: Setting Up a New Webflow Project as the Frontend Create a new Webflow project with two pages: Home and Sites. On the Home page, add a button labeled "Show Sites," which will trigger a request to Webflow for the access code. Set the button's URL to , replacing YOUR_CLIENT_ID with the actual Client ID obtained earlier. Adjust the URL if your app requires additional permissions. https://webflow.com/oauth/authorize?response_type=code&client_id=YOUR_CLIENT_ID&scope=sites%3Aread Clicking this button will display a permissions screen to the user, allowing them to choose which projects to grant access to. Upon authorizing the app, they'll be redirected to the Redirect URL—remember to copy the URL of the Sites page (the second page you created) and paste it into the Redirect URL field of your app. Upon completing this step, clicking "Show Sites" will redirect users to the Sites page, with the access code included in the URL. Step 3: Setting Up a Xano Project and Creating the First API Create a new project in Xano, and navigate to the APIs tab. Add a new API Group, and then within that group, add a new API Endpoint—let's call it "getToken." In the "getToken" endpoint: Add a text input named "accessCode" to receive the access code from the frontend. Make a POST request to with body parameters: https://api.webflow.com/oauth/access_token client_id: Your Client ID client_secret: Your Client Secret grant_type: authorization_code code: accessCode (using the variable from the input) Define the output of the first API request as "accessToken," which will be the access token associated with the user. Make a second API request (for demonstration purposes) to retrieve the user's site list—a GET request to . Include the following headers: https://api.webflow.com/v2/sites accept: application/json authorization: accessToken.response.result.access_token Define the output of the second API as "siteList," which represents the list of Webflow projects. Return the "siteList" in the response. Copy the API endpoint URL for later use. Step 4: Configuring a Frontend Request From Your Webflow Project Return to the Webflow project and open the Sites page—the page where users are redirected after granting access to their Webflow projects. Here, add the following JavaScript functions in the custom code area before the </body> tag. First, let's create the function to retrieve the sites: getSites() function getSites() {
  const url = window.location.search;
  const params = new URLSearchParams(url);
  const accessCode = params.get('code');
  const options = {
    method: 'POST',
    headers: {accept: 'application/json', 'content-type': 'application/json'},
    body: JSON.stringify({accessCode: accessCode})
  };
  fetch('YOUR_API_ENDPOINT', options)
    .then(response => response.json())
    .then(response => {
      const siteList = response.response.result.sites;
      showSites(siteList);
    })
    .catch(err => console.log(err));
} Then, let's create the function to display the retrieved sites: showSites() function showSites(sites) {
  const container = document.querySelector('#result');
  sites.forEach(site => {
    const siteDiv = document.createElement('div');
    siteDiv.classList.add('site');
    const siteContent = 
      `<h2>${site.displayName}</h2>
       <p><strong>ID:</strong> ${site.id}</p>
       <p><strong>Workspace ID:</strong> ${site.workspaceId}</p>
       <p><strong>Short Name:</strong> ${site.shortName}</p>
       <p><strong>Time Zone:</strong> ${site.timeZone}</p>
       <p><strong>Created On:</strong> ${site.createdOn}</p>
       <p><strong>Last Updated:</strong> ${site.lastUpdated}</p>
       <p><strong>Last Published:</strong> ${site.lastPublished}</p>
       <img src="${site.previewUrl}" alt="Preview">
     `;
    siteDiv.innerHTML = siteContent;
    container.appendChild(siteDiv);
  });
} Lastly, ensure that the function runs on page load: getSites() document.addEventListener('DOMContentLoaded', function() {
  getSites();
}); And there you have it! I hope this guide proves helpful for my fellow no-coders! Feel free to reach out if you have any questions or need further clarification. Happy coding!

No-Code Webflow OAuth: Make Authenticated Requests to the Webflow API Using Xano

নো-কোড ওয়েবফ্লো OAuth: Xano ব্যবহার করে Webflow API-তে প্রমাণীকৃত অনুরোধ করুন

No-Code-Webflow-OAuth: Stellen Sie mit Xano authentifizierte Anfragen an die Webflow-API

Webflow OAuth sin código: realice solicitudes autenticadas a la API de Webflow utilizando Xano

No-Code Webflow OAuth : effectuez des requêtes authentifiées à l'API Webflow à l'aide de Xano

नो-कोड वेबफ़्लो OAuth: Xano का उपयोग करके वेबफ़्लो API के लिए प्रमाणित अनुरोध करें

ノーコード Webflow OAuth: Xano を使用して Webflow API への認証済みリクエストを行う

코드 없는 Webflow OAuth: Xano를 사용하여 Webflow API에 인증된 요청 만들기

No-Code Webflow OAuth: Faça solicitações autenticadas para a API Webflow usando Xano

OAuth Webflow без кода: выполнение аутентифицированных запросов к API Webflow с помощью Xano

Kodsuz Webflow OAuth: Xano Kullanarak Webflow API'sine Kimliği Doğrulanmış İstekler Yapın

OAuth luồng web không mã: Thực hiện các yêu cầu được xác thực đối với API luồng web bằng Xano

无代码 Webflow OAuth：使用 Xano 向 Webflow API 发出经过身份验证的请求

Hello everyone! Reading emails in automated tests is a trick that you might need to know how to do in a lot of the projects. Here’s why and how to deal with it… Why Is This Important? Well, if the system sends emails - you might want to verify that they are being sent and the content is right, including clickable links. So these are the usual scenarios when you need this: Sign up. A lot of platforms send a confirmation email once you create an account, and you need to click a confirmation link from the email. Invoices. If your app does any payments - they usually send a cheque or invoice via email, so you might want to see if their contents are correct too. Results. Like medical test results. In my experience - some hospitals send an email with test results once they are done (or at least a link to a personal page where you can view the report). … Of course, this is not the complete list - these are just the use cases I’ve met the most in my career. Failing to verify these scenarios might lead to users not getting emails or getting the wrong information in emails. In one of the projects, it helped us find early an expired token. SendGrind What Are the Complications of Reading Emails in Tests? Reading emails is a tricky thing to do, but not an impossible one. Early email clients were using to fetch emails from the server, but there’s a small problem - it deletes the emails from the server once they are downloaded. POP3 Later, protocol came in - it allows you to simply read emails from the server. IMAP The problem is - or when you connect for the first time (like when you restart an automated test). some services ban these protocols make you confirm your identity On the other hand, some services like provide a to manipulate your emails, but there’s another problem - the documentation and its libraries are not really that user-friendly (especially for those who don’t work with email testing much). Gmail REST API This is where comes in - an library that allows you to read emails and even open them in your browser if you use browser automation tools like . gmail-getter npm Playwright Reading Gmail Emails With Gmail-Getter First thing first - you need to install the package in your project: npm install gmail-getter Create a Google Cloud Console Project, and Obtain Credentials To log into you need to obtain credentials: a , a , and a . These credentials let you get an Access token, which is required in further requests (like getting a list of emails or a single email, etc.). Gmail API, Client ID Client Secret Refresh token Steps to go: Create a project in . Google Cloud Console Create in the section ( ) and download it. OAuth credentials API & Services preferably, select app there if you need it for automated tests Desktop Enable the . Gmail API Obtain a Refresh token. To get a Refresh token - simply execute a command in a project root: npx gmail-getter get-refresh-token (or anywhere else if you've got the package installed globally) get-refresh-token You must put the file in a place where you will execute the command. credentials.json ⚠️ credentials file name is case-sensitive ⚠️ Obtain Access Token Once the configuration is done, you must get an Access token in your automated tests. I’d say that the best place for it is a global setup (a function that executes before the test run starts). So, it’ll be something like this: import {getToken} from 'gmail-getter'

export default async function globalSetup() {
  process.env['ACCESS_TOKEN'] = await getToken(
    process.env.CLIENT_ID!,
    process.env.CLIENT_SECRET!,
    process.env.REFRESH_TOKEN!
  )
} The example above uses environment variables, for which you will definitely need to install the package as well. dotenv But, if you wanna keep things simple - you can use this snippet wherever you need the token to be accessible from: const accessToken = await getToken(
    '<put-your-client-id-here>',
    '<put-your-client-secret-here>',
    '<put-your-refresh-token-here>'
  ) Get Emails Right now, uses to find the email you need: Gmail’s REST API its own query language const email = await checkInbox(accessToken!, 15000, 1500, 'from:squier7 subject:Test!') The command above returns you an email object, but you still need to get either its contents or a link. Replace to your own query following the syntax from the link above ☝️ from:squier7 subject:Test! You can parse a link using : a regex const link = parseLinkFromHtml(email!, /(https:\/\/)(\S*)(gmail-getter)([\w\/\?\=\-]*)/im) Replace with your own regular expression ☝️ /(https:\/\/)(\S*)(gmail-getter)([\w\/\?\=\-]*)/im OR get the whole HTML content of the email, and render it in your browser: import {getToken, parseHtml} from 'gmail-getter'
import {test} from '@playwright/test'

test('Render an email', async ({page}) => {
  const accessToken = await getToken(
      '<put-your-client-id-here>',
      '<put-your-client-secret-here>',
      '<put-your-refresh-token-here>'
    )

  const email = await checkInbox(accessToken!, 15000, 1500, 'from:squier7 subject:Test!') // get an email
  const html = parseHtml(email!) // parse HTML from the email
  await page.setContent(html) // render the email in the browser
}) Overall I think it’s pretty obvious now that working with emails in automated tests might be tricky! But knowing these tricks makes things much easier. You might still go through some other email services or try , but I guarantee you - it won’t be as easy as it is in this guide, as you’d need to create a helper of your own, like provided here. IMAP gmail-getter You can find the on . too. Playwright example GitHub Cypress example

How to Read Gmail Emails With Playwright

নাট্যকারের সাথে জিমেইল ইমেলগুলি কীভাবে পড়বেন

So lesen Sie Gmail-E-Mails mit Playwright

Cómo leer correos electrónicos de Gmail con Playwright

Comment lire les e-mails Gmail avec Playwright

नाटककार के साथ जीमेल ईमेल कैसे पढ़ें

Playwright で Gmail メールを読む方法

극작가와 함께 Gmail 이메일을 읽는 방법

Como ler e-mails do Gmail com o Playwright

Как читать электронные письма Gmail с помощью драматурга

Oyun Yazarı ile Gmail E-postaları Nasıl Okunur?

Cách đọc email Gmail với nhà viết kịch

如何使用 Playwright 阅读 Gmail 电子邮件

Introduction Angular is a popular front-end framework used for building dynamic web applications. One of its essential features is making API requests to fetch and manipulate data from external sources. However, doing this correctly is crucial to ensure your application's performance, security, and maintainability. In this comprehensive guide, we will dive into the best practices for handling API requests in . Angular Understanding API Requests What Are API Requests? API, which stands for Application Programming Interface, is a set of rules that allows different software applications to communicate with each other. API requests, in the context of web development, involve sending and receiving data between a client (your ) and a server (the external data source) using HTTP protocols. Angular application In Angular, you often make API requests to retrieve data from servers, update information, or perform other actions such as authentication and authorization. These requests can be of various types, including GET (retrieve data), POST (send data), PUT (update data), and DELETE (remove data). Why Proper API Request Handling Matters Properly handling API requests is essential for several reasons: Inefficient API requests can slow down your application. Optimized requests ensure a smooth user experience. Performance: Securely handling requests prevents vulnerabilities like cross-site scripting (XSS) and cross-site request forgery (CSRF). Security: Well-organized API request code is easier to maintain and scale as your application grows. Maintainability: Handling errors gracefully helps you provide informative feedback to users. Error Handling: Now, let's explore the best practices for making API requests in Angular. Best Practices for API Requests in Angular 1. Organize Your Code Follow the MECE (Mutually Exclusive, Collectively Exhaustive) principle to organize your API request code. Group related API requests into services and keep them separate from component logic. This makes your codebase more structured and maintainable. // Example of an API service
@Injectable({
  providedIn: 'root',
})
export class DataService {
  constructor(private http: HttpClient) {}

  getPosts(): Observable<Post[]> {
    // API request logic
  }

  createPost(newPost: Post): Observable<Post> {
    // API request logic
  }
} 2. Use Angular's HttpClient Angular provides the module for making HTTP requests. Use it instead of the older module, as offers features like strong typing and interceptors for handling requests and responses. HttpClient Http HttpClient import { HttpClient } from '@angular/common/http';

constructor(private http: HttpClient) {} 3. Set a Base URL Define a base URL for your API requests to avoid repeating the same URL in multiple places. You can set this in your environment configuration for flexibility between development and production environments. // environment.ts
export const environment = {
  production: false,
  apiUrl: 'https://api.example.com',
}; // Service
import { environment } from 'src/environments/environment';

@Injectable({
  providedIn: 'root',
})
export class DataService {
  private apiUrl = environment.apiUrl;

  constructor(private http: HttpClient) {}

  // Use this.apiUrl when making requests
} 4. Use RxJS Observables Angular leverages RxJS Observables to handle asynchronous data streams. Embrace Observables when making API requests to manage data flow effectively and handle events like data updates and errors. getPosts(): Observable<Post[]> {
  return this.http.get<Post[]>(`${this.apiUrl}/posts`);
} 5. Implement Error Handling Always include error handling in your API requests. You can use the operator to gracefully manage errors and provide meaningful feedback to users. catchError import { catchError } from 'rxjs/operators';
import { throwError } from 'rxjs';

getPosts(): Observable<Post[]> {
  return this.http.get<Post[]>(`${this.apiUrl}/posts`).pipe(
    catchError((error) => {
      // Handle the error and optionally log it
      console.error('API Error:', error);
      return throwError('Something went wrong. Please try again later.');
    })
  );
} 6. Use Interceptors are middleware functions that can preprocess requests and responses globally. You can use interceptors for tasks like adding headers, handling authentication, or logging requests. Angular interceptors @Injectable()
export class AuthInterceptor implements HttpInterceptor {
  constructor(private authService: AuthService) {}

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    // Add authentication token to the request headers
    const token = this.authService.getToken();
    if (token) {
      request = request.clone({
        setHeaders: {
          Authorization: `Bearer ${token}`,
        },
      });
    }

    return next.handle(request);
  }
} 7. Optimize HTTP Requests To optimize your application's performance, reduce unnecessary HTTP requests by caching data when appropriate, and use techniques like lazy loading for modules that make API requests. 8. Implement Pagination and Filtering For large datasets, implement pagination and filtering on the server side to minimize the amount of data transferred in each request. Pass pagination and filtering parameters in your API requests. 9. Secure Sensitive Data When dealing with sensitive data, use HTTPS for secure communication and ensure your server-side endpoints are properly secured with authentication and authorization mechanisms. FAQ Q1: What is the difference between HttpClient and Http in Angular? A1: HttpClient is the recommended module for making HTTP requests in Angular, offering features like strong typing and interceptors. HTTP is the older module, and its use is discouraged. Q2: How do I handle authentication in API requests? A2: You can handle authentication by using interceptors to add authentication headers to your requests. Ensure that your server-side endpoints also implement authentication mechanisms. Q3: What is the purpose of error handling in API requests? A3: Error handling allows you to gracefully handle errors that may occur during API requests and provide informative feedback to users. Conclusion Mastering API requests in Angular is crucial for building efficient, secure, and maintainable web applications. By following best practices like organizing your code, using Angular's HttpClient, and implementing error handling, you can ensure your application communicates with external data sources effectively. Remember to optimize your requests, handle sensitive data securely, and always keep the user experience in mind. With these principles in mind, you'll be well on your way to creating robust Angular applications. Also published . here

Mastering API Requests in Angular: Best Practices for Efficient, Secure, and Maintainable Web Apps

Blockchain technology has sparked the emergence of a whole new industry widely known as “Web3”, a new frontier in the digital economy where decentralization, interoperability and user empowerment are put front and center. As part of the Web3 dawning, multiple new asset classes are becoming available to the masses. Cryptocurrencies such as Bitcoin and Ethereum are a well-known staple of web3 assets, but since the rise of Decentralized Finance and NFT’s the variety of blockchain-based asset classes is rapidly increasing. With this increased complexity in Web3-assets users are looking for convenient ways to keep track of their assets across blockchains and Web3 protocols. Enter the , a convenient platform that connects to a Web3-wall and provides a comprehensive overview of its balances and positions: Portfolio Tracker et In this article we will provide a step-by-step walkthrough for web3 and web3-curious developers to build their own portfolio tracking feature, using the free-to-use . DeCommas’ Mission Control API What is DeCommas “Mission Control API”? DeCommas’ API is a developer-friendly API providing fast and convenient access to structured blockchain data. On developers can get access to free API-keys in a matter of seconds, providing access to one of the fastest cross-chain Web3 API’s out there. https://build.decommas.io/ As a developer you can access and query the data stored on multiple blockchains with blazing fast response times of below 150ms, free of charge. There’s no need to duplicate multiple API-calls either, as the API response is cross-chain by default. Recently the DeCommas team has doubled down on the OP Stack, adding support for opBNB and Base L2’s as well. In case you are curious about the API, full documentation is available . here Tutorial: Building a Portfolio Tracker using Mission Control API For this tutorial we’ll help you on your way building a Portfolio Tracking feature. We’ll use Mission Control API, and make use of endpoints to fetch ERC20-balances, NFT holdings and even Protocol Positions. In this tutorial, we’ll: Show you how to get your Mission Control API key Set up Mission Control API in your environment Learn about the API call and it’s response Create fundamental features for your portfolio tracker Let’s dive in! Get your personal Mission Control API key DeCommas Mission Control API is required for completing this tutorial. It’s free to use, supports cross-chain queries by default and achieves extremely high response times. Gaining access is simple: Head to https://build.decommas.io/ Click “Get Started” Enter your email address Check your email and click the link to sing in You will now be able to access , which contains your API keys https://dashboard.decommas.io/ You will need your API keys for completing this tutorial, so go ahead and copy paste these to some place where they are easy to find for you, but securely stored. For this tutorial, DeCommas documentation will also come in handy: https://docs.decommas.io/ Setting up Mission Control API in your environment Depending on your preferences, you can interact with the API either via a raw HTTPS request or in JavaScript using our SDK. In case you go with the first route, the call would look like this: https://datalayer.decommas.net/datalayer/api/v1/tokens/{address}?api-key={YOUR-API-KEY} For this tutorial however, we’ll be using the JavaScript SDK that’s provided, and we’ll be using the Quick Start guide to get Mission Control API initiated in your environment. DeCommas SDK: https://github.com/DeCommas/decommas-sdk Install the Mission Control API application in your Javascript environment npm install @decommas/sdk 2.After installing the app you can import and use the SDK: import { Decommas } from '@decommas/sdk';

// Allows to use SDK in DEV-ONLY mode
const decommas = new Decommas();

const getVitalikERC20Balances = async () => {
const address = '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045'; // any address

const tokens = await decommas.address.getTokens({ address });
console.log(tokens);
}; You are now all set, and are ready to call the API! Building fundamental Portfolio Tracker features Now you are familiar with the and can access the API, let’s build some real world features! SDK A good Portfolio Tracker needs to provide insights in ERC-20 holdings, the value of these holdings and a user's transaction history. We’ll give you a primer on all 3 of these! 1. Fetch current ERC-20 balances for a wallet In order for a user to know what and how many  ERC-20 tokens they possess, we’ll be using the once more. ERC-20 tokens endpoint By providing the user's wallet address to the API call, the API returns an overview of ERC-20 tokens across all supported networks. In this case, for wallet address 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 the API will return an array of tokens together with their corresponding balances. The API will respond with a clean array containing tokens, the chains they’re on and their respective balances. You can use this data to provide an overview in your Portfolio Tracker, for example by showing a list of tokens a user holds, sorted by the total amount of each token. {
  "count": 2,
  "status": 200,
  "result": [
    {
      "chain_name": "mainnet",
      "chain_id": 1,
      "address": "0x228ba514309ffdf03a81a205a6d040e429d6e80c",
      "name": "Global Social Chain",
      "decimals": 18,
      "symbol": "GSC",
      "logo_url": "https://assets.coingecko.com/coins/images/4304/large/global-social-chain.png?1547742843",
      "actual_price": "0.00147295",
      "is_verified": true,
      "is_stable": false,
      "amount": "20000000000000000000"
    },
    {
      "chain_name": "mainnet",
      "chain_id": 1,
      "address": "0x38e4adb44ef08f22f5b5b76a8f0c2d0dcbe7dca1",
      "name": "Concentrated Voting Power",
      "decimals": 18,
      "symbol": "CVP",
      "logo_url": "https://assets.coingecko.com/coins/images/12266/large/Powerpool.jpg?1598621373",
      "actual_price": "0.433299",
      "is_verified": true,
      "is_stable": false,
      "amount": "42130000000000000000"
    }
  ]
} 2. Report value of ERC-20 tokens in USDC While knowing how much of a token a user possesses is valuable information, many users would like to see the value of their holdings expressed in USD. Let’s take another look at the response from the ERC-20 Tokens endpoint: {
  "count": 2,
  "status": 200,
  "result": [
    {
      "chain_name": "mainnet",
      "chain_id": 1,
      "address": "0x228ba514309ffdf03a81a205a6d040e429d6e80c",
      "name": "Global Social Chain",
      "decimals": 18,
      "symbol": "GSC",
      "logo_url": "https://assets.coingecko.com/coins/images/4304/large/global-social-chain.png?1547742843",
      "actual_price": "0.00147295",
      "is_verified": true,
      "is_stable": false,
      "amount": "20000000000000000000"
    },
    {
      "chain_name": "mainnet",
      "chain_id": 1,
      "address": "0x38e4adb44ef08f22f5b5b76a8f0c2d0dcbe7dca1",
      "name": "Concentrated Voting Power",
      "decimals": 18,
      "symbol": "CVP",
      "logo_url": "https://assets.coingecko.com/coins/images/12266/large/Powerpool.jpg?1598621373",
      "actual_price": "0.433299",
      "is_verified": true,
      "is_stable": false,
      "amount": "42130000000000000000"
    }
  ]
} Using the variable “actual_price”, you can show the user the sum of their holdings expressed in USD.  Depending on what you have in mind for your Portfolio Tracker, you could consider showing the amount of tokens by token, combined with a total USDC value the user has in that token. For this you can use “Name”, “Symbol”, “Amount” and “Actual Price”. Wrapping up - Your first steps to building your web3 Portfolio Tracker This is of course just a start for building your Portfolio Tracker. Want to learn more about expanding your Portfolio Tracker? Keep an eye out on DeCommas’ , as new web3 tutorials are posted frequently! HackerNoon Getting started in web3 development might feel daunting, but by using DeCommas’ Mission Control API you can speed up the process tremendously. Utilizing just a few straightforward API calls already gets you access to heaps of blockchain-stored data, free of charge. Enjoyed this Tutorial and want to learn more? Give DeCommas a follow on , where we regularly post Web3 Development tutorials just like this one! Already know all that you need and want to build on? Head out to and use Mission Control API to your advantage! HackerNoon build.decommas.io Also published . here

Creating a Web3 Portfolio Tracker with DeCommas API

Creación de un rastreador de cartera Web3 con la API DeCommas

Création d'un suivi de portefeuille Web3 avec l'API DeCommas

DeCommas API के साथ एक Web3 पोर्टफोलियो ट्रैकर बनाना

DeCommas API を使用した Web3 ポートフォリオ トラッカーの作成

Criando um rastreador de portfólio Web3 com API DeCommas

Tạo Trình theo dõi danh mục đầu tư Web3 bằng API DeCommas

使用 DeCommas API 创建 Web3 投资组合跟踪器

How We Created Our Own ChatGPT

In the web development field, auth (authentication + authorization) plays a vital role in securing user access and protecting sensitive data. Authentication involves verifying the user’s identity, and Authorization is about granting them appropriate access to the application’s resources. That said, it’s not easy. Implementing auth solely in the frontend is easy, but is usually a terrible idea. Even when done in the backend, it can have its drawbacks. This article explores these limitations and presents a compelling third alternative: the . Backends-for-Frontends (BFF) pattern By adopting this approach, developers can enhance security, improve performance, and achieve greater flexibility in their authentication implementation. Essentially, it’s the perfect pattern for this problem. Additionally, we’ll examine how WunderGraph simplifies the process of implementing auth with a BFF. So let’s get going! Why Frontend Auth Falls Short Let’s first clear the air and analyze why doing front-end auth is such a bad idea (because, let’s face it, it might seem easy, but it’s a terrible way to implement it). Too Exposed Frontend auth involves embedding auth logic in the client-side code, making it vulnerable to inspection by malicious actors. With access to the JS bundle, anyone can analyze and exploit potential weaknesses, jeopardizing the security of the system. Yes, you can obfuscate the code, minimize it and make it literally unreadable by humans. But anyone with enough free time and a Developer’s Console (which is on every major browser) can break your logic and “hack” your auth. Messy Frontend Code Handling auth logic in the frontend increases the burden on frontend teams, leading to slower development cycles. Moreover, frontend code becomes tightly coupled with the auth implementation, hindering scalability and adaptability. In other words, you’re adding code where you shouldn’t, and that only plays against you and your team. Multiple Clients Complexity What if your back-end can be used by different clients (e.g., desktop, mobile app, gaming consoles)? In that case, every different client will have to re-implement the entire auth logic. Does that sound reasonable to you? Even worse, what if you’re developing a platform that can be used by anyone? Then you’ll have countless client applications having to re-invent the authentication wheel. Madness! MADNESS I SAY! The “Prevent Tracking” Option Enabling privacy features that aim to prevent user tracking might unintentionally interfere with auth, causing third-party cookies or auth tokens to be dropped, and eventually disrupting the authentication process. In a typical frontend auth setup, the authentication process involves the frontend obtaining an auth token or cookie from the backend upon successful login. This token is then used to authenticate subsequent requests. But when the “prevent tracking” option is activated, the frontend may be prevented from storing or sending these tokens or cookies. As a result, the authentication flow is disrupted, and users may find themselves unable to access protected resources or perform authenticated actions. The implications of the “prevent tracking” option on on the authentication flow underline the need for alternative approaches. By moving the auth logic to the backend or adopting other patterns (more on this in a second), developers can mitigate these challenges. So, let’s ditch the frontend and focus on the backend! I mean, it only makes sense right? If implementing the auth flow on the front-end alone makes no sense (and we’ve seen many reasons why that is), then logic dictates we should move it to the back-end. Right? Not exactly. While moving the authentication flow to the backend is a step in the right direction, there is a hidden third option that literally lies in the middle of both alternatives: the Backend-for-frontend, also known as BFF (sounds funny, I know). Let’s review what the BFF pattern is, and why implementing the auth layer in the Backend for Frontend (BFF) makes even more sense! The Power of Backends-for-Frontends (BFF) and WunderGraph The acts as a dedicated mini-backend layer owned by the frontend team, created to cater to the needs of that particular frontend or client. It serves as the only ‘backend’ that frontend app can see, hiding the actual backend from it. This BFF serves as the intermediary between the frontend and the real backend. Backends-for-Frontends (BFF) pattern specifically Think about it this way. Have you ever been part of a project where: The backend wants to develop the services one way and the frontend complains that’s not useful for them? And then each develops and deploys their part independently, having to spend weeks re-adjusting and re-factoring later to sync up and match expectations? One where you have multiple, diverse clients that need to consume the same service (most commonly, when you start offering a mobile app in addition to a web app), leading to complex, chatty (either via overfetching or underfetching) frontend code that results in increased network overhead and slower response times, and becomes harder to maintain and scale? Or simply one where changes in one component had unintended effects on the other, because the frontend and backend were tightly coupled? Who hasn’t right? Well, with the BFF pattern, frontend developers can have more control over the data they need and their interactions with the backend, and each can develop, evolve, and deploy their services independently, without being tightly coupled and stepping on each others’ toes. Check out the following diagram to make more sense of it: The above setup shows a classic client-server setup, while the bottom version shows the BFF pattern being implemented by WunderGraph. Sounds like overengineering, but here’s why BFF is superior to both the frontend and the backend for implementing auth: : Within the BFF, developers can implement various security measures like IP whitelisting/blacklisting, rate limiting, request validation and more. They can use any middleware they want for it and these robust options safeguard backend services from problems like DDoS attacks, ensuring that incoming requests undergo the necessary security checks before reaching your backend. Middleware : The BFF pattern allows developers to add a cache for auth tokens, manage session states efficiently, and aggregate data from multiple downstream backend services. Think about it, you can do anything you want in this layer to save time and avoid unnecessary requests to the actual backend of the application. That of course, translates into a more efficient service and potentially a better user experience. Potential Performance Gains : Auth logic can be iterated upon and scaled independently of the backend, since you’re literally not touching it. This agility helps accelerates development cycles, and ensures resilience as traffic increases through horizontal scaling (adding more servers to the auth-backend). Scalability : With the frontend team also owning the BFF, they can iterate on the user interface and authentication flows independently. Through techniques such as request-mocking, they can move forward with the entire development process while the backend team focuses on developing the core business logic. Granted, eventually both teams will have to “talk to each other”, but this process allows for a safer and more flexible way to work independently from each other. Separation of Concerns for the team : Remember what I said earlier about how a developer with a Dev Console could be a potential problem to a full-frontend implementation? Well, this is one way to solve those problems. With the BFF pattern, developers can’t really see the actual log-in logic, they can only see how the frontend reacts to certain responses and that’s IT. In the end, more than , this is more like , but that was too long to use as a bullet point. Security by obfuscation “security by obfuscation” “security by hiding the logic away from the developer” Alright, by now you should be thinking something like right? “Right, OK, I’m sold, how do I implement my first BFF?” Well, that’s not a trivial task, which is why we’ll use other tools to assist us and help with the process. That’s where WunderGraph comes into play. What is WunderGraph? WunderGraph, the Backend for Frontend (BFF) Framework, streamlines API composition with its intuitive approach. By combining APIs seamlessly and treating them as dependencies, WunderGraph enables developers to build applications that rely on data from multiple sources. With native support for GraphQL Subscriptions and a virtual graph layer for cross-source joins, WunderGraph empowers real-time functionality and simplified data integration. With its open-source nature, WunderGraph aims to make utilizing APIs quick and effortless. You can check out WunderGraph's GitHub . here Let’s Explore Clerk Authentication with WunderGraph in our BFF I always like to say: show me a practical example! So enough with the crazy theory and the list of benefits and let’s get this show on the road. Let’s build something using Wundergraph and the BFF pattern. Actually, we’ll use that AND NextJS as the framework and we’ll also throw in a little bit of to handle the auth process. Clerk STEP 1: Set up WunderGraph + NextJS To get started, let’s set up WunderGraph with NextJS. Open your terminal and run the following commands: npx create-wundergraph-app my-project -E nextjs
cd my-project && npm i && npm start If you see something like this after the first line, it means everything was installed correctly: Verify that everything is working by navigating to in your browser. If you see this (it takes a while, so give it time), then you’re good: localhost:3000 STEP 2: Sign up for a Clerk.com Account To proceed with Clerk, you’ll need to sign up for a account. This will provide the necessary authentication infrastructure for our implementation. Clerk.com Once you’ve signed up, click on “Add Application” and start configuring your authentication strategy. As you can see below, you get a nice preview of your log-in screen (right half of the screen) while at the same time, you can configure which auth methods you’ll allow (left half of the screen): For this example, we’ll just go with e-mail and Google. Now hit “Create Application” and let the SaaS do the rest! You’ll be redirected to a page showing you your new keys and how to configure them on multiple frameworks. The first one is going to be Next and since that’s what we’re using (coincidence?!), just don’t touch anything. Just click on the “copy” button on the top right corner of the keys section (see image below): And save that on your file (if you don’t have one at the root of your project, create one and save the data there). .env You’ll also have to install the package: @clerk/nextjs npm install @clerk/nextjs STEP 3: Implementing Clerk Auth in WunderGraph Now, let’s dive into the code and integrate Clerk authentication into our WunderGraph BFF. For the example, we’ll use the default page that was already created by the generator. We’ll add our auth code, and suddenly we’ll have to sign in to actually see it. First, go to and on the left side menu, select the “JWT Templates” section: Add a new one, and fill in a name, let’s call it “wundergraph” (original, I know), and on the “claims” box, add something like this: Clerk.com {
 "id":  "{{user.id}}",
 "email":  "{{user.primary_email_address}}",
 "company":  "{{user.company}}",
 "lastName":  "{{user.last_name}}",
 "username":  "{{user.username}}",
 "firstName":  "{{user.first_name}}"
} The important bit is you’ll also copy the “JWKS Endpoint”: Then go to and edit the section to look like this: .wundergraph/wundergraph.config.ts authentication authentication: {
  tokenBased: {
    providers: [
      {
        jwksURL: "<the url you just got>",
      },
    ];
  }
} Now go to the file and change it to look like this: pages/_app.tsx import Head from "next/head";
import { AppProps } from "next/app";
import { useAuthMiddleware } from "@wundergraph/nextjs";
import { withWunderGraph } from "../components/generated/nextjs";
import {
  ClerkProvider,
  RedirectToSignIn,
  SignedIn,
  SignedOut,
  useAuth,
} from "@clerk/nextjs";
import { Middleware } from "swr";

export const useWunderGraphClerk: Middleware = (useSWRNext) => {
  const auth = useAuth();

  return useAuthMiddleware(useSWRNext, async () => {
    return auth.getToken({ template: "wundergraph" });
  });
};

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <ClerkProvider {...pageProps}>
      <Head>
        <meta charSet="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <script src="https://cdn.tailwindcss.com"></script>
      </Head>
      <main className="flex dark:bg-slate-800 min-h-screen justify-center">
        <SignedIn>
          <Component {...pageProps} />
        </SignedIn>
        <SignedOut>
          <RedirectToSignIn />
        </SignedOut>
      </main>
    </ClerkProvider>
  );
}

export default withWunderGraph(MyApp, {
  use: [useWunderGraphClerk],
}); There are several things to note here: We created the middleware. useWunderGraphClerk We applied the middleware to the exported component. Inside the middleware, we’re referencing the name of the JWT template we created on Clerk (I called it “wundergraph” you might need to change this value if you used another name). I added the component around everything. If you don’t do this, you’ll see an error saying something like . <ClerkProvider> Auth context not found I also added the and components, which take care of adding logic inside the JSX code to understand what to do if the user is signed in or not. SignedIn SignedOut At this point, when visiting you should see a login screen like this: And after logging in, you’ll be redirected automatically to your homepage. http://localhost:3000 STEP 4: But wait, there is more! Yes, you’re done, you can stop reading now, but I wanted to take this a little bit further and show you how cool Clerk is. Inside your logged-in pages, you can add a user menu icon that by default already shows your avatar. And all of that with a single component. Simply add the component inside the file wherever you want and be amazed by the simplicity and power of this component. <UserButton /> pages/index.tsx Here is mine: There you have the “Sign-out” link, which is also a common question users ask after setting everything up! By integrating Clerk authentication into our WunderGraph BFF, we were able to leverage the powerful features and security provided by while benefiting from the simplicity and flexibility of WunderGraph. Clerk.com This is truly a match made in heaven! If you’d like to check out the full source code of this example, , simply clone the repo and go nuts! That said, I hope you found this step-by-step tutorial interesting! I personally loved the simplicity of integration and how both options simplify different aspects of the development process. you have it here In the end, we’re looking at a flexible and powerful frontend capable of being easily integrated into different backends without affecting the UI. Not only that, but we also saw a very simple way of integrating authentication into an existing application with minimum effort! Have you used the BFF pattern before? What about Wundergraph or Clerk? Share your experience in the comments, I’d love to know what you think about this topic!

How to Implement Authentication in Your BFF Architecture in Minutes

If your business has ever considered adding a payment system for issuing cards—perhaps to customers or employees—then you may have avoided it because the technical hurdles seemed too difficult. In reality, getting a payment system up and running is quite straightforward. In this post, we’ll look at how to build payments into your Java application using the from . Core API Marqeta Marqeta is a financial services company that you’ve likely already benefited from using their platform. , , and all have payment platforms built out using Marqeta. If your company needs to issue payment methods to customers or employees, then this platform may be exactly what you need. Uber Square DoorDash We’ll walk through building out a fully functioning card payment system that starts with a bank or other financial institution and ends with a customer or employee with a card they can use for payments anywhere that a debit or credit card is accepted. Before we get going on the technology, it’s important first to cover some of the key terms in use at Marqeta. Key Terms at Marqeta Marqeta partners with a bank to provide a . This source will be a place from which money can be drawn any time a transaction is carried out by the who has a issued to them. A cardholder is any user who holds a card—which can be physical or virtual. funding source user card The rules that govern how a card is to be used  are encapsulated in a . Card products include information related to all cards associated with them, such as whether cards are physical or virtual, single-use or multiple-use, and what is required to complete a transaction. card product All of these important pieces of the Marqeta ecosystem can be managed via the Core API. In our simple Java application, we’ll , , and (based on the card product we created) to the user we created—all by using the Core API. From the perspective of your cardholders, everything will be happening within the app that we’re going to build, so there’s no need for them to interact with Marqeta at all. create a new card product create a user issue a virtual card Java and the Core API While there’s not an officially supported Java SDK for Marqeta, is quite straightforward, as the Core API is documented in both and . The OpenAPI documentation is in beta, but it is generated directly from the API source code. To get a Java client, all we need to do is drop the OpenAPI yaml file into , modify the servers section to use the as the URL, and tell it to generate a Java client. building a Java client Swagger v2.0 OpenAPI v3.0 editor.swagger.io https://sandbox-api.marqeta.com/v3 Building the Client Once you’ve downloaded the client, you can build the client in your local Maven repository, get a Maven app started, and include the client in your file. pom.xml Newer versions of Java may require adding a dependency to the client’s : pom.xml 
<dependency>
  <groupId>javax.annotation</groupId>
  <artifactId>javax.annotation-api</artifactId>
  <version>1.3.2</version>
</dependency> To build the client, we run this command from within the client’s folder: $ mvn clean install Then, in a clean working folder for our app, we run this command: $ mvn -B archetype:generate \
    -DgroupId=com.mycompany.app \
    -DartifactId=my-payment-app \
    -DarchetypeArtifactId=maven-archetype-quickstart \
    -DarchetypeVersion=1.4 You’ll now have a folder called with a into which you can add the generated client as a dependency: my-payment-app pom.xml <dependency>
  <groupId>io.swagger</groupId>
  <artifactId>swagger-java-client</artifactId>
  <version>1.0.0</version>
  <scope>compile</scope>
</dependency> Creating the Java Payment App Now that you’ve created your app’s skeleton, let’s look at the meat of getting started with Marqeta’s Core API. In fact, we’re going to be working through a lot of the steps of the . If you’d prefer to work through that guide, you won’t need to write any code at all, as it includes a built-in . The explorer is also a great way to double check your work as you go through this article. Core API Quick Start guide API Explorer Imports and authentication We can get started in the main file of the Maven-generated app by setting up our authentication and importing the classes we’ll use throughout the project. App.java package com.mycompany.app;

import io.swagger.client.*;
import io.swagger.client.api.*;
import io.swagger.client.model.*;

public class App
{
   public static void main( String[] args )
   {
       String username = "your-sandbox-application-token";
       String password = "your-sandbox-admin-access-token";

       ApiClient apiClient = new ApiClient();
       apiClient.setUsername(username);
       apiClient.setPassword(password);
  }
} Of course, in a production application, you wouldn’t want to include your authentication tokens in plaintext in your code. However, for learning purposes in this demo setup, doing so will allow us to get going quickly. You can find the values you need in your . Marqeta Sandbox Dashboard Create a user Once we have this object ready to go, we can create a new user record with the : ApiClient UsersAPI ...
       apiClient.setPassword(password);

       UsersApi usersApiInstance = new UsersApi();
       usersApiInstance.setApiClient(apiClient);
       CardHolderModel cardHolderBody = new CardHolderModel();

       cardHolderBody.setFirstName("Marqeta");
       cardHolderBody.setLastName("User");
       cardHolderBody.setAddress1("180 Grand Avenue");
       cardHolderBody.setAddress2("6th Floor");
       cardHolderBody.setCity("Oakland");
       cardHolderBody.setState("CA");
       cardHolderBody.setPostalCode("94612");

       String userToken = "";

       try {
           UserCardHolderResponse cardHolderResult = usersApiInstance.postUsers(cardHolderBody);
           System.out.println(cardHolderResult);
           userToken = cardHolderResult.getToken();
           System.out.println("USER TOKEN: " + userToken);
       } catch (ApiException e) {
           System.err.println("Exception when calling UsersApi#postUsers");
           e.printStackTrace();
       }
... Note that we’ve set the user’s first and last name, and we’re storing the user token that gets returned so we can use it later. We also configured the to use the that we defined previously. We’ll continue to do that for each new API endpoint we interact with. usersApiInstance APIClient Create or use an existing card product At this point, we can look for an appropriate card product for issuing a card to our user. Fortunately, the sandbox provides us with a card product called “Reloadable Card”, so we can search for that card product and save its token. This card product also has a funding type attached to it, so we don’t need to do anything special to create one. ...
       CardProductsApi cardProductsApiInstance = new CardProductsApi();
       cardProductsApiInstance.setApiClient(apiClient);

       Integer count = 1;
       Integer startIndex = 0;
       String sortBy = "-createdTime";

       String cardProductToken = "";

       try {
           CardProductListResponse cardProductListResult = cardProductsApiInstance.getCardproducts(count, startIndex, sortBy);
           System.out.println(cardProductListResult);
           cardProductToken = cardProductListResult.getData().get(0).getToken();
           System.out.println("CARD PRODUCT TOKEN: " + cardProductToken);
       } catch (ApiException e) {
           System.err.println("Exception when calling CardProductsApi#getCardProducts");
           e.printStackTrace();
       }
... Issue a card At this point, we have everything we need—a and a —to issue a new card. We make sure to tell the API to send us the CVV or the PAN for the card upon generation, for greater security. user token card product token not ...
       CardsApi cardsApiInstance = new CardsApi();
       cardsApiInstance.setApiClient(apiClient);

       CardRequest cardRequestBody = new CardRequest();
       cardRequestBody.setUserToken(userToken);
       cardRequestBody.setCardProductToken(cardProductToken);

       Boolean showCvvNumber = false;
       Boolean showPan = false;

       try {
           CardResponse cardResult = cardsApiInstance.postCards(cardRequestBody, showCvvNumber, showPan);
           System.out.println(cardResult);
       } catch (ApiException e) {
           System.err.println("Exception when calling CardsApi#postCards");
           e.printStackTrace();
       }
... Simulate transactions and see history Now that you’ve created a card for your user, you can . The existing card product we used already has a , but you can also make API calls to make sure that a user is properly funded to make payments with their card. simulate some transactions against that card funding source Then, you can view account balances and a history of transactions in the tool in your dashboard. This will help you get a sense of what exactly goes on when transactions are carried out against a card on Marqeta. Transaction Timeline Webhooks Marqeta’s Core API also implements , which allow your application or systems to be notified whenever certain events take place. Webhooks can help you connect activity in your application (like the issuing of a card or a declined transaction) with triggers to run backend processes or notify your users. webhooks Conclusion Integrating payments into your application—whether it’s in Java, Python, JavaScript, or another language—isn’t as daunting of a task as you might think. With Marqeta’s Core API—available in OpenAPI format—coupled with its and the , building a payment application is a straightforward project you can tackle quickly. documentation API Explorer Also published . here

A Guide to Building a Java Payment App Using Marqeta

Hello everyone, dev.family is in touch. We would like to tell you about an interesting project that we have been working on for almost six months and are still continuing. During this time, a lot has happened in it, a lot has changed. We discovered something interesting for ourselves, managed to fill the bumps. What will our story be like? What did we do How we started Where did this lead us What problems did we face Why monorepo Why PNPM Why TS How it works now How much we have made our lives easier A little about the project So, what are we still working on? In fact, this question at some point became very relevant, as it was, for example, for the owner of McDonalds corporation at one time. We started the project as a crypto-loyalty program that provides end-users with rewards for certain actions, and customers receive analytics on these same users. Yes, it's pretty superficial, but it doesn't matter. Beginning of work It was necessary to develop Shopify modules for connecting to Shopify stores, a portal for brands, an extension for Google Chrome, a mobile application + a server with a database (well, actually, nowhere without them). In general, with what we need, we decided and started working. Since the project was immediately assumed to be large, everyone understood that it could grow like magic beans of delayed action. It was decided to do everything “correctly” and “by all standards”. That is, everything is written in one language - TypeScript. So that everyone writes the same way, and there are no unnecessary changes in the files, linters (a lot of linters), so that everything is “easy” to reuse, put EVERYTHING into separate modules, and so that they do not steal under the Github access token. So we started: Repository for linters and ts config separate (style guide) Repository for a mobile application (react native) and a Chrome extension (react.js) (together, since they repeat the same functionality, only aimed at different users) Another repository for the portal Two repositories for Shopify modules Repository for blockchain stuff API repository (express.js) Repository for infrastructure Huh ... think I listed everything. It turned out a bit too much, but okay, let’s keep rolling. Oh yeah, why were two repositories allocated for Shopify modules? Because the first  repository is UI-modules. There is all the beauty of our babies and their settings. And the second is integrations-Shopify. This is in fact its’ implementation in Shopify itself  with all liquid files. In total, we have 8 repositories, where some should communicate with each other. Since we are talking about development in TypeScript, we also need package managers to install modules, libraries. But we all worked independently in our repositories, and it didn't matter to anyone what to use. For example, while developing a mobile application on React Native, I did not think for too long and kept YARN1. Someone may be more used to using the good old NPM, while others love everything new and use the fresh YARN3. Thus, somewhere there was NPM, somewhere YARN1, and somewhere YARN3. So we all started to make our applications. And almost immediately the fun began, but not that complete. Firstly, some did not think about what TypeScript was for, and used “Any” wherever they were too lazy, or where they “didn’t understand” how they could not write it. Someone did not realize all TypeScript power and the fact that in some places everything can be made much easier. Therefore, the types came out of cosmic dimensions. Yes, I forgot to say, we decided to use Hasura GraphQL as a database. Manual typization of all answers from it sometimes looked like something else. And in one case, some even wrote in good old Javascript. Yes, the situation turned out to be cool: the first guy put “Any” once again to not to strain too much, the second writes canvases of types with his own hands, and the third still do not write types at all. Later it turns out that in cases where we repeated the logic, and, in a good way, it should have been taken out in a separate package - no one was going to do this. Everyone writes and writes code for himself, for everything else - spit from a high bell tower. Where did this lead us? What do we have? We have 8 repositories with different applications. Some are needed everywhere, others communicate with each other. Therefore, we all create .NPMrc files, prescribe credits, create a github token, then through the package manager-module. In general  a slight hassle, although unpleasant, but nothing unusual. Only in the case of updating something in the package, you need to upgrade its version, then upload it, then update it in your application/module, and only then you will see what has changed. But this is totally inappropriate! Especially if you can just change the color somewhere. In addition, some code is repeated and not reused, but simply quietly rewritten. If we are talking about a mobile application and a browser extension, the redux store and all the work with the API are completely repeated there, something is just completely rewritten or slightly modified. In total, what we are left with: a bunch of repositories, a rather long launch of applications / modules, a lot of the same things written by the same people, a lot of time spent on testing and introducing new people into the project, and other problems arising from the above. In short, this led us to the fact that the tasks were performed for a very long time. Of course, this led to deadlines being missed, it was quite difficult to introduce someone new to the project, which once again affected the speed of development. Everything was going to be quite dreary and long, in some cases, thanks to webpack for that. Then it became clear that we were moving far from where we were striving, but who knows where. After analyzing all the mistakes, we made a number of decisions, which will be discussed now. Why monorepo? Probably, the most important thing that influenced a lot in the future was the realization that we are not building a specific application, but a platform. We have several types of users, there are different applications for them, but they operate within the same platform. So we immediately closed the issue with a large number of repositories: if we are working on one platform, why split it into repositories when it is easier to work in one. I want to say that working in a monorepo made our lives a hell of a lot easier. Some applications or modules had a direct relationship with each other, and now you can work on them with peace of mind on the same branch in the same repository. But this is far from the main advantage. Let's continue. We have moved everything into one repository. Cool! We continued to work at the same pace until it came to reusability. In fact, this is a “rule of good taste” we have in our work. Realizing that in some places we use the same algorithms, functions, code, and in some places separate packages that we installed via github, we decided that all this “doesn’t smell very good” and started putting everything into separate packages within a monorepo using Workspaces. Workspaces (workspaces) are sets of functions in the NPM cli, with which you can manage multiple packages from a single top-level root package. In fact, these are packages within one package that are linked through a specific package manager (any YARN / NPM / PNPM), and then used in another package. To tell the truth, we did not immediately rewrite everything on workspaces, but did it as needed. Here's what it looks like: From one file { "type": "module", "name": "package-name-1", ... "types": "./src/index.ts", "exports": { ".": "./src/index.ts" }, }, To another file { "type": "module", "name": "package-name-2", ... "dependencies": { "package-name-1": "workspace:*", }, }, An example using PNPM Nothing complicated, actually if you think about it: write a couple of commands and lines, and then use whatever you want and wherever you want. But “there is one caveat, comrades”. Earlier I wrote that everyone used the package manager they wanted. In short, we have a repository with different managers. In some places it was funny when someone wrote that he could not link this or that package, having in mind a fact that he uses NPM, and there is YARN. I will add that the problem was not because of different managers, but because people used the wrong commands or configured something wrong. For example, some people through YARN 3 just did a YARN link and that's it, but for YARN 1 it didn't work the way they wanted due to the lack of backward compatibility. After switching to monorepo Why PNPM? By this point, it became clear that it is better to use the same package manager. But you need to choose which one, so at that time we considered only 2 options - and . We discarded NPM right away, because it was slower than others and uglier. There was a choice between PNPM and YARN. YARN PNPM YARN initially worked well - it was faster, simpler and more understandable, which is why everyone used it then. But the person who made YARN left Facebook, and the development of the next versions og it was transferred to others. This is how YARN 2 and YARN 3 appeared without backward compatibility with the former. Also, in addition to the yarn.lock file, they generate a yarn folder, which sometimes weighs as node_modules and stores caches in itself. Therefore, we, like many other developers, turned our attention to PNPM. It turned out to be as convenient as the first YARN at its time. Workspaces can be easily used here, some commands look the same as in the first YARN. In addition, shamefully-hoist turned out to be a nice additional option - it is more convenient to install node_modules everywhere at once than go to some folder every time and do PNPM install. Turborepo and code reuse In addition, we decided to try turborepo. Turborepo is a CI/CD tool that has its own set of options, cli, and configuration via turbo.json file. Installed and configured as easy as possible. We put a global copy of the turbo cli through PNPM add turbo --global. Adding turbo.json to the project turbo.json { "$schema": "https://turbo.build/schema.json", "pipeline": { "build": { "dependsOn": ["^build"] } } } After that we can use all the available functions of turborepo. We were most attracted by its features and the possibility of using it in a monorepo. What hooked us: Incremental builds (Incremental builds - collecting builds is quite painful, Turborepo will remember what was built and skip what has already been calculated); Content-aware hashing (Content-aware hashing - Turborepo looks at the contents of files, not at timestamps, to figure out what needs to be built); Remote Caching (Remote hashing - share a remote build cache with the team and CI / CD for even faster builds.); Task pipelines (A task pipeline that defines relationships between tasks and then optimizes what and when to create.). Parallel execution (Performs builds using each core with maximum parallelism, without wasting idle CPUs). We also took the recommendation for organizing a monorepo from the documentation and implemented it in our platform. That is, we split all our packages into apps and packages. To do this, we also create the PNPM-workspace.yaml file and write: PNPM-workspace.yaml packages: 'apps/**/*' 'packages/**/*' Here you can see an example of our structure before and after: Now we have a monorep with customized workspaces and convenient code reuse. I will add a few more points that we did in parallel. I mentioned two things earlier: we had a chrome extension, and that we decided - we were making a platform. Since our platform worked with Shopify as a priority, we decided that instead of an extension for Chrome or in addition to it, it would be nice to make another module for Shopify, which can be simply installed on the site, so as not to once again force people to download a mobile application or Chrome extension . But it must completely repeat the extension. Initially, we did them in parallel, but we realized that we were doing something wrong, because we simply duplicated the code. In every sense we write the same thing in different places. But since we now have all the workspaces and reuse configured, we easily moved everything into one package, which we called in the Shopify module and Chrome extension. Thus, we saved ourselves a lot of time. The second thing that saved us a lot of time was the elimination of webpack and, in some places, builds in general. What's wrong with webpack? In fact, there are two critical points: complexity and speed. What we have chosen is vite. Why? It is easier to set up, it is quickly gaining popularity and already has a large number of working plugins, and an example from the docks is enough for installation. In comparison, the build on the webpack of our Chrome web extension took about 15 seconds, on vite.js about 7 seconds (with dts file generation). Feel the difference. What's with the rejection of builds? Everything is simple, as it turned out, we didn’t really need them, since these are reusable modules and in package.json, in exports, you could simply replace dist/index.js with src/index.ts. How it was {... "exports": { "import": "./dist/built-index.js" }, ... } How it’s now { ... "types": "./src/index.ts", "exports": { ".": "./src/index.ts" }, ... } Thus, we got rid of the need to run PNPM watch to track application updates related to those modules, and do PNPM build to pull updates. I don't think it's worth explaining how much time it saved us. In fact, one of the reasons why we collected builds was TypeScript, more precisely index.d.ts files. So that when importing our modules / packages, we know what types are expected in certain functions or what types others will return to us, such as here: But given that you can simply export from index.tsx, there was another reason to abandon builds. TypeScript + GraphQL But still, why TypeScript? I think it makes no sense now to describe all the advantages of TS: type safety, facilitating the development process due to typing, the presence of interfaces and classes, open source code, errors made during code modification are visible immediately, and not at runtime, and so on. As I said at the very beginning, we decided to write everything in one language so that if someone stops working or leaves, we can support or insure. First we chose JS. But JS is not very secure, and without tests on large projects it is quite painful. Therefore, we decided in favor of TS. As practice has shown, it is very convenient in monorepo, due to the fact that you can simply export *.ts files, and when using components, the expected data and their types are immediately clear. But one of the main useful features was auto-generation of types for GraphQl query and mutations. For everyone who is not very knowledgeable, GraphQl is a technology that allows you to go to the database through the same query (to get data) and mutation (to change data), and looks something like this: query getShop {shop { shopName shopLocation } } Unlike the REST API, where until you receive it, you won’t know what will come to you, here you yourself determine the data that you need. Let's get back to our President-elect. We used Hasura, which is a GraphQL wrapper on top of PostgreSQL. Since we are working with TS, then in a good way we must type the data from both requests and those that we send to payload. If we are talking about the code from the example above, there should be no problems, kind of. But in practice, a query can reach a hundred lines, plus some fields may or may not come, or have different data types. And typing such canvases is a very long and thankless task. Alternative? Of course I have! Let the types be generated via commands. In our project, we did the following: We used the following libraries: graphql and graphql-request First, files with *.graphql resolution were created, in which queries and mutations were written. For example: test.graphql query getAllShops {test_shops { identifier name location owner_id url domain type owner { name owner_id } } } Next we created codegen.yaml codegen.yaml schema: ${HASURA_URL}:headers: x-hasura-admin-secret: ${HASURA_SECRET} emitLegacyCommonJSImports: false config: gqlImport: graphql-tag#gql scalars: numeric: string uuid: string bigint: string timestamptz: string smallint: number generates: src/infrastructure/api/graphQl/operations.ts: documents: 'src/**/*.graphql' plugins: - TypeScript - TypeScript-operations - TypeScript-graphql-request There we indicated where we were going, and at the end - where we save the file with the generated API (src/infrastructure/api/graphQl/operations.ts) and where we get our requests from (src/**/*.graphql). After that, a script was added to package.json that generated the same types for us: package.json {... "scripts": { "generate": "HASURA_URL=http://localhost:9696/v1/graphql HASURA_SECRET=secret graphql-codegen-esm --config codegen.yml", ... }, ... } They indicated the URL that the script accessed to obtain information, the secret, and the command itself. Finally, we create the client: import { GraphQLClient } from "graphql-request"; import { getSdk } from "./operations.js"; export const createGraphQlClient = ({ getToken }: CreateGraphQlClient) => { const graphQLClient = new GraphQLClient(‘your url goes here...’); return getSdk(graphQLClient); }; Thus, we get a function that generates a client with all query and mutations. The bonus in operations.ts lays all our types that we can export and use, and there is a complete typing of the entire request: we know what needs to be given and what will come. You don't need to think about anything else, except to run the command and enjoy the beauty of typing. Conclusion Thus, we got rid of a large number of unnecessary repositories and the need to constantly push the slightest changes in order to check how things work. Instead, they came up with one in which everything is structured, decomposed according to its purpose, and everything is easily reused. So we made our life easier and reduced the time to introduce new people to the project, to launch the platform and modules / applications separately. Everything has been typed, and now there is no need to go into each folder and see what this or that function/component wants. As a result, development time has been reduced. In conclusion, I want to say that you should never be in a hurry. It is better to understand what you are doing and how to do it easier than to deliberately complicate your life. Problems are everywhere and always, sooner or later they will come out somewhere, and then deliberate complication will shoot you in the knee, but will not help in any way. The dev.family team was with you, see you soon!

Monorepository in TypeScript: The Story of How we Broke Everything and Made it Better

Monorepositorio en TypeScript: la historia de cómo rompimos todo y lo mejoramos

Monorepository dans TypeScript : l'histoire de la façon dont nous avons tout cassé et amélioré

टाइपस्क्रिप्ट में मोनोरेपोसिटरी: द स्टोरी ऑफ़ हाउ वी ब्रोक एवरीथिंग एंड मेड इट बेटर

TypeScript のモノレポジトリ: すべてを壊してより良くする方法の話

Monorepositório em TypeScript: a história de como quebramos tudo e melhoramos

Kho lưu trữ đơn trong TypeScript: Câu chuyện về cách chúng tôi phá vỡ mọi thứ và làm cho nó tốt hơn

TypeScript 中的单一存储库：我们如何打破一切并使其变得更好的故事

We've looked at many different ways to create live streaming experiences with Amazon Interactive Video Service (Amazon IVS) here on this blog, but all of those examples so far have focused on public channels that can be viewed by anyone without any playback authorization to verify that the viewer is allowed to view the live stream. Many live streaming user generated content (UGC) platforms do not require any authorization to view a stream, but there are use cases where we want to limit our stream viewers to a subset of our audience. For example, maybe our content creators want to charge a subscription for the content that they produce. Or, perhaps there are licensing limitations to the stream content that prohibit distribution to certain demographics or geographic locations. To address use cases where the platform must enforce playback authorization, Amazon IVS supports private channels. These channels will restrict playback to viewers who have obtained a token that is signed with a private key and verified with a public key. In this post, we'll look at how to enable playback authorization, create a playback key pair, generate a token, and play a private stream. Creating a Private Channel The first step in this workflow is to create a private channel. Creating a private channel is very similar to creating a public channel - the only difference is a single setting when creating the channel to enable playback authorization. We can enable playback authorization via the , via the AWS CLI, or via any of the AWS SDKs. Amazon IVS Console Let's start by looking at how to create a private channel via the Amazon IVS Console. At the list of channels in the console, click . Create channel On the page, enter a channel name (#1), select (#2), and turn on (#3). Create channel Custom configuration Enable token-authorization requirement for video playback If you prefer to use the CLI to create a channel, you can add the option. --authorized $ aws ivs create-channel --name demo-private-channel --latency-mode LOW --type STANDARD --authorized In reality, you're probably going to use the AWS SDK to create your user's channels. In this case, you can refer to the AWS SDK documentation for your favorite language to determine the appropriate argument to set for playback. For example, here are the for for the AWS SDK for JavaScript v3 which state that we can set a boolean property when creating a channel. authorized docs CreateChannelCommandInput authorized Now that we have enabled playback authorization, if we were to broadcast to the channel and try to view the live playback without generating and passing a playback token, we will receive a playback error. Here's an example of playback using the Amazon IVS player SDK where we have added an listener to capture playback errors. ERROR const streamUrl = '[private channel Playback Url]';
const ivsPlayer = IVSPlayer.create();
ivsPlayer.attachHTMLVideoElement(document.getElementById('video-player'));
ivsPlayer.load(streamUrl);
ivsPlayer.play();

ivsPlayer.addEventListener(IVSPlayer.PlayerEventType.ERROR, (err) => {
  console.log(err);
}); Running this in a browser when pointed at a private channel will result in the following error logged to the console. {
  "type": "ErrorAuthorization",
  "code": 7,
  "source": "MasterPlaylist",
  "message": "invalid_playback_auth_token"
} This confirms that our channel is indeed private, and requires a to be generated and passed along with the to authorize playback. token Playback Url Creating a Playback Key Before we can generate a playback token, we will need to create a private/public key pair and upload it to the Amazon IVS console. This key pair will be used to generate a token that is signed with the private key, and verified with the public key, to authorize playback. JWT To manage Playback keys with the Amazon IVS Console, select in the left navigation sidebar. Playback keys We can either create a key with the console, or manually with OpenSSL offline on our local machine. To create a key pair directly in the console. For this, click on . Create playback key Give the key a name, and click . Create The public key of this pair is saved to your AWS account and will be used to verify any playback requests that contain a token signed with the private key. When using the Amazon IVS Console to generate a key pair, the private key is immediately downloaded to your machine and is . not saved in the console or available for further download Creating a Key Pair Offline If you'd prefer to create your own key pair, you can do that offline and then import the public key into the Amazon IVS console. Here's an example of creating a key pair with OpenSSL. $ openssl ecparam -name secp384r1 -genkey -noout -out demo-private-channel-private-key-1.pem
$ openssl ec -in demo-private-channel-private-key-1.pem  -pubout -out demo-private-channel-public-key-1.pem To import the public key, click on on the list page. Import Playback key Give the imported key a name, and browse for the key file (or paste the key file contents). public public This can also be done via the AWS CLI: $ aws ivs \
    import-playback-key-pair \
    --name demo-private-channel-playback-key-1 \
    --public-key-material "`cat /path/to/your/public-key.pem`" Or via the AWS SDK ( for JavaScript example). docs Private Channel Playback Now that we have created a private channel and a playback key pair, we are ready to generate signed playback authorization tokens. In your application, your business logic will dictate which users should be granted an authorization token. As mentioned above, maybe your application logic will first check that the user is a valid subscriber to the channel by querying a database. Or, in the case of geo restrictions, maybe you'll have to look up the IP address of the viewer to make sure it is associate with a region that is able to view the stream. The exact implementation will vary, but once you determine whether the viewer is indeed authorized to view the stream, you can proceed with the token generation method described below. Token generation will differ based on the language you're using on the backend. Refer to the for details on the requirements. Heads Up: user guide To generate a token with Node.js, we can use the library ( ). This library will simplify the process and allow us to sign our payload with the signing algorithm as required by Amazon IVS. Our payload must contain the , an to limit playback to a specific domain (or for all domains), and a token expiration timestamp. To sign the payload, we'll format it as below and use the private key that we created and imported above. jsonwebtoken docs SHA-384 Channel ARN access-control-origin * The token is used to start playback on a private channel, so the expiration period only applies to the time between token generation and playback start. It does not relate to the amount of time the user can play a given stream. Once playback is authorized, it can continue until the user disconnects or reloads the web page. Note: Here's one way to generate a token on the backend (via a microservice or serverless application) using Node.js. import jwt from "jsonwebtoken";

const getToken = () => {
  const privateChannelArn = process.env.DEMO_PRIVATE_CHANNEL_ARN; // private channel ARN
  const privateChannelPrivateKey = process.env.DEMO_PRIVATE_CHANNEL_PRIVATE_KEY; // playback private key

  const payload = {
    "aws:channel-arn": privateChannelArn,
    "aws:access-control-allow-origin": "*",
    "exp": Date.now() + (60 * 1000), // expires in 1 minute
  };

  const token = jwt.sign(payload, privateChannelPrivateKey, { algorithm: 'ES384' });
  return token;
} In our frontend, we can retrieve the token from the backend and append it to the private channel's . In the example below, I've trunacted the Playback Url ( ) for brevity. Playback Url streamUrl const streamUrl = `https://[truncated].m3u8?token=${token}`
const ivsPlayer = IVSPlayer.create();
ivsPlayer.attachHTMLVideoElement(document.getElementById('video-player'));
ivsPlayer.load(streamUrl);
ivsPlayer.play(); Summary In this post we learned how to create private channels, create and import playback keypairs, and generate a JWT token for playback authorization. To learn more about private channels, refer to the . user guide

Using Amazon IVS to Create a Private Channel for Authorized Live Stream Playback

Uso de Amazon IVS para crear un canal privado para la reproducción de transmisión en vivo autorizada

Utilisation d'Amazon IVS pour créer un canal privé pour la lecture de flux en direct autorisée

अधिकृत लाइव स्ट्रीम प्लेबैक के लिए एक निजी चैनल बनाने के लिए Amazon IVS का उपयोग करना

Amazon IVS を使用して、承認されたライブ ストリーム再生用のプライベート チャネルを作成する

Usando o Amazon IVS para criar um canal privado para reprodução de transmissão ao vivo autorizada

Sử dụng Amazon IVS để tạo kênh riêng để phát lại luồng trực tiếp được ủy quyền

使用 Amazon IVS 创建私有频道进行授权直播流媒体播放

Photo by on NGO TUNG Unsplash My company, CriticalBlue, provides a remote mobile app authentication service called . An Approov SDK is provided as a drop-in library to native iOS and Android app developers. Approov With many of our customers using or experimenting with React Native, I wanted to provide a convenient Javascript module which exposes the native Approov SDK functionality to React Native developers. Overall, creating my first React Native native module was surprisingly straightforward. All code for my initial proof of concept is available in a . github repository React Native Bridge For react Native, Facebook provides a solid which goes over the basics, including how to set up an application and how the underlying UI components differ from the usual React web elements. getting started guide (from ) React Made Native Easy Architecturally, there are two important threads running in each React Native application — one a main UI thread and the other running a Javascript VM. The two threads interact through a bridge whose communication is asynchronous, serialized, and batched, decoupling the two systems as much as possible. While the bulk of the React Native app is described in React and runs on the Javascript VM, the UI is rendered using the native platform’s UI elements, and actions which alter the app’s UI are passed as messages through the bridge from the VM to the app’s main UI thread. System functionality and libraries developed for the native device environment can be exposed to the Javascript VM using React Native’s native module interface and accessed through the React Native bridge. Approov Native SDK The Approov SDK is a drop-in native iOS or Android library. It interfaces with the cloud-based Approov authentication service which validates that the app is genuine, untampered, and not a bot. An app integrity token is returned from the authentication service, and that token is sent with each API call to ensure that the back-end API service is dealing with a known and genuine front-end request. The basic operation we will expose in our native module proof of concept is , an asynchronous operation in the native SDK. fetchApproovToken() (Approov-protected API call) Before each back-end API call requiring app authentication, the client app makes a fetch token request. If a fresh token is needed, the SDK makes a remote attestation request, and the attestation service cryptographically authenticates the app and responds with an app integrity token. The token has a short lifetime and is signed by a secret known only to the Approov service and the app’s back-end service. No secret is stored in the app, and in fact the app does not know whether the returned token is valid or not. The app simply adds the integrity token to the back-end API call, and the back-end server validates that the token has not expired and is properly signed before processing the request. Approov Demo Service Approov offers a which provides demonstration iOS and Android SDKs and a back-end service with two endpoints: downloadable demo , which provides a publicly accessible test point. https://demo-server.approovr.io/hello , which provides a random shape only if the request contains a valid integrity token. https://demo-server.approovr.io/shapes We’ll use the Android SDK with the back-end service to demonstrate a simple React Native app using Approov. A version of this example using the iOS SDK with React native is also available. Saying Hello I started my React Native project using create-react-native-app (CRNA). Follow the to setup your React Native environment and then: CRNA installation instructions $ create-react-native-app rndemo I will be adding native code to the app, so go ahead and eject now from create-react-native-app: $ yarn eject
... ? What should your Android Studio and Xcode projects be called? rndemo Generating the iOS folder.
Generating the Android folder.
... $ cd rndemo Ejecting is permanent! Please be careful with your selection. ? How would you like to eject from create-react-native-app? React Native: I’d like a regular React Native project. We have a couple of questions to ask you about how you’d like to name your app: ? What should your app appear as on a user’s home screen? RN Demo Wrote to app.json, please update it manually in the future. Select a regular React Native project and name it as you wish. The iOS and Android projects are generated, and you will need and/or build environments installed. Native code will be added to the native Android project later on. Xcode Android Studio We will experiment with a very simple proof of concept app that will use the demo server hello endpoint to validate our network connectivity. React Native implements the for networking. We combine the connection check, UI rendering, and styling all in the file: fetch API App.js } }) })
    }) })
    });
  } }; );
  }
} }, }, }, }, },
}); import React from 'react' ; import { View, Image, Text, Button, StyleSheet } from 'react-native' ; import ShapeView from './ShapeView' export default class App extends React . Component { constructor ( props ) { super (props); this .state = { shape : 'logo' , status : '' }; // check connection checkConnection = () => { fetch( 'https://demo-server.approovr.io/hello' , { method : 'GET' , .then( ( response ) => response.text()) .then( ( text ) => { this .setState( previousState => { return { shape : 'hello' , status : 'connected' }; .catch( ( error ) => { this .setState( previousState => { return { shape : 'confused' , status : 'not connected' }; // render the app screen render ( ) { let pic = { uri : 'https://approov.io/images/approov_largelogo.png' return ( < View style = {styles.container} > < View style = {styles.header} > < Text style = {{fontSize: 24 }}> Approov Shapes </ Text > </ View > < ShapeView style = {styles.content} shape = {this.state.shape} status = {this.state.status}/ > < View style = {styles.footer} > < View style = {styles.buttonBar} > < Button onPress = {this.checkConnection} title = "Test Hello" /> </ View > </ View > </ View > // flexbox styles const styles = StyleSheet.create({ container : { flex : 1 , flexDirection : 'column' , backgroundColor : '#fff' , margin : 10 , header : { flex : .1 , flexDirection : 'row' , justifyContent : 'center' , content : { flex : .8 , flexDirection : 'column' , justifyContent : 'center' , alignItems : 'center' , footer : { flex : .1 , flexDirection : 'row' , justifyContent : 'center' , buttonBar : { flex : 1 , flexDirection : 'row' , alignItems : 'flex-end' , justifyContent : 'space-around' , // end of file The top-level App component is registered in the file. index.js The main view is rendered by a stateless view component which displays a choice of image and a status message: }; );
} }
}); import React from "react" ; import { View, Image, Text, StyleSheet } from "react-native" ; const shapeView = ( props ) => { const imgSrc = { 'logo' : require ( './assets/approov_largelogo.png' ), 'hello' : require ( './assets/hello.png' ), 'confused' : require ( './assets/confused.png' ), 'Rectangle' : require ( './assets/rectangle.png' ), 'Square' : require ( './assets/square.png' ), 'Triangle' : require ( './assets/triangle.png' ), 'Circle' : require ( './assets/circle.png' ) return ( < View style = {props.style} > < Image source = {imgSrc[props.shape]} style = {styles.shapeImg} /> < Text style = {{fontSize: 24 , marginTop: 10 }}> {props.status} </ Text > </ View > const styles = StyleSheet.create({ shapeImg : { resizeMode : 'contain' , height : 256 , width : 256 export default shapeView; // end of file I am using Android for these examples, but this works similarly on iOS. Fire up an Android emulator (you may need to launch Android Studio for this) or connect a phone via . In the directory, launch the app: adb rndemo $ yarn run android $ cd rndemo You should see a screen like this: Push the button and you should see a connected message if everything went okay: TEST HELLO This validates network communication between our React Native app and the demo server. You can set airplane mode on your phone or emulator and push the test button again to verify there is then no longer a connection. The Approov Native Module The Approov demo package includes a README, the iOS and Android Approov demo libraries, sample clients, and app registration tools. Download the , and save the app registration token which is included in your download email. demo package The Approov SDK includes the native code we want to expose to React Native. It must be included in the iOS or Android native projects which were generated when we ejected the create-react-native-app. For Android, this project is located at rndemo/android. Import the Approov SDK into the Android project by following these from the . instructions Approov docs An Android native module is described in Java by extending the ReactContextBaseJavaModule class. The getName() method must be implemented and provides the name of the module to Javascript. Methods exposed to React Native are adorned with @ReactMethod and may provide Javascript callback or promise mechanisms. We’ll use promises in our example. Facebook’s describes other capabilities such as sending events to Javascript and listening to lifecycle events. native module page We initialize the default configuration for Approov authentication in the native module constructor, and define ‘Approov’ in the getName() call. The exposed call wraps the asynchronous native and settles a promise when the token fetch completes. fetchApproovToken() fetchApproovToken() private Context context; ApproovConfig config = ApproovConfig.getDefaultConfig(reactContext);
            ApproovAttestation.initialize(config); }
    }

    @Override }

    @ReactMethod @Override promise.resolve(results.getToken()); }
        }, url);
    }
} package com.criticalblue.approov; import ... import com.criticalblue.attestationlibrary.ApproovAttestation; import com.criticalblue.attestationlibrary.ApproovConfig; import com.criticalblue.attestationlibrary.TokenInterface; class ApproovModule extends ReactContextBaseJavaModule { private static final String E_APPROOV_ERROR = "E_APPROOV_ERROR" ; public ApproovModule ( ReactApplicationContext reactContext ) { super (reactContext); this .context = reactContext; try { } catch (IllegalArgumentException ex) { } catch (MalformedURLException ex) { public String getName ( ) { return "Approov" ; public void fetchApproovToken ( final String url, final Promise promise ) { ApproovAttestation.shared().fetchApproovToken( new TokenInterface ( ) { public void approovTokenFetchResult ( ApproovResults results ) { if (results.getResult() == ApproovAttestation.AttestationResult.SUCCESS) else promise.reject(E_APPROOV_ERROR, "Failed to fetch Approov Token" ); A bundles and creates one or more native modules: ReactPackage @Override }

    @Override }
} package com.criticalblue.approov; import ... public class ApproovPackage implements ReactPackage { public List<ViewManager> createViewManagers ( ReactApplicationContext reactContext ) { return Collections.emptyList(); public List<NativeModule> createNativeModules ( ReactApplicationContext reactContext ) { List<NativeModule> modules = new ArrayList<>(); modules.add( new ApproovModule(reactContext)); return modules; The project’s main application implements ReactApplication and creates and returns a list of module packages. We add the Approov package to the list in . getPackages() @Override }

    @Override );
    }

    @Override }
  };

  @Override }

  @Override }
} package com.rndemo; import ... import com.criticalblue.approov.ApproovPackage; public class MainApplication extends Application implements ReactApplication { private final ReactNativeHost mReactNativeHost = new ReactNativeHost ( this ) { public boolean getUseDeveloperSupport ( ) { return BuildConfig.DEBUG; protected List<ReactPackage> getPackages ( ) { return Arrays.<ReactPackage>asList( new MainReactPackage(), new ApproovPackage() protected String getJSMainModuleName ( ) { return "index" ; public ReactNativeHost getReactNativeHost ( ) { return mReactNativeHost; public void onCreate ( ) { super .onCreate(); SoLoader.init( this , /* native exopackage */ false ); On the Javascript side, the Approov native module will now be included in the imported from . In our implementation, returns a normal javascript promise: NativeModules react-native Approov.fetchApproovToken() NativeModules.Approov.fetchApproovToken(input) }) }); import {NativeModules} from 'react-native' ; .then( token => { // do something useful... .catch( ( error ) => { throw error; Bridging the native and Javascript environments was surprisingly straightforward. Interceptors Many networking libraries, such as and tp, include the concept of an interceptor. Interceptors can be used to intercept network requests and responses and inject some additional processing. Axios OkHt When implementing natively with the Android SDK, most customers use interceptors to fetch an Approov token and add it to each API request’s headers, so we’ll want to fully implement this abstraction in our production module. For this simple example though, we’ll hardwire the interception in a fetchWithToken() call. In the fetchWithToken() method, when the native fetch token call completes, if the promise is resolved, we add the token to the input request headers and make a fetch() call with the augmented input request. When completed, the fetch returns a resolved promise holding the API server’s response. } }
                }) })
        }) })
}; import {NativeModules} from 'react-native' ; const fetchWithToken = ( input, options ) => { return NativeModules.Approov.fetchApproovToken(input) .then( token => { let optionsA = (options? {...options, headers :{ ...options.headers}}:{ headers : {}}); optionsA.headers[ 'Approov-Token' ] = token; return fetch(input, optionsA) .then( ( response ) => { if (response.ok) { return response; else { throw new Error ( 'HTTP response status is ' + response.status); .catch( ( error ) => { throw error; .catch( ( error ) => { throw error; const Approov = Object .assign({ fetch : fetchWithToken }, NativeModules.Approov); export default Approov; For convenience, we create an Approov object from the NativeModules.Approov object, adding a fetch() method which is actually the fetchWithToken() method, and then we export this as the Approov module. Getting Shapes Now we are ready to use the Approov object for authentication. We add a getShape() method inside our App which makes an Approov.fetch(request) call to authenticate and request a random shape value. Once the fetch completes, the App component state updates, triggering a render() call which causes the ShapeView to display an updated shape and status message. A GET SHAPES button is added to the button bar to request new shapes. }) } }) })
    }) })
    });
  } }; );
  }
} import Approov from './Approov' ; class App extends React . Component { // unchanged code ommitted for brevity... // get shape getShape = () => { Approov.fetch( 'https://demo-server.approovr.io/shapes' , { method : 'GET' , .then( ( response ) => { if (!response.ok) { throw new Error ( 'HTTP response status not OK.' ); return response.text(); .then( ( text ) => { this .setState( previousState => { return { shape : text, status : '' }; .catch( ( error ) => { const message = '' + error.message; this .setState( previousState => { return { shape : 'confused' , status : message }; // render the app screen render ( ) { let pic = { uri : 'https://approov.io/images/approov_largelogo.png' return ( < View style = {styles.container} > < View style = {styles.header} > < Text style = {{fontSize: 24 }}> Approov Shapes </ Text > </ View > < ShapeView style = {styles.content} shape = {this.state.shape} status = {this.state.status}/ > < View style = {styles.footer} > < View style = {styles.buttonBar} > < Button onPress = {this.checkConnection} title = "Test Hello" /> < Button onPress = {this.getShape} title = "Get Shape" /> </ View > </ View > </ View > Everything looks good, but when we request a new shape, we see a failure with a 400 status code, suggesting there is a problem with the client request. Failure to fetch a shape The call fails because the integrity token added by Approov is invalid. Until our example app is properly registered with the Approov service, the fetchWithToken() call will always fail the authentication check. Command line registration tools are included in the demo download. To register the app, issue a registration request specifying the App’s APK bundle and the app registration token you saved from the demo download email. As a courtesy to other demo users, set your registration to expire after a few hours using the -e flag: $ ./registration -t <registration-token>
   -e 2h
Submitting data… $ cd <<approov-demo-package>> /registration-tools/ Android/Mac/ -a <<rndemo-project>> /android/ app/build/outputs/apk/app-debug.apk Success : new app signature added to database.always be done. Once the app is registered and can be properly authenticated, pressing the GET SHAPES button should return one of these shapes: (Successfully fetching random shapes) Man in the Middle Attacks The security of the communication channel is very important during API calls. If the channel is insecure, an API call could be intercepted and modified. An integrity token, although it has a short lifetime, could be observed in the insecure channel and used to make malicious API calls with impunity. Despite using HTTPS/TLS when making API requests, an attacker who controls both the network and the mobile device can easily setup a to steal and quickly reuse Approov tokens before they expire. Man in the Middle (MitM) attack To counter MitM attacks, mobile clients should use which checks that the certificate or public key presented by the back-end service is known specifically by the client app. Other certificates, though they might appear authentic, will be rejected by the client, and no API calls will be made. certificate or public key ‘pinning’ Implementing pinning in React Native is a bit complicated and will be described in a separate article and integrated into this example’s code repository. Going Further We’ve demonstrated a native module implementation in React Native with a hardwired interceptor successfully providing app authentication and API protection. A production quality native module implementation for React Native would generalize the interceptor functionality, add convenience configuration methods, and provide full MitM protection. For comparison, a similar already exists for and hybrid apps. Approov plugin library Cordova Ionic All code for this example is located on . github Thanks for reading! For more information on mobile API security, check out . www.approov.io I’d really appreciate it if you recommend this post (by clicking the 👏 button) so other people can find it.

First experiences with React Native: bridging an Android native module for app authentication

A couple of days ago in my current working project, we decided to rewrite our simple fetch service to a more powerful solution with the ability to cancel requests which were sent previously. From the beginning, we decided to use library and , as everybody has experience with it previously, and it provides a solution for request canceling based on Promises. It’s already working but will be extended in nearly future. axios TypeScript So, let’s start. Firstly, we need to create an Axios service. All our services in the current project is a class-based, so we need to create a class . There are 2 base approaches of how we can use Axios: directly use object from import or create a new instance with . We will use the last one. Service will have 2 fields: instance which has a type and which has a type : AxiosService axios axios.create AxiosInstance cancelToken CancelTokenStatic class AxiosService {
    instance: AxiosInstance;
    cancelTokenStatic: CancelTokenStatic;
} Then in the constructor, we create : axiosInstanse constructor(url: string) {
    this.instance = axios.create({
        headers: {
            Accept: 'application/json',
            'Content-Type': 'application/json',
        },
        baseURL: url
    });
    this.cancelTokenStatic = axios.CancelToken;
} function can take an object with options. In our case, we set field and told that our instance will work with and provide a base URL address that will be used for every request. provide cancel requests logic, so we also save it axios.create headers json axios.CancelToken One more thing that we need is to create a public function that will update . We need it for some specific business cases: baseURL setBaseURL(url: string): void {
    this.instance.defaults.baseURL = url;
} Full version of class: AxiosService import axios, { AxiosInstance, CancelTokenStatic } from 'axios';

class AxiosService {
    instance: AxiosInstance;
    cancelTokenStatic: CancelTokenStatic;

    constructor(url: string) {
        this.instance = axios.create({
            transformRequest: [
                (data, headers): string => {
                    headers['Authorization'] = `Bearer ${authService.getToken()}`;
                    return JSON.stringify(data);
                },
            ],
            headers: {
                Accept: 'application/json',
                'Content-Type': 'application/json',
            },
            baseURL: url,
        });
        this.cancelTokenStatic = axios.CancelToken;
    }

    setBaseURL(url: string): void {
        this.instance.defaults.baseURL = url;
    }
} The next step is to create which will implement all other logic with requests. Why do we need to create a new service instead of just adding request logic to AxiosService? Because it will help us to use any other rest library instead of Axios if we want to do this in the future. HttpService HttpService will have 3 fields: class HttpService {
    private axiosInstance: AxiosInstance;
    private sourceMap: { [key: string]: CancelTokenSource[] } = {};
    private cancelToken: CancelTokenStatic;
} and we will set in constructor, will be our store where we will keep cancel tokens for requests axiosInstance cancelToken sourceMap constructor(instance: AxiosInstance, cancelToken: CancelTokenStatic) {
    this.axiosInstance = instance;
    this.cancelToken = cancelToken;
} Now let’s implement the logic for canceling requests. private createCancelToken = (cancelKey: string): CancelToken => {
    const source = this.cancelToken.source();

    if (this.sourceMap[cancelKey]) {
        this.sourceMap[cancelKey].push(source);
    } else {
        this.sourceMap[cancelKey] = [source];
    }

    return source.token;
}; Private function firstly create a new cancel token source. Then we check if our already have a field with key , then we just add new to array or we create a new field in and the source is the first element in the array. createCancelToken sourceMap cancelKey cancelSource sourceMap The next step is to create method. cancelPreviousRequests cancelPreviousRequests = (cancelKey: string): void => {
    const requests = this.sourceMap[cancelKey] || [];
    
    requests.forEach((item) => {
        item.cancel('cancel');
    });

    this.sourceMap[cancelKey] = [];
}; We take a from the argument and find such field in . Then we iterate through every in it and call the function. And then delete the target field in via saving an empty array to it. cancelKey sourceMap CancelTokenSource cancel sourceMap Now we can start with requests logic. We will use the general method for all requests. This method will take some options. Let’s define interface for them: sendRequest interface RequestOptions {
    url: string; // url for request
    method?: Method; // HTTP method
    params?: Dictionary<any> | string; // request params
    cancelKey?: string; // key for sourceMap if request can be canceled
  responseType?: ResponseType; // type for response
} And the method which will return Promise: sendRequest sendRequest<T = unknown>({
    url,
    method = 'GET',
    params,
    cancelKey,
    responseType,
  }: RequestOptions): Promise<AxiosResponse<T> | void> {
    let cancelToken;

    if (cancelKey) {
        cancelToken = this.createCancelToken(cancelKey);
    }

    switch (method) {
        case 'POST':
            return this.postRequest({ url, data: params, cancelToken });

        default:
            return this.getRequest({
                url,
                cancelToken,
                responseType,
            });
    }
} We use generic for returned type for response and method we set to T by default. Firstly, we check if we have a , then we need to create and push it to . Then we use switch construction to iterate through the request’s methods and call corresponding functions. GE cancelKey cancelToken sourceMap The request function also will take some params, so we need to define an interface for them: type RequestParams = {
    url: string;
    cancelToken?: CancelToken;
    data?: Dictionary<any> | string;
}; We have 2 base HTTP methods for POST and GET requests: private async postRequest({
    url,
    data,
    cancelToken,
}: RequestParams): Promise<AxiosResponse | void> {
    try {
        return await this.axiosInstance.post(url, data, { cancelToken });
    } catch (error) {
      return Promise.reject(error);
    }
}

private async getRequest({
    url,
    cancelToken,
}: RequestParams): Promise<AxiosResponse | void> {
    try {
        return await this.axiosInstance.get(url, { cancelToken });
    } catch (error) {
        return Promise.reject(error);
    }
} Nothing special here. We just call the corresponding request from with our params axiosInstance Full code for HttpService: import {
    AxiosResponse,
    Method,
    CancelTokenSource,
    CancelToken,
    AxiosInstance,
    CancelTokenStatic,
} from 'axios';
import { axiosService } from './AxiosService';

interface RequestOptions {
    url: string;
    method?: Method;
    params?: Dictionary<any> | string;
    cancelKey?: string;
}

interface RequestParams {
    url: string;
    cancelToken?: CancelToken;
    data?: Dictionary<any> | string;
}

class HttpService {
    private axiosInstance: AxiosInstance;
    private sourceMap: { [key: string]: CancelTokenSource[] } = {};
    private cancelToken: CancelTokenStatic;

    constructor(instance: AxiosInstance, cancelToken: CancelTokenStatic) {
        this.axiosInstance = instance;
        this.cancelToken = cancelToken;
    }

    private createCancelToken = (cancelKey: string): CancelToken => {
        const source = this.cancelToken.source();
        if (this.sourceMap[cancelKey]) {
            this.sourceMap[cancelKey].push(source);
        } else {
            this.sourceMap[cancelKey] = [source];
        }
        return source.token;
    };

    cancelPreviousRequests = (cancelKey: string): void => {
        const requests = this.sourceMap[cancelKey] || [];
        requests.forEach((item) => {
            item.cancel('cancel');
        });
        this.sourceMap[cancelKey] = [];
    };

    private async postRequest({
        url,
        data,
        cancelToken,
    }: RequestParams): Promise<AxiosResponse | void> {
        try {
            return await this.axiosInstance.post(url, data, { cancelToken });
        } catch (error) {
            return Promise.reject(error);
        }
    }

    private async getRequest({ url, cancelToken }: RequestParams): Promise<AxiosResponse | void> {
        try {
            return await this.axiosInstance.get(url, { cancelToken });
        } catch (error) {
            return Promise.reject(error);
        }
    }

    sendRequest<T = unknown>({
        url,
        method = 'GET',
        params,
        cancelKey,
    }: RequestOptions): Promise<AxiosResponse<T> | void> {
        let cancelToken;

        if (cancelKey) {
            cancelToken = this.createCancelToken(cancelKey);
        }

        switch (method) {
            case 'POST':
                return this.postRequest({ url, data: params, cancelToken });

            default:
                return this.getRequest({
                    url,
                    cancelToken,
                });
      }
} Example of usage: httpService.cancelPreviousRequests('testRequest');
httpService
    .sendRequest<string[]>({
        url: '/api/testurl',
        cancelKey: 'testRequest',
    })
    .then((response) => {
        if (response?.data) {
            console.log(response.data)
        }
    })
    .catch((error) => {
        console.warn(error);
    });

Making HTTP Requests With Axios in TypeScript

Coinbase Cloud Node & NFT APIs

1. Test Case The test case is very simple, so it can’t cover the full flow of the scanner. Note: 2. Token: function, JsPrint The V8_INLINE Token::Value Scanner::ScanSingleToken() is the start of scanning the token. We already know that c0_ has already pointed to the first character of the JS stream during initialization. In our test case, c0_ points to “f”. Let’s see how it works. The 5th line of the above code. Checks whether c0_ is an Ascii. In our case, it is true (c0_ is f). (1): The 6th line of the above code. one_char_tokens is a pre-defined template in V8, which is an array of character types. It is below: (2): The one_char_tokens is composed of the above three parts of the code. In our case, ‘f’ is the IsAsciiIdentifier(c) identifier, it’s type is Token::IDENTIFIER, and IsAsciiIdentifier is below: Look at ScanSingleToken(). The type of c0_ is Token::IDENTIFIER, so the ScanIdentifierOrKeyword() will be called. We can see several methods in ScanIdentifierOrKeyword, these methods are used to wrap the relationship between classes. Figure 1 is the call stack of these methods. (3): Searching for ScanSingleToken in V8, then set a breakpoint on it, you can reproduce the stack of Figure 1. Before scanning the next character, the ‘f’ needs to be saved. The following is the method to save characters. (4): Figure 2 is the variable window, we can see that the one_byte_char is c0_, which is stored in the backing_store_. Let’s start scanning the second character, the code is below. The AdvanceUntil method reads each character in turn and stops when the terminator occurs. In Figure 3, we can see that these eight characters are exactly the first string — — function in our case. Now, we get a complete token, the next step is to analyze whether the token is a keyword or an identifier. The code is below. GetToken is used to determine whether a token is a keyword or an identifier. The determination is very simple — get the type of token by looking up a predefined hash table. Figure 4 shows the important members of the hash table. So far, the token function has been generated, and it’s type is Token::FUNCTION. The token JsPrint is similar, it’s type is Token::IDENTIFIER. 3. Difference between function and JsPrint We know that function is a keyword, and JsPrint is a custom identifier. Let’s see how Parser expresses the difference between the two of them. The above code parses these two tokens. Let’s make it clear that the scanner is responsible for generating tokens, and the difference between tokens is identified by the parser. In ParserBase<Impl>::ParseHoistableDeclaration(), the above method will be called. In our case, the ParseIdentifier uses the following symbol method when parsing our function and JsPrint. The symbol table saves the correspondence between identifiers and JS source code. Precisely, it saves the pairing relationship between the identifier and its declaration information. In our case, the function and JsPrint are a pair in the symbol table. Figure 5 is the call stack of the symbol table. We can see the source code when debugging the program, precisely benefit from the existence of the symbol table. It is a data structure generated in the compilation. To be precise, the symbol table is generated in the lexical analysis phase and supplemented in the syntax analysis phase. Okay, that wraps it up for this share. I’ll see you guys next time, take care! My blog is . Please reach out to me if you have any issues. cncyclops.com : qq9123013 : v8blink@outlook.com WeChat Email Also Published here

Understanding Chrome V8 — Chapter 4: Scanner, Token generation

Introduction I’ve only been in Web3 for about a year now, but I can honestly say that NFTs are the most exciting aspect about it for me. I’m not talking about Apes or Punks, however. PFP (profile picture) projects and art, although cool and a simple proof of concept for the technology, won’t create a better world. Instead, I’m excited about the actual utility of NFTs. Allowing gamers to own their assets, delivering fair royalty commissions to musicians and artists, and making concert tickets impossible to scalp while providing a sweet digital memento are some of the use cases I find interesting. However, building and interacting with NFTs aren’t always the easiest thing to do. As developers, we need clear resources to build projects effectively in order to give our users a better experience. I recently heard about , so I thought I would check it out and see how it could improve my development workflow. In this article, I will explore the capabilities of Infura’s NFT API and test it out using a Lootbox NFT sample project from Infura’s Github. Infura’s private beta for their NFT API What is the Infura NFT API? According to on Infura’s website, the NFT API will help me “accelerate my time to value” and allow me to interact with anything related to NFTs through a convenient SDK. In addition, I can build and verify my NFTs, create metadata templates and easily mint NFTs. So my first impression is that I can start creating and interacting with NFTs using API endpoints rather than building smart contracts and deploying them. this blog post Sounds pretty useful! And I’m all for testing any tool that will help improve my development processes. Infura’s NFT API suite seems helpful for any dev transitioning from Web2, since you can run API endpoints without Solidity. Now let’s dive deeper and see what this NFT API is capable of. Infura NFT API Capabilities A quick glance through the on Infura’s website proves my first impression correct. I will be able to deploy and call methods on my NFT contracts using Infura’s API endpoints, without having to actually write the smart contract code. This is a huge time saver! NFT API documentation is straightforward. I create the NFT metadata in JSON format, in another Infura project, then create a simple deployment script and run it with node. I also have to make a file to hold some environment variables. My deployment script ends up looking something like this: Deploying a contract upload the metadata to IPFS .env import { config as loadEnv } from 'dotenv';
import { SDK, Auth, TEMPLATES } from '@infura/sdk';

loadEnv();

const auth = new Auth({
      projectId: process.env.INFURA_PROJECT_ID,
      secretId: process.env.INFURA_PROJECT_SECRET,
      privateKey: process.env.WALLET_PRIVATE_KEY,
      chainId: 4,
    });

const sdk = new SDK(auth);

const myNFTContract = await sdk.deploy({
   template: TEMPLATES.ERC721Mintable,
   params: {
     name: 'My NFT Contract',
     symbol: 'MYNFT',
     contractURI: 'https://MY_NFT_METADATA_URL',
   },
 });
console.log(`Contract address is: ${myNFTContract.contractAddress}`); Then, I run it with Node. Infura creates a smart contract for me and uploads it to Ethereum behind the scenes. After that, I just need to make sure I have some tokens for whichever I have specified in my code. In this case, the Rinkeby testnet (chainId: 4). From here, I could from this contract or gather the contract metadata. chainId mint NFTs This is a much easier method to create an NFT contract than writing Solidity code and deploying it myself! The NFT API also provides methods for from wallets, from one wallet to another, and a host of other . These include , , and . gathering NFT info transferring NFTs NFT methods adding an address to the minter list setting royalty info changing the contract URI Overall, it seems that Infura’s NFT API indeed helps improve my development workflow. Having all the necessary functionality for building and interacting with NFTs packaged together in an easy-to-use SDK is quite convenient! But enough about what it can do, let’s see how this API works! The Lootbox Project Along with the NFT API, Infura released an to demo its capabilities. All I will have to do is input an Infura project ID and secret, then connect my MetaMask wallet to the dapp frontend. Then the dapp uses the API to fetch all my NFTs to display nicely in the frontend. So to break that down, I will need the following things for this project: NFT Gallery Project on their Github An Infura account Infura Project ID and Secret A with NFTs in it MetaMask wallet extension Let’s get started! Step 1 - The Infura Project ID and Secret Before starting the Lootbox project, I want to gather the necessary items. So first, I’ll head to , log in, and create a new project. Then, I can grab the and for use later. infura.io Project ID Project Secret Step 2 - MetaMask This step will be quick because I already have the extension installed in my browser. If someone following along with this article doesn’t, however, head to and the extension for your specific browser. Then follow the steps to create a new account. metamask.io download Next, I’ll sign in and switch accounts to the wallet address that holds my NFTs. If you need to acquire an NFT, you can head to and buy one or try to create one yourself using the Infura NFT API 😉. Either way, you will need some ETH in your wallet. your favorite marketplace Step 3 - Setting Up The Project With all the prep work out of the way, I can start building the project. So next, I’ll clone the project repo onto my local machine. I’ll first navigate to the folder I want to work out of and then type the following command: git clone https://github.com/INFURA/nft-api-lootbox-gallery-app.git Next, I will change directories into the project folder and install dependencies using : yarn cd nft-api-lootbox-gallery-app
yarn After everything is installed, the last thing I need to do is create a file to store my environment variables and secrets. I’ll just copy the file that’s already there and add my variables to it. .env cp .env .env.local Now I’ll open up the project and add my and from my recently created Infura project. There’s also an option to input the Account Address of any wallet to view their NFTs, but I’ve got my own I want to see in the Lootbox NFT Gallery. Project ID Project Secret With all the setup out of the way, I can finally run the Lootbox project. But first, I want to browse through the code to see what’s happening under the hood. Step 4 - The Lootbox Code Based on the of the Lootbox project, the most important components are in the , , and files. So I’m going to browse those and see if I can figure out how this project uses the Infura NFT API. README file pages/index.tsx hooks/useWallet.ts pages/api/assets.ts After looking through these files, I can see the file contains the code which displays the frontend for the project. If the state variable is true, then it should display my NFTs. If it’s false, then it should display the welcome text with the button. This Connect Wallet button connects to some functions in the file, so I’ll check there next. pages/index.tsx showGallery Connect Wallet hooks/useWallet.ts In the file, I can see the function which is supposed to grab my NFTs. Specifically, the function. hooks/useWallet.ts getTokens const getTokens = async (accountAddress: string) => {
    try {
      const { data } = await axios.post('/api/assets', { accountAddress });
      return data.assets;
    } catch (error) {
      setTimeout(() => {
        setErrorMessage('Error getting tokens');
      }, 2000);
      return;
    }
  }; This function seems to make a POST request using a parameter from the file and return the results with my assets. So looking into the file, I can see where the NFT API is being used. /api/assets pages/api/assets.ts try {
    const { data } = await axios.get(  `https://nft.api.infura.io/networks/1/accounts/${accountAddress}/assets/nfts`,
      {
        headers: {},
        auth: {
          username: `${process.env.INFURA_PROJECT_ID}`,
          password: `${process.env.INFURA_PROJECT_SECRET}`
        }
      }
    );

    return res.status(200).json({
      assets: data.assets,
    }); This code calls the , using my and to access my account, and returns my NFTs in a JSON object. Following the path back to the file, if the function from doesn’t timeout, it will return my NFTs, switch the state variable to , and display my NFTs on the page. get function of the NFT API Infura Project ID Project Secret pages/index.tsx getTokens hooks/useWallet.ts setGallery true Cool! So I’ve got an idea of how it works, let’s see it in action! Step 5 - Running The Lootbox Project To run the project locally, I just need to type: yarn dev After navigating to , I can see a nice-looking frontend for the Lootbox Project. http://localhost:3000/ Clicking on prompts my MetaMask wallet to pop up to approve the connection request. Connect Wallet After connecting, it immediately starts fetching my tokens. This is the point where I now know the dapp is using the NFT API. Once the fetch is successful, it displays my NFTs in a fancy gallery, allowing me to browse and choose each one to get a better look at them. Neat! Conclusion My verdict on the Infura NFT API is that it's a tool that cuts down my development time, and there’s quite a bit I can do with it. It’s handy to build, mint, and interact with NFTs from an easy-to-use API. Although I am more familiar with building NFT contracts with Solidity and deploying them with Truffle, I can easily see how this would help smooth the transition of a Web2 dev into Web3. Using JavaScript rather than writing a smart contract will be a huge time saver for many Web2 developers. I would suggest trying the NFT API out for yourself. It’s still in private beta, but anyone can . For more information on its capabilities, you can check out or . register this YouTube demo Infura’s documentation Also published . here

Using Infura's NFT API With Lootbox

Adding DAO Governance to Existing Token Contracts

Adición de la gobernanza de DAO a los contratos de token existentes

Stories, News & Mentions about GMTTOKEN

Gmttoken’s Stories on HackerNoon