DEV Community: Adebola

How to Pay Gas Fees for Users of Your dApp: Meta Transactions on Tezos

Adebola — Wed, 03 Jan 2024 12:06:20 +0000

This tutorial introduces Meta transactions on Tezos and covers how to use the Gas Station API to cover gas fees for dApp users.

To onboard the next billion users on Web3, simplifying user onboarding and improving the user experience of dApps (decentralized applications) is extremely important.

For many users, the mindset shift from using Web2 applications to using Web3 dApps can be a steep slope. As such, dApp developers are always on the lookout for new ways to improve the UX for users in a way that abstracts away some of the complexities of using decentralized applications.

One example of a major barrier to onboarding users to a dApp is the need to pay gas fees to interact with the dApp.

Users of dApps built on Tezos will need to open a wallet and acquire XTZ(tez) to start using your dApp which can be a barrier to user onboarding. To get over this barrier, the idea of meta-transactions was developed.

What are Meta Transactions?

Meta transactions allow dApp developers to improve the user experience of their applications by removing the need for users to hold tokens for paying gas fees. This is done by separating the transaction's sender (user) from the gas payer. The Gas Payer (usually another smart contract wallet) acts as the relayer for the transaction.

Let's look at why this is important;

In Web2 for example, an app like Instagram allows users to post pictures to their feed without the need to pay a fee each time they post. Users can also like posts, leave comments, send DMs, and more without the need to pay fees for each operation. Meta transactions allow for Web3 dApps to provide a similar experience to users making dApps more user-friendly and improving the overall experience.

There are 2 types of Meta transactions:
Gasless transactions: Gasless or Zero-gas transactions allow users to interact with your dApp without the need to pay gas fees.

Gas Abstraction: Gas abstraction allows users of your dApp to pay gas fees using a token other than the native token of your application. Any token supported by the relayer can be used to cover the gas fees for the transaction.

TZIP-17 and Meta Transactions

TZIP-17 (the permit proposal) introduced the standard for account abstraction. This standard allows pre-signing - a way to have transactions be signed and submitted separately. Read more here.

TZIP-17 is the standard that allows meta transactions to work on Tezos. With this standard, we can have a relayer submit a user's pre-signed (meta) transaction and pay the tez fees on their behalf.

Gas Stations
Gas stations are a good example of systems that can act as a relayer for transactions on a dApp. A Gas station - as the name implies, is simply a system that allows you to store tez (or any token supported by the station) to be used in paying for gas on behalf of your dApp users.

In the next part of this tutorial, we'll build a simple dApp that interacts with a Gas Station.

Using the Gas Station API

With everything we've covered in the previous sections, you should now be familiar with these concepts;

Relayer
Gas Abstraction
Gasless transactions
Meta Transactions
TZIP-17 proposal
Gas stations

Now, we're ready to take all of this knowledge and build something in the wild. We'll be using the Gas Station API from Marigold to build a simple voting dApp that implements gasless transactions. If you have never built a dApp on Tezos before, follow this tutorial to learn more. We'll be building on the voting dApp example in that tutorial here.

The full code for the Voting dApp's front end can be found here.

Let's get started!
Head over to the Marigold Gas Station API environment and connect your wallet to the application using the Connect Wallet button in the top right. Connect your wallet on the Ghostnet network to the application.

Next, we'll need to add credits to the gas station to be used to pay for transactions for users of our dApp. Click on My credits in the menu. You should now be able to see your wallet balance. Enter the amount of tez you'd like to use within the gas station and click Add ꜩ to add the tez to your account. You can get test credits by using a faucet.

Now, we need to make some changes to our Voting Smart Contract for it to still work correctly with our dApp and Gas station. We'll need to

Do away with sp.sender because the transaction's sender will always be the relayer (Gas Station API). As such, we'd need to get the actual sender/user from the transaction parameters - more on this later.
Get the transaction's sender from params instead. Make the following changes to the increase_votes entrypoint.

@sp.entrypoint
def increase_votes(self, params):
  assert not self.data.votersWalletAddresses.contains(params.sender), "YouAlreadyVoted"
  assert self.data.players.contains(params.playerId), "PlayerIDNotFound"
  self.data.players[params.playerId].votes += 1
  self.data.votersWalletAddresses.add(params.sender)

We'll also need to change up our test scenarios to accommodate these changes. Your test scenarios should now look like the below;

# Scenario 1: Increase votes when playerId Exists
    contract.increase_votes(playerId=2, sender=bob.address).run()
    scenario.verify(contract.data.players[2].votes == 1)

    # Scenario 2: Increase votes when playerId Exists
    contract.increase_votes(playerId=2, sender=charlie.address).run()
    scenario.verify(contract.data.players[2].votes == 2)

    # Scenario 3: Fail if User already voted
    contract.increase_votes(playerId=2, sender=charlie.address).run(valid=False, exception="YouAlreadyVoted"
    )

    # Scenario 4: Fail if playerID does not exist
    contract.increase_votes(playerId=6, sender=adebola.address).run(valid=False, exception="PlayerIDNotFound")

Now, go ahead to deploy your smart contract.

See the full code for the updated smart contract here.

Connecting your Smart Contract to the Gas Station

Back in the Gas Station UI, navigate to contracts in the menu. Copy and paste your smart contract address in, then click fetch entrypoints. Give your contract a name you can easily remember.

Now, you can toggle on the entrypoints you'll like to use with the Gas Station API. For this example, we'll only use the increase_votes entrypoint.

Click Add.

Connecting the Frontend to the Gas Station

With our Smart contract deployed, let's head to our application's Frontend to make some changes. The original code for this application is here. We'll be modifying the following files; src/pages/index.js and src/helpers/constants.js . We'll also be installing Axios which will allow us to connect to APIs/endpoints like the Gas station API that exists outside our application.

Let's install axios.

npm i axios

Next, update the src/helpers/constants.js file. We'll need to update the CONTRACT_ADDRESS and GAS_STATION_API_URL

const CONTRACT_ADDRESS = "KT1Aa2YS4RgQjDPDw7YQHpkXgtHvYwC7SYqo";
const GAS_STATION_API_URL = "https://gas-station-api.gcp-npr.marigold.dev";

Don't forget to also export GAS_STATION_API_URL
Next, head into src/pages/index.js.

Import the GAS_STATION_URL with the rest of your constants like below;

import {
  CONTRACT_ADDRESS,
  RPC_URL,
  GAS_STATION_API_URL,
} from "@/helpers/constants";

We'll also need to keep tabs on the User's Wallet Address userAddress so we can send this alongside the rest of the transaction parameters to the API. To do that, we'll use React's useState hook. Your hooks section should now look like below with const [userAddress, setUserAddress] = useState(null) added.

  const [players, setPlayers] = useState([]);
  const [reload, setReload] = useState(false);
  const [message, setMessage] = useState("");
  const [userAddress, setUserAddress] = useState(null);

Now, we'll update our connectWallet function to store the userAddress state

  const connectWallet = async () => {
    setMessage("");
    try {
      const options = {
        name: "Ballon tz'or",
        network: { type: "ghostnet" },
      };
      const wallet = new BeaconWallet(options);
      walletRef.current = wallet;
      await wallet.requestPermissions();
      Tezos.setProvider({ wallet: walletRef.current });
      const userWalletAddress = await wallet.getPKH();
      setUserAddress(userWalletAddress);
    } catch (error) {
      console.error(error);
      setMessage(error.message);
    }
  };

We'll also create a button for the user to connect their wallet when the application loads. This button will run the connectWallet function when clicked. This allows us to make sure we have stored the userAddress before we attempt to send a transaction.

 <button
        className="mt-4 rounded-full bg-green-500 p-3 hover:bg-green-700 transition-all ease-in-out"
        onClick={() => connectWallet()}
      >
        Connect Wallet      
</button>

Finally, we'll add a callGasStation function to replace our votePlayer function. i.e when a user clicks on Vote, our dApp will call callGasStation instead of votePlayer
You'll notice that the callGasStation function bypasses the need to have the user's wallet load up, show them the gas fees and have them approve and sign the transaction. Instead, all of that is handled by the gas station (relayer).

  const callGasStation = async (playerId) => {
    try {
      console.log("in call Gas station");
      const contract = await Tezos.wallet.at(CONTRACT_ADDRESS);
      const op = await contract.methods
        .increase_votes(playerId, userAddress)
        .toTransferParams();

      console.log("address", userAddress);

      const response = await axios.post(GAS_STATION_API_URL + "/operation", {
        sender: userAddress,
        operations: [{ destination: op.to, parameters: op.parameter }],
      });
      console.log("Gas Station response:", response.data);
    } catch (error) {
      console.log(error.message);
      setMessage(error.message)
    }
  };

Let's walk through the code snippet above;

We connect to the contract using Taquito as usual.

 const contract = await Tezos.wallet.at(CONTRACT_ADDRESS);
 const op = await contract.methods
        .increase_votes(playerId, userAddress)
        .toTransferParams();

We tap into the increase_votes entrypoint that has been updated to take 2 parameters of playerId and sender - which is the userAddress . Then, we call the toTransferParams() method on it in order for us to access the operations object returned by the method. The operations object contains a number of objects including the to and parameter which we make use of when calling the Gas Station API.

You can find out what the parameters expected by the Gas Station API are by reading the Swagger Docs/API documentation here. From the docs, we can see that the /operation API expects a JSON object of sender and operation in the form below;

{
  "sender": "string",
  "operations": [
    {}
  ]
}

So, we pass userAddress and the values obtained from op to the API.

 const response = await axios.post(GAS_STATION_API_URL + "/operation", {
        sender: userAddress,
        operations: [{ destination: op.to, parameters: op.parameter }],
   });

See the full code here.

Now, we can run our application to check that everything works correctly.

We can also head to a smart contract explorer like BetterCallDev to check that our smart contract works correctly. For the smart contract used in this example, you can see use the BCD explorer to see how it works.

Run Serverless Cron Jobs With Firebase Cloud Functions

Adebola — Wed, 05 Jul 2023 01:44:29 +0000

Run a job every 2 minutes with Google Cloud Functions

When a user’s subscription within your app expires, how do the systems you have built know to notify them? If you're building a fintech that is involved in lending, how do you send repayment reminders to users a few days to their repayment and on the repayment day? You may also need to backup your databases at the end of each business day, how do you spin up a service to do that? These and many more are why cron jobs matter. In this tutorial, rather than building out a service that runs cron jobs, we’ll hand all of the work over to a managed service like Google Cloud scheduler.

Google Cloud scheduler combined with Firebase cloud functions allows us to write, deploy and run code that completes a task at any given time. In this tutorial, I’ll show you how we automate loan repayment reminders to our users using firebase functions and the google cloud scheduler.

Getting Started

Set up a new Firebase project by following the Getting Started with Firebase section in my article published here. Once your firebase project is setup, you’ll need to upgrade from Spark which is the free firebase plan to Blaze — a paid plan. The scheduler function we’ll be using is only available on the paid plans of firebase. Follow the instructions here to upgrade your plan.

Install firebase admin and firebase tools globally using the commands

npm install firebase-functions@latest firebase-admin@latest — save
npm install -g firebase-tools

3. If you’re on a Mac or a UNIX based system, you may run into a permissions error during installation, prefix your command line commands with sudo . With our libraries installed, let’s get into it!

Setting up your Functions

Next, we need to log in to firebase from our command line to connect it to the project we created in Step 1. Run the command

firebase login\. This will redirect you to your browser, prompting you to login via the UI. Login via the E-mail you connected to your firebase account to continue. Once in, return to the terminal

Navigate into the directory where you’ll like to create your new functions project. Run the command,

firebase init functions

Select the following options in the prompt

-> Use an existing project
-> Select the project you created in Step 1
-> Select JavaScript
-> When prompted to use ESlint, you can select Yes/N. For this example we'll go with N
-> Select Y to install dependencies

By completing the steps above, you should now see a functions folder created for you in your directory. Let’s run some tests to check that everything works. We’ll build a quick app that tells us the time in the US, UK, and Nigeria.

Testing Your Setup using Luxon

Navigate into your functions folder and install the luxon package — a recommended alternative to moment. We’ll be using this package

npm i luxon

In functions > index.js, write the following piece of code. I’ve added comments for clarity.


const { onRequest } = require("firebase-functions/v2/https");
const logger = require("firebase-functions/logger"); // for logging to the terminal
const { DateTime } = require("luxon"); // get the DateTime class from Luxon

exports.timeInDiffPlaces = onRequest((req, res) => {
  const dt = DateTime.now();

  logger.log(
    "timeInLondon",
    dt.setZone("Europe/London").toLocaleString(DateTime.DATETIME_FULL)
  );
  logger.log(
    "timeInNewYork",
    dt.setZone("America/New_York").toLocaleString(DateTime.DATETIME_FULL)
  );
logger.log(
    "timeInLagos",
    dt.setZone("Africa/Lagos").toLocaleString(DateTime.DATETIME_FULL)
  );
  res.send("success");
});

9. Test out your code by running the command

firebase emulators:start

This will create endpoints for each function in your index.js file within the functions folder. The endpoint will be displayed in your terminal window e.g http://127.0.0.1:5001/adebola-reminder/us-central1/timeInDiffPlaces

Now, when you go to the endpoint (in your browser) that is displayed in the terminal, you should see a page that simply displays success as we have specified in our res.send. But take a look in your terminal window, the logger library will log out the time in New York, London, and Lagos in your terminal like below.

Scheduling E-mails to Users

Now that we have everything working fine, let’s get started writing a function to send E-mails to our users. Later, we’ll set up a cloud scheduler to trigger the sending of these emails.

Setting up Nodemailer and Gmail

We’ll be using nodemailer and Gmail to send our E-mails. Follow my article here on setting up both.

Since that article was written, Google has updated how apps can use your E-mail. Google now requires 2FA to be setup to connect it to Nodemailer. Setup 2FA on your E-mail by going here. Once done, we’ll also need to set up an app password to login to our gmail account remotely.

Learn more about app passwords here. To setup App password,

Go here. Make sure you’re logged in to your Gmail account.
Under How you sign in with Google, select 2-step verification.
You’ll be prompted to sign in to your E-mail again. Sign in
Scroll down to App passwords. Click App passwords
Enter a name for your app. Then, click Generate. A modal will pop up with your app password.

The final code is below.

const hbs = require("nodemailer-express-handlebars");
const nodemailer = require("nodemailer");
const path = require("path");

// initialize nodemailer
var transporter = nodemailer.createTransport({
  service: "gmail",
  auth: {
    user: "youremail@gmail.com",
    pass: "your_app_password",
  },
});

// // point to the template folder
const handlebarOptions = {
  viewEngine: {
    partialsDir: path.resolve("./views/"),
    defaultLayout: false,
  },
  viewPath: path.resolve("./views/"),
};

// // use a template file with nodemailer
transporter.use("compile", hbs(handlebarOptions));

exports.sendEmailToUsers = onRequest((req, res) => {
  // setup the E-mail options
  const mailOptions = {
    from: '"Happpiness App" <youremail@gmail.com>', // sender address
    to: "your_test_email@gmail.com", // list of receivers
    subject: "Welcome!",
    template: "email", // the name of the template file i.e email.handlebars
    context: {
      name: "Adebola", // replace {{name}} with Adebola
      company: "My Company", // replace {{company}} with My Company
    },
  };

  // trigger the sending of the E-mail
  transporter.sendMail(mailOptions, function (error, info) {
    if (error) {
      return console.log(error);
    }
    logger.log("Message sent: " + info.response);
  });

  res.send("success");
});

Again, test that everything works by hitting the URL in your terminal window followed by /sendEmailToUsers . Later on, we’ll extract this code into a function of its own rather than having it directly inside the serverless function.

Now for the much-awaited Scheduler

Now that we can trigger E-mails to users, we can setup a scheduler in Google cloud to trigger our function every so often. For this use case, we want to send reminders to users to repay their loan when 3 days to their repayment dates. I’ll skip the code for figuring out when a user’s repayment falls on and go ahead to show you how to set up your scheduler to call the sendEmailToUsers serverless function.

First, extract your E-mail sending logic into a new async function, like below

const sendEmailToUsers = async (emails) => {
 // past the code from Setting up Nodemailer and Gmail section above
// remember that E-mails would contain an array of object so adjust your code
// accordingly
}

Next, setup the logic you need to get the names, emails and other details of the users you’ll like to E-mail. Remember to adjust the template in your views folder from the setting up nodemailer and gmail section to reflect your use case.

We’ll also need to import the onSchedule function from firebase into our code. Like below;

const { onSchedule } = require("firebase-functions/v2/scheduler");

Do this at the top of the index.js file where you have your other imports.

Finally, write the scheduler function using the App Engine syntax to trigger the sendEmailForRepayment function every 2 minutes to make sure everything works correctly. The App engine syntax reads like plain English e.g every 2 minutes compared to the crontab syntax which looks like

*/2 * * * * representing every 1 minute. You can play around with the crontab syntax here. The crontab guru tool will help you generate the appropriate crontab syntax for your scheduler.

You may also use the crontab syntax which most people are familiar with.

exports.sendEmailsForRepayment = onSchedule("every 2 minutes", async (event) => {
  // get users whose repayments are due
  await getUsersWithDueRepayments()
  const emailsWithRepaymentDetails = await getRepaymentDetailsForUsers()
  await sendEmailToUsers(emailsWithRepaymentDetails);
  logger.log("Schedule done running");
});

Deploying your Scheduled Cloud functions

Make sure to run your code using the firebase emulator to test that everything works on your local before deploying. Deploy your code using

firebase deploy

Your scheduled cloud functions should now be live!

Your schedule function should run every minute as specified in the onSchedule callback.

Logging

To monitor the performance of your serverless functions, head over to your google cloud console. Make sure you’re in the right firebase project by selecting your project name from the dropdown.

Use the searchbar to search for the name of your function, in our case sendEmailsForRepayment . From here you’ll be able to see all the information on how that function is performing.

Pub/Sub vs HTTPs

In this example, we connected to our serverless functions via HTTP requests. In my next article, we’ll talk about another way to communicate with serverless functions using Pub/sub or publisher and subscriber. Pub/subs are event-driven.

How to Stream Data From Firebase to BigQuery Easily

Adebola — Sat, 24 Jun 2023 23:39:56 +0000

You must have installed the Stream Firestore to Big Query Extension and maybe even read some of the docs but you still can’t quite figure out how to get everything to work. This guide will help you with that.

Have data in Firebase Firestore and need to bring them into Big Query? That’s a little straightforward. You simply export the data into a bucket and pull the data into your Big query console. There are a few articles online that explain this well, particularly this.

But, when it comes to streaming data in realtime from Firestore to BQ, I couldn’t find any good articles there that could get me from start to finish without errors — so, I wrote one.

This guide assumes you have an existing Firestore instance setup and one or more collections in your Firestore DB. Next, within your Firebase console, navigate to the extensions screen. Search for and install the Stream Firestore to BigQuery extension.

Once in, set up the extension by following the prompts.

NB: You’ll only be able to use the extension if your workspace or account has a Credit card on file.

Keep hitting next till you get to Step 4: Configure extension.

Set your Project Id, Collection Path, Dataset ID and Table ID. Project ID should be the same as whatever you have named your firebase project. Collection path refers to the primary collection you would like to stream to BQ. In our case, we want the users collection. Dataset ID and Table ID can be named as you wish. Keep all other configurations as default and hit the install button.

The extension will take around 3–5mins to install.

At this point, there’s no new data in your BQ console just yet.

While waiting on the extension’s installation to complete, you can begin the process of setting up gcloud CLI. You’ll need to set up the CLI in order to authenticate when running the import script that will take your data from Firestore to BQ.

Follow the instructions here to set up the CLI for your device. Don’t forget to make sure the CLI is in your PATH by running (on a Mac) — in your HOME directory.

./google-cloud-sdk/install.sh

Restart your terminal instance before continuing.

With the CLI setup. Run the command below in your terminal window to authenticate.

gcloud auth application-default login

The command will bring you to the Google sign-in screen. Authenticate using the E-mail that has access to the Firestore project you’re working with.

You’ll see a screen like below if everything goes fine.

Your terminal should also have a message like below

Google has an import script that will allow you to automatically bring all the data in your Firestore collection into BigQuery by running one command. This script works alongside the Stream Firestore to BigQuery extension. Run the command below in your terminal to trigger the script.

npx @firebaseextensions/fs-bq-import-collection

P.S The command above will only work if you have Node/NPM installed.

Follow the prompts starting with entering your project ID. You only need to enter the custom information we set earlier — project ID, Dataset ID, Table prefix and Collection Path. See screenshot below.

The script will create a raw_changelog file in the format table_name_raw_changelog. Once you navigate to your BigQuery console, you would be able to see this.

You can also run queries on your data using the Compose a new query button

Now, you can add a new document to the users collection, refresh your table within BigQuery and observe that the new document reflects in your BigQuery query!

How to Use a Local SMS Service Provider Other than Twilio With Customer.io

Adebola — Sat, 24 Jun 2023 23:35:23 +0000

If you’re running a Business in Africa, you know that every cent counts.

While I love Twilio, and I’m always impressed by their delivery rates, the truth is that at $0.1982 per SMS, it’s expensive to use for early-stage startups whose revenues aren’t based in USD.

I’m a big fan of customer.io and the power it packs and as such it’s something we use a lot at Moni for automating our Marketing campaigns and running in-app and push notifications. I still think that African Startups pay too much for tools — especially startups whose revenues aren’t based in USD, but this is a topic for another day.

Customer.io has a direct integration with Twilio and it’s easy to set up that integration. If that’s something you’re interested in, follow the customer.io docs here.

In this tutorial, we’ll be using a local Nigerian SMS Service provider Sleengshort to send SMS’ to users on our platform. You can follow along with this tutorial without a Sleengshort account. Simply make sure that you have the following;

A registered sender ID with your SMS provider
An API Gateway you can connect to, to trigger the SMS
A customer.io account and basic knowledge of customer.io

Let’s get into it.

First, log in to your Sleengshort account to get your Sender ID and API Keys. You can find both from your Sleengshort Dashboard by going to Settings > Sender ID and Settings > API Keys.

In the Settings > API Keys section, create a new API Key by clicking Add new Key. Give it a name e.g customer.io. Feel free to leave the callback URL and Route/bind options blank. To learn more about both, you can refer to the sleengshort docs here. Once your API keys and sender ID are set up, head over to customer.io. We’ll be using the customer.io Webhooks feature for this integration. To learn more, customer.io has some great documentation here.

Within Customer.io, head to Campaigns > Create Campaign > Give the Campaign a name. I believe these steps would also work for a broadcast. Setup your Campaign with your triggers > Settings > Goal & Exit. The real magic begins in the workflow section. You should end up on a screen like below

Click, hold, and drag the send and receive data block on the left into the large Drag your first block here section. Your screen should look like below;

You can now make changes to the Webhook 1 section by clicking it. Click Add request in the slider that pops up.

The Add request button will bring you to the screen below. The screenshot below already contains the URL to the Sleengshort APIs.

You also need to add the headers. The headers will contain the authorization keys Sleengshort’s APIs expect to receive. Click the Add header button and add the following fields.

Name -> X-Api-Key

Value -> your_api_key_from_sleensghort_starting_with_APPKEY

Sleengshort and Customer.io

Once done, use the fields above in the editor. I’ve also repeated them below.

{
"sender_id" : "Your Sender ID",
"recipients" : {{customer.phone_number}},
"msg" : "Hello {{customer["First Name"]}}, welcome to our Company",
"type": 0
}

Make sure that each key and value is wrapped in a double quote " " to avoid errors in your messages sent. Also, use the + button next to each field that your users in your segment already have to add the recipient’s phone number and to add details like the customer’s name and other custom fields to the “msg” field. Click the send test button at the top to test that everything works fine. Make sure the test message is being delivered to a phone number you have access to.

If you get anything other than a 200 and ok response, you’ll need to make sure that you have setup everything correctly as show from the beginning of this tutorial.

Finally, click done and review your workflow before starting the campaign. Engineering teams can easily set up this workflow for their marketing teams. In the future, if the marketing team needs to start another campaign, they can simply duplicate the webhook settings by clicking the copy from workflow button and searching for the previous campaign that contains the webhooks setting.

And that’s how you save your company thousands of every month on Marketing SMS by using a local SMS provider other than Twilio!

Firebase Functions to Build a Serverless CRUD App

Adebola — Sat, 24 Jun 2023 23:28:47 +0000

Firebase is a powerful backend service provided by Google that speeds up Web Development by providing a BaaS (Backend-as-a-service) infrastructure. Firebase allows Engineering teams to quickly build out and prototype applications without the need to worry about common backend services like authentication, authorization, database provision, task schedulers (thank you cloud functions!), and more! Some of the features listed above are different services within the Firebase console — e.g Firestore is Firebase’s database service.

Firebase can be integrated with a web or mobile application using any of the available SDKs. In this project, we’ll be using the Firebase JavaScript SDK.

In this article, we’ll look at some of the most common functions you’ll need to build out a Backend using Firebase’s Firestore database and auth service. Think of this as a Cheat sheet to avoid reading the firebase docs.

Getting Started with Firebase

To get started setting up your firebase service, simply head over to https://firebase.google.com/, make sure you’re signed in with your Google account, and hit the Get started button.

On the Welcome to Firebase screen, click Create Project to spin up a new firebase project. Give your project a name, accept the terms and conditions and let’s dance! You’ll be brought to the firebase console. Next, select your project from the list of projects and click Firestore Database to the left of your dashboard. From here, we can manage everything to do with our Databases.

By default, Firebase allows anyone to read and write from your database for a period of 30 days — as long as they have your keys. You can see your database rules by going under the rules tab on the Firestore page in your firebase console. Make sure to edit these rules when you’re ready to go to PROD.

Adding Firebase to your Project

To add Firebase to your project, you’ll need a set of keys. Click on the gear icon next to Project Overview to access the keys for your project.

We’ll be integrating firebase into our React project. To set up Firebase in your project, run the command;

npm install firebase

This will add the Firebase SDK to your project. Create a .env file in the root directory of your project and set the following variables. You can get the values from the Project Settings section above.

apiKey= YOUR_KEY
authDomain= YOUR_KEY
projectId=YOUR_KEY
storageBucket=YOUR_KEY
messagingSenderId=YOUR_KEY
appId=YOUR_KEY

With your environment variables set up, we’re ready to start adding functions.

Setup Firebase in Your Codebase

We’ll now run through getting Firebase setup within our app. In the root directory of your project, create a folder named utils and a file called firebase.js. You can follow whatever directory structure you prefer but I like to setup my projects like this.

In your firebase.js file, add the following lines. We start off by importing all the functions we need from within the firebase module.

// initialize firebase
import { initializeApp } from 'firebase/app'

// firebase auth service
import {
  getAuth,
  signInWithEmailAndPassword,
  onAuthStateChanged,
  updateProfile,
  signOut,
createUserWithEmailAndPassword
} from 'firebase/auth'

// firebase DB service
import {
  collection,
  getFirestore,
  addDoc,
  getDocs,
  updateDoc,
  doc,
  getDoc,
  setDoc,
  arrayUnion,
  deleteDoc
} from 'firebase/firestore'

const firebaseConfig = {
  apiKey: process.env.apiKey,
  authDomain: process.env.authDomain,
  projectId: process.env.projectId,
  storageBucket: process.env.storageBucket,
  messagingSenderId: process.env.messagingSenderId,
  appId: process.env.appId,
}

// initialize firebase
export const app = initializeApp(firebaseConfig)

// connect to firebase auth with your credentials
export const auth = getAuth(app)

// connect to firebase db with your credentials
const db = getFirestore(app)

On to the next!

Auth

What’s one thing every app must have? You guessed it! Auth!

Firebase allows you to use sign-in providers like Google, Twitter, Microsoft or Facebook to allow your users sign in with their accounts on other platforms. To set this up, simply head over to the Build tab on your Firebase console, click Authentication and then the sign in method tab.

In this article, we’ll be keeping it simple and using the E-mail and password auth provided by Google. To get started, under the Users tab, click Add user.

This allows you to create a login for users on your platform from inside Firebase itself. To allow users sign up from within your UI, use the following block of code.

const register = async ({ email, password }) => {
  try {
    const { user } = await createUserWithEmailAndPassword(auth, email, password)
    return user
  } catch (e) {
    return false
  }
}

For your login flow, call the signInWithEmailAndPassword provided by Firebase, like below.

const login = async ({ email, password }) => {
  try {
    const { user } = await signInWithEmailAndPassword(auth, email, password)

    return user
  } catch (e) {
    return false
  }
}

To check if a user is signed in, use;

const isUserSignedIn = async () => {
  onAuthStateChanged(auth, (user) => {
    if (user) {
      // get signedIn user
      const uid = user.uid
      console.log(user)
      return uid
    } else {
      return false
    }
  })
}

To sign out a user from your service;

const signOutUser = async () => {
  await signOut(auth)
}

To update a user’s metadata, use;

const updateUserProfile = async ({ displayName, photoURL }) => {
  try {
    await updateProfile(auth.currentUser, {
      displayName,
      photoURL,
    })
  } catch (error) {
  }
}

Adding new Collections and Documents to Firestore

Firebase is a No-SQL database. This means that the Database structure is a little bit different from conventional SQL databases. For example, while SQL databases are based off the idea of Tables and Columns, No-SQL databases use documents and collections to structure data. Collections can be likened to tables and documents to columns — they’re not like for like though and shouldn’t be considered as such.

Let’s create a User’s collection in our DB. To create a new collection, we’ll simply add a document to the collection in our codebase. Firebase is intelligent enough to create the collection and a document at the same time even if the collection does not already exist.

// take in the user's details from the UI
const addNewUser = async ({ phoneNo, name, email, address, cars = '' }) => {

  try {
    // add a new Doc to the User's Collection
    const userRef = await addDoc(collection(db, 'users'), {
      phoneNo,
      name,
      email,
      address,
      cars
    })

    console.log('Document written with ID: ', userRef.id)
  } catch (e) {
    console.error('Error adding document: ', e)
  }
}

Getting all the Data in a Firestore Collection

If we want to get all the users in our database for example, we can use the getDocs() function.

const getCollection = async () => {
  try {
    const users = []

    const querySnapshot = await getDocs(collection(db, 'users'))
    querySnapshot.forEach((doc) => {
      users.push({ user: doc.data(), docId: doc.id })
    })

    return users
  } catch (error) {
    console.log(error)
  }
}

Update a Record in Firestore

If you have a user in the DB already, you can update their records in the DB.

// Update the user's details
const updateUserPhoneNo = async ({ phoneNo, user }) => {

  try {
    const userRef = doc(db, 'users', [USER_DOCUMENT_ID])

    // Update the User's Collection
    const userRef = await updateDoc(userRef, {
      phoneNo,
    })

    console.log('Document written with ID: ', userRef.id)
  } catch (e) {
    console.error('Error adding document: ', e)
  }
}

For the block of code above to work, you’ll need to know the USER_DOCUMENT_ID to look up the user and update the user’s records.

Firebase will automatically generate a Document ID for data written to the database. While writing to the DB, this ID is generated after the document has been written which may make it a little difficult to update the record in the future. To prevent this, I prefer to use a unique ID to identify unique users in my database and subsequently use that ID to look up a user’s records in my database. You can use the popular UUID npm package to generate these IDs.

For example, we can change our function to add a user to the following;

// take in the user's details from the UI
const addNewUser = async ({ phoneNo, name, email, address, cars = '' }) => {

  const userId = uuid_v4() // generate the userId
  const userRef = doc(db, 'users', userId) // use the userId generated to create a docId
  const data = {
      phoneNo,
      name,
      email,
      address,
      cars,
      userId // save the userId to the user record
    }

  try {
    // add a new Doc to the User's Collection
    await setDoc(userRef, data, { merge: true })
    console.log('Document written with ID: ', userRef.id)

  } catch (e) {
    console.error('Error adding document: ', e)
  }
}

This would mean that our update function from earlier will look like;

// Update the user's details
const updateUserPhoneNo = async ({ phoneNo, user }) => {

  try {
    const userRef = doc(db, 'users', user.userId) // use the userId to find the user in the DB

    // Update the User's Collection
    const userRef = await updateDoc(userRef, {
      phoneNo,
    })

    console.log('Document written with ID: ', userRef.id)
  } catch (e) {
    console.error('Error adding document: ', e)
  }
}

Note that addDoc() and setDoc() are slightly different in the way they work. addDoc will automatically generate a Document ID for your document while writing to the DB while setDoc allowing you to specify the Document ID you’ll like to use. For writing data that you’ll want to look up later, using setDoc is advisable to allow for easier look-up.

Update an array Record in Firestore

If you have a record in your database that takes in an array and you need to update that record, use the array_union function. For example, imagine that our user has some cars in his Garage.

// Update the user's details
const updateUserPhoneNo = async ({ phoneNo, carName }) => {

  try {
    const userRef = doc(db, 'users', [USER_DOC_ID]) // USER_DOC_ID is the userId if you followed the setDoc example

    // Update the User's Collection
    const userRef = await updateDoc(userRef, {
      cars: arrayUnion({
          carName: carName,
      }),
    })

    console.log('Document written with ID: ', userRef.id)
  } catch (e) {
    console.error('Error adding document: ', e)
  }
}

Deleting a Document in Firestore

const deleteUser = async ({ user }) =>{
  try {
    const userRef = doc(db, 'users', user.userId)
    await deleteDoc(doc(db, "users", userRef));

  } catch (e) {
    console.error('Error adding document: ', e)
  }  
}

Rounding Up

With the functions above, you can create your own application by using Firebase as a backend service. The functions above list all the CRUD operations you need to create your own backend service. To summarise;

setDoc or addDoc allows you to CREATE a new firestore document/collection.

getDoc allows you to READ the data within your firestore collection

updateDoc allows you to UPDATE a document within a firestore collection

deleteDoc allows you to DELETE a document within a firestore collection.

For more information, the Firebase docs provide a complete resource for all firestore functions and features.

A day in the life of a remote Software Engineer from Nigeria

Adebola — Thu, 06 May 2021 17:19:01 +0000

This article was originally published on the Aeeiee Blog.

January 2021 Update: This article was originally written in 2020. It’s now 2021 and thankfully, many more companies are learning to cope better with COVID. Let’s hope that this year brings in an effective Vaccine and things go back to some sort of normalcy.

2020 has been a year! There has been enough significant events in this year to take up at least 5 years. With the COVID-19 global pandemic hitting businesses this year, it has been a difficult time for many businesses. It has also forced many businesses to transition to remote work and a widespread acceptance of remote work as the future of many white collar jobs.

Transitioning a company to one that allows for remote work is a difficult process on its own but making that change during a pandemic is even more difficult. Luckily for us at Aeeiee, as a software company, making that transition has not been too arduous and I believe the key to this has been in the recruitment and training process.

With staff members across the US, India, and Nigeria, having a process that works and allows everyone to collaborate effectively is key to ensuring high quality output within a remote development team.

Starting at Aeeiee

I joined Aeeiee in September of 2020 as the company started to ramp up its staff strength and transition to remote work. As someone who has been through several recruitment processes, I particularly liked the one at Aeeiee. The entire process from application to getting an offer took about 2 weeks – meaning that if you apply here, you aren’t left in limbo trying to figure out whether or not you’ll be offered a role and how quickly you will get a response to your application.

The interview process

The first stage was a timed online exam. It contained an aptitude test, an English test, and a couple of coding challenges. The second stage was to write an essay summarising an excerpt from the book The Falsification of Afrikan Consciousness, by Dr. Amos Wilson – a text I found very insightful, making it more than just a part of the recruitment process for me.

The final interview was a 15 min presentation on any topic of choice with the rest of the Aeeiee team present. They got to ask me both technical and career related questions. I was impressed that other members of the team got a say in selecting the teammates they may potentially work with which clearly showed that the opinion of each person on the team was highly valued – another reason to join the team at Aeeiee.

A day in the life of an Aeeiee Dev

At Aeeiee we are an Agile company, utilizing the Scrum methodology with “sprints” lasting 2 weeks. This means that we break down our projects into small tasks, weigh them, in other words – determine how long or difficult a piece of work is and then focus intensely on completing those tasks within the sprint.

Here’s a quick breakdown of what a typical day at Aeeiee looks like for me. All times below are in Nigerian time (WAT).

7:00am – I typically wake up around this time. Toss and turn for a bit, get up, grab my running shoes and head out the door for my every-other-day run. I’m training with the Nike run app and loving that. I’m training to hopefully run a 10K at the next Lagos City Marathon and if I don’t hit that goal, I will run at a 5k meet instead.

Once done with my run, I’d typically get in a strawberry smoothie with a dash of tigernut milk (considered a superfood) or a salad – getting all the nutrients you can get in is important for your mind to run optimally as a dev.

Afterwards, I’d typically get some rest, read tech blogs or spend time writing down ideas on open source projects I’d like to build or contribute to. Or maybe just run any errands I need to.

12:00pm – 12:15pm: Clock in for the day. At this time, the team in the US is still asleep while the team in India has gotten through a couple of hours of their workday already.

We use Tsheets to track our time and tasks – I love the app and totally recommend it. We track our time in 15 min increments.

After clocking in, I check my emails and slack messages first to see if there are any urgent requests or information I need to know.

Once done with that, I head over to our Jira board (we manage our workflow using Jira and use Confluence for documentation) to check if my team lead has left any new comments for me on the tickets I’m working on.

12:15pm – 2:30pm: Start work on a new ticket or continue work on a ticket I’ve been working on.

2:30pm – 2:45pm: Jump on our daily stand-up call. On this call we talk about what we did the previous day and what we plan to get done for the day. We also bring up any blockers we may be having. This is an interesting call because while it’s already afternoon here in Lagos, it’s late in the evening in India and it’s the early hours of the morning in Arizona.

2:45pm – 3:00pm: I’d typically take a short break at this point. Protect your eyes! They’re the only ones you got! I also make sure to get in about 4-5L of water each day

3:00pm – 4:30pm: Continue work on the ticket I’m working on. I may hop on a call with teammates to get help or help out anyone else with their ticket. In between these times, I’m thinking about lunch and what to have – Jollof rice, Plantains or Àmàlà? More recently, since its emergence as a social media sensation on TikTok, I’ve been considering Fufu. I’m also attempting to make a mental decision on whether to order from a restaurant nearby or cook something.

4:30pm – 5:30pm: At this point, I’m usually a little jittery and so I take a 1-hour break. I’d eat some lunch and maybe take a walk down the street.

5:30pm – 5:45pm: Get back to work. Daydream a little while mentally trying to get my mind back into work mode.

5:45 – 8:00pm: I may be on any one of Google/Stackexchange/YouTube or the Php docs looking for anything that may help me get my ticket over the line. If I’m able to complete the ticket by the end of the day, I’ll move the ticket to in review to trigger a code review.

Code reviews are something we take seriously at Aeeiee as it helps us ensure everyone is writing code in a similar way that makes it easy for any new developer joining the project to maintain the code. It also ensures that we’re architecting code in a streamlined manner and following best practices.

8:00pm: I clock out for the day and make mental notes of questions or thoughts I may have had during the day that I need to speak to anyone on the team about at the next standup.

The most important things at Aeeiee

Our CEO always says there’s one thing that’s the most important thing at Aeeiee – and that is correctly tracking time. But, I think there are 2 things. And those 2 things are what helps us get better each day – Time tracking and Training. In my first month at Aeeiee, I spent the entire month learning the Aeeiee development stack – PHP and WordPress while also learning Jira and Agile.

The productivity gains from those training are immense. As every developer will agree, a software training course cannot cover every use case and you may still need a number of resources to complete tasks but it’s always a good way to lay a solid foundation for learning more advanced concepts in the future.

The best thing about training at Aeeiee? You get to do them on company time which means you’re paid to do them!

Team bonding at Aeeiee

Gaming

On Wednesdays, we have a one hour gaming session. So far it has been a great way to bond with everyone else on the team. We’ve played games like Among us, Call of Duty, and Charades amongst others! Everyone gets to suggest a new game to play every now and then.

Journeylines

Every 2nd Friday after we complete our Sprint retrospective, we do this thing where one or two members of the team basically tell us their life stories. We haven’t gotten through to hearing everyone’s story yet but I’ve found these stories incredibly fascinating and I really believe that they’ve made us a closer knit team. It makes you see your teammates as people with stories and experiences and not just developers who write code.

African Leadership Training

Something else that’s very important to us at Aeeiee is the African Leadership Training that all the West African developers can take. This training is delivered by our CEO with the goal being to help us understand our history as African people and using that knowledge to transform the way we think about Africa, how we approach the unique challenges we face as developing countries, and the way we see ourselves as people of African descent. It has helped us become more aware of the world around us.

Wrapping it all up!

Working remotely as a developer at Aeeiee has been great! The lifestyle is certainly something I’d choose over and over again. Luckily for us at Aeeiee, we’ve been able to find a balance around the usual downsides that come with remote work; not being able to disconnect from work, being overworked amongst others. We try to make sure our projects are well scoped out and planned ahead of time to ensure that developers do not have to work overtime unless absolutely necessary. Also, between our daily standups, journeylines and gaming sessions, we’ve been able to find a system that works and allows us deliver high quality work for clients.

What are you waiting for? Come join the team!

How to to Upload files to S3 with the AWS JavaScript SDK and WordPress

Adebola — Fri, 23 Apr 2021 08:36:14 +0000

This article was first published on the Aeeiee Blog.

Why AWS?

AWS has a ton of amazing services to help in the software development process. From services that help you cache static assets like CloudFront, to services that scale based on the traffic to your application like ElasticBeanstalk (this comes with a load balancer by default). At Aeeiee, we're huge fans of AWS. Our servers run on EC2 instances and we even use AWS CodeCommit for version control. AWS provides high availability and has been the go-to cloud solutions provider for millions of developers for sometime now.

In this article, we'll explore one of AWS' most popular services - AWS S3. You'll learn how to use AWS's S3 to store and manage digital assets on your WordPress site.

Let's jump into it!

Creating an AWS account

Creating an AWS account is pretty straightforward. Follow the link here to sign up. You'll need a Credit Card to get started. Amazon uses it to verify your identity and keeps it on file for when they need to bill you. The steps needed in this tutorial are covered under the free tier. You can also destroy the bucket you've created when done to ensure your credit card is not charged.

Getting your S3 Credentials

On your AWS Dashboard, search for S3 in the search bar.

Click the first option - S3.

Next, Click the Create bucket button.

Give your bucket a name. We'll call ours aeeiee-test. You can leave the default region. Ours is currently set to EU (London) - EU West 2. You can leave the other options as they are.

To get your Access Key ID and Secret Access Key, click on your username in the top right of the dashboard.

Then, select the my security credentials option. Scroll down to the Access keys (Access Key ID and Secret Access Key) section and click to expand it. Click the create new access key button to create a new access key. You'll be able to see your Secret Access Key here. You can download the file containing your keys to your computer or simply copy and paste the keys somewhere secure for safe keeping. Once you exit this popup, you may be unable to retrieve your secret access key again.

Setting up the AWS JS SDK for use in WordPress

Next, we're going to create a Plugin to handle our uploads. To avoid running into issues, we've found that the best way to load the AWS S3 SDK is to link to the version hosted by AWS rather than self-hosting a copy of it on our own servers.

In your plugins directory, create a new folder - aeeiee-s3-uploader. Inside this folder, create a new file. We'll call ours index.php. Also, create two additional files: aeeiee-s3.js and aeeiee-s3-views.php. The JavaScript file will hold all the JS code to handle uploading files to our S3 bucket while the aeeiee-s3-views.php file will handle displaying HTML content on the page.

We will create a plugin file with the information below. This ensures that WordPress can correctly detect and load our plugins and make it available to us on the Plugins page.

<?php
/**
 * Aeeiee S3 Plugin
 *
 * @author              Aeeiee Inc.
 *
 * @wordpress-plugin
 * Plugin Name:        Aeeiee S3 Plugin
 * Description:        This plugin allows us upload files to an Amazon S3 bucket.
 * Author:            Aeeiee Inc.
 * Author URI:        https://www.aeeiee.com
 * Version:            1.0
 * Requires PHP:     7.2
 */

Next, we enqueue the AWS JS SDK script using the link provided by AWS.

add_action('admin_enqueue_scripts', function () {
    // loads the AWS SDK
    wp_enqueue_script('aeeiee-aws-sdk', 'https://sdk.amazonaws.com/js/aws-sdk-2.828.0.min.js');

});

Walkthrough

With our scripts enqueued, we would need to create a new page when our plugin is activated. When a user navigates to this page, they'll be presented with an upload form. Once they hit the upload button, the file they've selected will be uploaded to our S3 bucket.

Creating a Page and enqueuing Scripts

First, we'll create a new page when the plugin is activated using the add_menu_page API provided by WordPress. See code below.

We want to ensure that our JavaScript files are enqueued only on the pages we need them, to avoid conflicts with other plugins. To do that, we use the $hook_suffix variable that's automatically passed to the admin_enqueue_scripts hook callback. The $hook_suffix tells us what page we're on and we can use that to activate our JavaScript file only on the pages we want.

We also use wp_localize_script API in WordPress to pass our AWS keys as variables to our JavaScript file using PHP.

NB: Replace YOUR ACCESS KEY ID and YOUR SECRET ACCESS KEY with the relevant values you obtained when you created your AWS account.

add_action('admin_menu', 'aeeiee_s3_uploader');

function aeeiee_s3_uploader()
{
    // add a new page to the menu
    add_menu_page('Aeeiee S3 Page', 'Aeeiee S3 Uploader', 'manage_options', 'aeeiee-s3-uploader', 'aeeiee_s3_callback', 'dashicons-chart-pie');

    // enqueue the JS scripts in the admin page
    add_action('admin_enqueue_scripts', 'aeeiee_s3_enqueue_scripts');
}

function aeeiee_s3_enqueue_scripts($hook_suffix)
{
    // if on the uploader page in the admin section, load the JS file
    if ($hook_suffix === 'toplevel_page_aeeiee-s3-uploader') {
        wp_enqueue_script('aeeiee-js', plugins_url('/aeeiee-s3.js', __FILE__));

        $aws_vars = array(
            'accessKeyId' => "YOUR ACCESS KEY ID",
            'secretAccessKey' => "YOUR SECRET ACCESS KEY",
        );

        // pass AWS Keys from the server to the client
        wp_localize_script('aeeiee-js', 'vars', $aws_vars);
    }

}

With our JavaScript file enqueued. Time to finally hook up our views too. Still within the index.php file, add the following:

function aeeiee_s3_callback(){
    include_once 'aeeiee-s3-views.php';
}

In the aeeiee-s3-views.php file, add the code to display the HTML on the frontend.

<section>
    <label for="s3-uploader"><strong>Upload a file to our S3 Bucket! </strong></label>
    <div>
        <input type="file" id="file-uploader" />
        <button id="start-upload">Start Upload</button>
    </div>
    <div>
        <p class="message"> </p>
    </div>
</section>

We've also added a paragraph tag with a class of message that we can use to inform users about the status of their upload.

Uploading the Files to S3

Finally, for the main bit. We will write this part in JQuery. Head into your aeeiee-s3.js file. First step is to initialize the SDK with our Keys.

// initialize AWS SDK
var s3 = new AWS.S3({
 accessKeyId: aws_vars.accessKeyId, 
secretAccessKey: aws_vars.secretAccessKey, 
region: 'eu-west-2'
});
const bucketName = "aeeiee-test";

Here's how the upload is going to work.

When a user selects a file, we will display a "Starting your file Upload to AWS S3...." message.

When the upload is done, we will once again inform the user by displaying a "File successfully uploaded to S3" message.

Here's the complete code for the JavaScript upload process.

jQuery(document).ready(function ($) {
  const fileUploadInput = $("#file-uploader");
  const messageSection = $(".message");

  $("#start-upload").on("click", function () {
    const file = fileUploadInput[0].files[0];

    messageSection.html("Starting your file Upload to AWS S3....");

    var upload = new AWS.S3.ManagedUpload({
      service: s3,
      params: {
        Body: file,
        Bucket: "aeeiee-test",
        Key: file.name,
      },
    });

    //  start the upload
    upload.send(function (err, data) {
      if (err) {
        console.log("Error", err.code, err.message);
        alert("There was an error uploading the file, please try again");
      } else {
        messageSection.html("File successfully uploaded to S3");
      }
    });
  });
});

Listing files in the bucket and downloading files

The AWS SDK provides high level APIs that allow us to perform a number of actions on buckets. There's a listObjects API that allows us list the objects in a bucket.

In our case, we will also be using the getSignedURL API to generate URLs that expire in 2mins. These URLs will be attached to objects from our buckets when displaying them on the frontend. This way, if a user clicks on that link within 2mins, the file(object) will be downloaded to their machine.

// Call S3 to obtain a list of the objects in the bucket
 s3.listObjects({ Bucket: bucketName }, function (err, data) {
   if (err) {
     console.log("Error", err);
   } else {
     console.log("Success", data.Contents);
     data.Contents.map((content) => {
       objectsSection.append(
         `<li><a href="${getPresignedURL(content.Key)}">${
           content.Key
         }</a></li>`
       );
     });
   }
 });

 function getPresignedURL(key) {
   return s3.getSignedUrl("getObject", {
     Bucket: bucketName,
     Key: key,
     Expires: 120,
   });
 }

** Final Result **

Handling CORS errors

You'll most likely run into CORS errors when trying to connect to your AWS bucket from your local machine/server. To resolve this problem, head back to your AWS Admin console and head to the Buckets section of the Admin area. Click on the name of your Bucket - in our case, we've called it aeeiee-test. Then Click permissions. Scroll down to the CORS section. Add the following JSON code.

In our case, we're giving permissions to our local development server - https://aeeieetests.local to read from our bucket (GET) and upload objects to our bucket (POST). You will need to change the AllowedOrigins to use your local host environment. Our dev server can also make PUT or PATCH requests. In production, you may want to alter the permissions given to users accessing your buckets from different environments.

You can read more on CORS in the AWS documentation here.

Security

AWS is able to protect your bucket from unauthorised access by enforcing that buckets that do not have public access, must have explicit permissions given to hosts/domains to access them.

On the other hand, with our current setup, our AWS credentials will be exposed to the Client and can be accessed from the console. AWS frowns on this. The way we solve this problem internally is by creating a temporary bucket using the process described in this article and then moving the files from there to a permanent bucket using PHP on the server. This way we are able to keep our credentials from being exposed on the client side. We'll explain the exact process for this in a future article.

Versioning

When the same object is uploaded to your bucket more than once, AWS will automatically overwrite the previous object in the bucket. To avoid this, you can ensure that your files have unique file names before starting the upload to your S3 bucket.

The complete version of the code used in this example is available here.

How to collect payments with PayPal in your React application

Adebola — Mon, 22 Feb 2021 14:50:02 +0000

I recently built a project that required integrating with Paypal to collect payments from users. After spending hours trying to implement Paypal payments using the Paypal JavaScript SDK, I realized that this was going to be a uphill task. Thankfully, I found an NPM package that already abstracted the SDK into React components for us to use. In this article, I’ll show you exactly how to collect payments using Paypal in your React application.

Getting started - setup your Paypal account

First steps first. Head over to paypal to create an account. Once done, head to the paypal developer screen.

Getting your credentials

Next step is to grab your credentials i.e your clientId.

Navigate to Dashboard > My Apps & Credentials .

Click the Sandbox tab. Then click the on the Default Application link. It will bring you to a page containing your clientId.

Your sandbox account will be an email address that you can use to make test payments while your client ID is what Paypal uses to connect your Application to your paypal account.

Setup your react project

For this example, our React project will be built using NextJS.

If you’ll like to follow along, you can skip the next couple of steps by simply cloning my repo. Run the git clone git@github.com:onedebos/nextjs-paypal-example.git command to do so. Then checkout to the starter branch with git checkout starter . If you clone the starter repo, you can skip to the Setup project structure section.

Otherwise, here are the steps to follow.

We’ll be using one of the NextJS example projects with tailwindcss already configured.

Run the command yarn create next-app --example with-tailwindcss next-paypal-example to create a NextJS application with Tailwindcss already configured.

Setup Project Structure

We’ll create a new folder in our current project called utils. Inside our utils folder, we’ll create a constants folder. Within the constants folder, add an index.js file.

Your folder structure should now look like

/utils/constants/index.js

Install the Paypal package
Install the react paypal package using yarn add @paypal/react-paypal-js@4.1.0.
Make sure to use the package at version 4.1.0 as i've found that people are having issues with the later version. I haven't had the time to try out later versions yet.

Collect Payments

Time to start collecting Payments!

In your utils/constants/index.js file, add your clientId.

export const PAYPAL_CLIENT_ID = {
    clientId: 'ATVzbN_TdDnGGVfyPxu6J-5ddFftdqu8l6tFpIy5TEZ7hjbx7y9Q4TY0ICI0Pot2dBBABc-myxZgYOfj'
}

In your _app.js file, bring in the PayPalScriptProvider using import { PayPalScriptProvider } from "@paypal/react-paypal-js";.

Then, wrap your Components with that tag.

import { PayPalScriptProvider } from "@paypal/react-paypal-js";
    import {PAYPAL_CLIENT_ID} from '../utils/constants'
    function MyApp({ Component, pageProps }) {
      return(
        <PayPalScriptProvider options= {{"client-id": PAYPAL_CLIENT_ID.clientId }}>
            <Component {...pageProps} />
        </PayPalScriptProvider>
      ) 
    }
    export default MyApp

Next, head into pages/index.js to create the page that collects the payments and bring in the PayPal Button.

Let’s create some state to hold data.

      const [succeeded, setSucceeded] = useState(false);
      const [paypalErrorMessage, setPaypalErrorMessage] = useState("");
      const [orderID, setOrderID] = useState(false);
      const [billingDetails, setBillingDetails] = useState("");

The orderId is the most important piece of state we care about. When the user clicks the Pay with PayPal button, Paypal will generate an orderId for the order and return that back to us. In the createOrder function below, we can see this in action.

      // creates a paypal order
      const createOrder = (data, actions) => {
        return actions.order
          .create({
            purchase_units: [
              {
                amount: {
                  // charge users $499 per order
                  value: 499,
                },
              },
            ],
            // remove the applicaiton_context object if you need your users to add a shipping address
            application_context: {
              shipping_preference: "NO_SHIPPING",
            },
          })
          .then((orderID) => {
            setOrderID(orderID);
            return orderID;
          });
      };

Along with the createOrder function, we need another function that runs when the payment is approved - onApprove

      // handles when a payment is confirmed for paypal
      const onApprove = (data, actions) => {
        return actions.order.capture().then(function (details) {
          const {payer} = details;
          setBillingDetails(payer);
          setSucceeded(true);
        }).catch(err=> setPaypalErrorMessage("Something went wrong."));
      };

Lastly, we can plugin out PayPal button from our react-paypal-js package to handle the payments.


        <PayPalButtons
                style={{
                  color: "blue",
                  shape: "pill",
                  label: "pay",
                  tagline: false,
                  layout: "horizontal",
                }}
                createOrder={createOrder}
                onApprove={onApprove}
        />

Paypal will redirect the user to a new window to complete the payment.

You can test this out using the sandbox email provided on the Paypal developer dashboard.

The full repo for the code is here.

How to use cookies for persisting users in Nextjs

Adebola — Thu, 29 Oct 2020 10:48:26 +0000

With LocalStorage

There are a number of ways to persist users in a React or Single Page Appplication. A lot of times, devs generally use localStorage to store user data and load the data from there when required. While this approach works, it's not the most effective way as it leaves users vulnerable to attacks. Using cookies is a little safer although it's still not the safest option. Personally, I prefer a mixture of using cookies and JWT'sJSON Web tokens with expiry to persist user session and to force a user to re-login when their session expires. Using JWT's is out of the scope of this article.

As LocalStorage is undefined on the server-side(since localStorag does not exist on the server), it's impossible to access localStorage before rendering a route. As such, our best bet is to check if a user's cookie is valid on the server side before rendering a route.

Getting started using cookies in React/NextJS

To use cookies in NextJS, we need to install 2 packages. For this tutorial, we'll be using cookie and react-cookie. React-cookie allows us set the cookie from the client side while the cookie package lets us access the set cookie from the server-side. Install both packages by running

npm install react-cookie cookie

Cookie-cutter is a tiny package that does the same thing as react-cookie.

Setting a cookie

With both packages installed, It's time to set a cookie. Usually, we set a cookie for a user once they've succesfully signed in or signed up to our application. To set a cookie on Sign in, follow the example below.

// pages/login.js
import { useCookies } from "react-cookie"

const Login = () => {
  const [cookie, setCookie] = useCookies(["user"])

  const handleSignIn = async () => {
    try {
      const response = await yourLoginFunction(username) //handle API call to sign in here.
      const data = response.data

      setCookie("user", JSON.stringify(data), {
        path: "/",
        maxAge: 3600, // Expires after 1hr
        sameSite: true,
      })
    } catch (err) {
      console.log(err)
    }
  }

  return (
    <>
      <label htmlFor="username">
        <input type="text" placeholder="enter username" />
      </label>
    </>
  )
}

export default Login

In the snippet above, we call the setCookie hook from react-cookies and set it to a default name. In our case, that's user. We then
make a request to sign in a user by calling a function to log the user in. We take the response from that API call, stringify the data(cookies are formatted as text) and store that data in a cookie.

We also pass some additional options to the cookie including path - makes sure your cookie is accessible in all routes, maxAge, how long from the time the cookie is set till it expires and sameSite. Samesite indicates that this cookie can only be used on the site it originated from - It is important to set this to true to avoid errors within firefox logs.

Giving your app access to the Cookie

To ensure that every route in our application has access to the cookie, we need to wrap our APP component in a cookie provider.

Inside _app.js, add the following bit of code.

// pages/_app.js
import { CookiesProvider } from "react-cookie"

export default function MyApp({ pageProps }) {
  return (
    <CookiesProvider>
      <Component {...pageProps} />
    </CookiesProvider>
  )
}

Setting up the function to parse the cookie

Next, we need to setup a function that will check if the cookie exists on the server, parse the cookie and return it. Created a new folder called helpers and within that add an index.js file.

Inside this file, add the following piece of code.

// helpers/index.js

import cookie from "cookie"

export function parseCookies(req) {
  return cookie.parse(req ? req.headers.cookie || "" : document.cookie)
}

The function above accepts a request object and checks the request headers to find the cookie stored.

Accessing the cookie within your component

Finally, we will use getInitialProps in our component to check if the user already has a valid cookie on the server side before rendering the requested route. An alternative to this approach is using getServerSideProps.

import { parseCookies } from "../helpers/"

export default function HomePage({ data }) {
  return (
    <>
      <div>
        <h1>Homepage </h1>
        <p>Data from cookie: {data.user}</p>
      </div>
    </>
  )
}

HomePage.getInitialProps = async ({ req, res }) => {
  const data = parseCookies(req)

if (res) {
    if (Object.keys(data).length === 0 && data.constructor === Object) {
      res.writeHead(301, { Location: "/" })
      res.end()
    }
  }

  return {
    data: data && data,
  }
}

Within getInitialProps, we're passing in the request object(req) that's available to us on the server-side in NextJS to the parseCookies function. This function returns the cookie to us which we can then send back to the client as props.

We also do a check on the server to see if the response object is available. The res object is only available on the server. If a user hits the HomePage route using next/link or next/router, the res object will not be available.

Using the res object, we check if there are cookies and if they're still valid. We do this check using the res object. If the data object is empty, it means the cookie isn't valid. If the cookie isn't valid, we then redirect the user back to the index page rather than showing a flash of the HomePage before redirecting the user.

Note that subsequent requests to pages containing getInitialProps using next/link or next/router will be done from the client side. i.e The cookie will be extracted from the client rather than the server side for other routes that are accessed via using next/link or next/router

And with that, you can now store cookies for users in your application, expire those cookies and secure your app to a good extent.

How to show a loading bar when changing routes in NextJS

Adebola — Thu, 29 Oct 2020 10:38:45 +0000

Setting up

I spent days trying to find the right thing to google on how to setup the blue loading bar that shows at the top of your screen when navigating between routes in NextJS. It's important to have this loading indicator to signify that a route change is occuring to avoid users assuming that the application has frozen.
This article assumes that you already have NextJS setup. To get started, we need to install the nprogress library.
Run

npm install nprogress

In _app.js

Inside pages/_app.js, add the following piece of code.

import NProgress from "nprogress"
import Head from "next/head"
import Router from "next/router"

Router.onRouteChangeStart = url => {
  NProgress.start()
}

Router.onRouteChangeComplete = () => NProgress.done()

Router.onRouteChangeError = () => NProgress.done()

export default function MyApp() {
    return (
        <>
            <Head>
               <link
                rel="stylesheet"
                href="https://cdnjs.cloudflare.com/ajax/libs    /nprogress/0.2.0/nprogress.min.css"
          />
             </Head>
              <Component {…pageProps} key={route} />
        </>
      )
}

Above, we access the Router object available inside next/router to ensure. onRouteChangeStart i.e when a Route change is in progress, NProgress will run i.e NProgress.start. Once the route change is done i.e onRouteChangeComplete, we call the done method on NProgress. We call the same method if there's an error.
I had issues using the NProgress stylesheet from the nprogress package within my application and resorted to using the stylesheet they provide via their CDN. Without the stylesheet, you won't notice anything on the screen.
Now, when you navigate to any page within your application, you should see a blue loading bar at the top of your screen

The easiest way to achieve dark mode in tailwindcss

Adebola — Sat, 05 Sep 2020 21:38:29 +0000

Here's a quickest way I've found to achieve dark and light mode theming in tailwindcss.

In tailwind.config.js

In this file, add the following screens to extend. i.e

module.exports = {
  future: {
    removeDeprecatedGapUtilities: true,
  },
  purge: ['./components/**/*.{js,ts,jsx,tsx}', './pages/**/*.{js,ts,jsx,tsx}'],
  theme: {
    extend: {
      colors: {},
      screens: {
        'light': { raw: '(prefers-color-scheme: light)' },
        'dark': { raw: '(prefers-color-scheme: dark)' }
      }
    },
  },
  variants: {
    backgroundColor: ['responsive', 'hover', 'focus', 'checked'],
  },
  plugins: [],
}

Now, we can do something like dark:bg-red-700.

To test, open your Google dev tools console, click the 3 dots icon, click more tools then select rendering.

Under rendering, scroll down to Emulate CSS media feature prefers-color-scheme. In the dropdown, select prefers-color-scheme: dark

You should see our dark:bg-red-700 now take effect.

How to make your web apps load in less than a second

Adebola — Sat, 05 Sep 2020 11:30:47 +0000

Background

I recently noticed that when I search for certain articles on google and click the search result, the page shows up instantly. I was curious as to how it worked and started to do some digging.

The GIF above shows the preloading effect instantly loading whichwifi - a review app i launched recently. If you click this link, it should open up the whichwifi page without "loading" it.

The tech

The technique used in showing pages immediately a user clicks on the link is not entirely new. It's a technique called prefetching/preloading. I'll explain the difference in a bit. Stick with me.

The gist is, when a link(s) shows up on a webpage, the browser immediately starts to fetch resources for the linked pages within that domain so that when a user clicks the link, they're shown the page instantly.

Next.js makes use of this tech extensively in their framework which makes for better responsiveness and faster page load times.

This wikipedia entry contains some of the pros and cons of prefetching.

Addy Osmani, a software engineer at google, also has a very insightful article on the tech behind preloading and prefetching and how google uses it in search.

Preloading vs Prefetching

There's a slight difference between preloading and prefetching. While preloading allows you load resources ahead of time, prefetching is used for subsequent requests within your site.

How to get started

Next.js

If you're building on the Next.js framework(my favorite React framework btw), prefetching links comes bundled right out of the box. Once a user lands on your site, Next will automatically prefetch all of the pages that are linked on that page.

To preload critical resources before a user lands on your page, instant.page provides a script to help us handle that. Here's a link to my github repo showing how I achieved preloading by modifiying the _document file in next.js

quicklink

Google also has a package that allows you preload websites within your viewport. It's called quicklink

Instant.page

Instant.page provides a script that you can include in your website to automatically prefetch your site when a user hovers over the link from anywhere.
NB - It doesn't always work, but when it does, it's great!

Do it yourself

Most sites use preloading to load the fonts on their website before a user gets to the site to avoid users seeing a strange font for a split second before seeing the actual font. You can achieve this by using

<link rel="preload" as="font" type="font" href=[link_to_font] />

Possible issues

You may run into issues with preloading if your application isn't server-side rendered but generally I've found that preloading works most times even if your site is statically rendered.

Conclusion

In conclusion, as developers, we are always looking for ways to give users a better experience. Preloading/prefetching resources speeds up time to first contentful paint, time to interactive and gives your users a better experience on your site resulting in higher conversions.