DEV Community: Fernando Mendez

WebSockets with React, Redux, and Ruby on Rails

Fernando Mendez — Sat, 08 Jan 2022 22:32:20 +0000

Note: all the code for this post can be found here(frontend) and here (backend/rails)

Let's explore how to integrate Rails ActionCable functionality (WebSockets) with a basic chat application using React and Redux (via Redux Toolkit). I'm only including the most relevant snippets of code, please refer to the code in the repo for the entire context.

This is what we will be building:

Backend

Since I'm using rails as an API endpoint, I'll create the app using the --api flag. This will prevent views from being generated when we call any of the rails generate commands, hence avoiding unnecessary code. Additionally, we'll use postgresql as the DB.

rails new chat-app-backend-rails --api -database=postgresql

Since we're building our frontend as a separate standalone project, potentially deployed on a different server than our API, we need to allow for cross domain calls. For that, we first add rack-cors on the Gemfile:

gem 'rack-cors'

And then configure it on config/initializers/cors.rb.

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    # In a prod app you'll restrict to specific origin(s).
    # for this will just allow from any.
    origins '*'

    resource '*',
             headers: :any,
             methods: %i[get post put patch delete options head]
  end
end

We then bundle install to install the gem we added.

Our app will simply have User and Messages. Let's create the models for that:

rails generate model User
rails generate model Message

Our User will only have username and status this is what the migration looks like:

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :username
      t.string :status
      t.timestamps
    end
  end
end

And for the Message:

class CreateMessages < ActiveRecord::Migration[7.0]
  def change
    create_table :messages do |t|
      t.string :content
      t.timestamps
    end
  end
end

Our models have a 1-to-many relationship (1 user has many messages). We'll capture that by adding has_many :messages on the User and belongs_to on Message.

class User < ApplicationRecord
  has_many :messages, dependent: :destroy
end

class Message < ApplicationRecord
  belongs_to :user
end

Lastly, we'll add a migration that adds the reference (user_id) to messages.

rails generate migration AddBelongToMessages

With this code:

class AddBelongToMessages < ActiveRecord::Migration[7.0]
  def change
    add_belongs_to :messages, :user
  end
end

Note: We could have added this when we first created the Message migration.

Finally, we run the migrate command:

rails db:migrate

Next, let's add all the routes we'll be using and mount the ActionCable (WebSocket) server:

  resources :messages, only: %i[index]
  resources :users, only: %i[index create] do
    post 'add_message'
    post 'change_status'
  end
  mount ActionCable.server => '/cable'

That's it for the setup. We're now ready to start adding some functionality. Let's start creating the messages and users channels. We'll use these to listen for messages posted on the chat and for users joining.

rails generate channel messages
rails generate channel users

In both generated channels, we'll simply change the subscribed method to specify where we're streaming from:

class MessagesChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'message_channel'
  end

  def unsubscribed; end
end

class UsersChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'user_channel'
  end

  def unsubscribed; end
end

Now we can use the ActionCable.server.broadcast() method to broadcast to all the subscribers on those channels. We want to notify to all subscribers of the user_channel when a user joins the chat. We also want to notify the message_channel after sending messages. Let's do both of those things on the UsersController:

class UsersController < ApplicationController
  def index
    users = User.all
    render json: users
  end

  def create
    user = User.new(user_params)
    ActionCable.server.broadcast('user_channel', user) if user.save
    render json: user
  end

  def add_message
    user = User.find(params[:user_id])
    message = params[:message]
    created_message = user.messages.create(content: message)
    ActionCable.server.broadcast('message_channel', created_message) if user.save
    head :ok
  end

  def change_status; end

  def user_params
    params.require(:user).permit(:username, :status)
  end
end

For completion, we also have our MessagesController that returns all messages for the users who just joined the chat (that way they can see what was said before them joining).

class MessagesController < ApplicationController
  def index
    messages = Message.all
    render json: messages
  end
end

With that, we have all the API calls we need to integrate with our frontend:

rails routes | grep users

user_add_message POST   /users/:user_id/add_message(.:format)

user_change_status POST   /users/:user_id/change_status(.:format)

users GET    /users(.:format)

POST   /users(.:format)                                                                                  users#create



rails routes | grep messages

messages GET    /messages(.:format)

Frontend

For the frontend, I'll be using react with redux and typescript. Let's create the app:

npx create-react-app chat-app-ui --template redux-typescript

This template will give you an application skeleton that uses redux with toolkit already setup (e.g., a sample reducer, a configured store, etc.).

I'll start by creating a /features/users folder. In there I'll add all the api and reducer functionality. In there I created a usersAPI with all the backend calls related to users. For example, this is how we're adding a new user to the chat:

export const addNewUser = async (user: UserType): Promise<any> => {
  const res = await fetch("http://localhost:3090/users", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(user),
  });

  return await res.json();
};

And this is how we handle a user sending a message:

export const sendUserMessage = async (
  data: sendUserMessageDataType
): Promise<any> => {
  const res = await fetch(
    `http://localhost:3090/users/${data.user.id}/add_message`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        user_id: data.user.id,
        message: data.message.content,
      }),
    }
  );

  return await res.json();
};

We will use these API calls indirectly via Redux thunks.

When working with async calls in the frontend, we usually make the async call and if it succeeds, we update the application state (e.g., Redux state) with the results. With thunks, the process is the same, but all is handled in the reducer itself. We only have to dispatch an action and after is fulfilled (e.g., call succeeded) then we update the state.

This is what a thunk looks like for adding a new user and for sending messages:

...
export const addUserAsync = createAsyncThunk(
  'users/addUser',
  async (user: UserType) => {
    const response = await addNewUser(user);
    return response;
  }
)

export const sendMessageAsync = createAsyncThunk(
  'users/sendMessage',
  async (data: sendUserMessageDataType) => {
    const response = await sendUserMessage(data);
    return response;
  }
)
...

We then configure them on the extraReducers section of the createSlice().

...
  extraReducers: (builder) => {
    builder
      .addCase(sendMessageAsync.fulfilled, (state, action) => {
        let updatedUser: UserType = state.value.filter(user => user.id === action.payload.user.id)[0];
        updatedUser.messages.push(action.payload.message);
        state.value = state.value.map(user => user.id !== updatedUser.id ? user : updatedUser)
      })

      .addCase(addUserAsync.fulfilled, (state, action) => {
        state.value.push(action.payload);
        localStorage.setItem("currentUser", JSON.stringify(action.payload));
        state.userLoggedIn = true;
      })
  },
...

You can review the entire reducer here.

To call Rails's ActionCable we have to install the actioncable package.

npm install --save actioncable

This is how we're using actioncable in the Messages.tsx to subscribe to new messages posted:

import { useAppDispatch, useAppSelector } from "../app/hooks";
import { addMessage, selectMessages } from "../features/messages/messagesSlice";
import { MessageType } from "../types";
import Message from "./Message";
import ActionCable from "actioncable";
import { useEffect } from "react";

function Messages() {
  const messages: MessageType[] = useAppSelector(selectMessages);
  const cable = ActionCable.createConsumer("ws://localhost:3090/cable");
  const dispatch = useAppDispatch();

  const createSubscription = () => {
    cable.subscriptions.create(
      { channel: "MessagesChannel" },
      { received: (message) => handleReceivedMessage(message) }
    );
  };

  const handleReceivedMessage = (message: any) => {
    dispatch(addMessage(message));
  };

  useEffect(() => {
    createSubscription();
  }, []);

  return (
    <div className="">
      {messages.map((message) => (
        <Message key={message.id} message={message} />
      ))}
    </div>
  );
}

export default Messages;

We use the same approach on the Users.tsx to subscribe to new users joining the chat.

With everything configured and styled, this is what the entire chat application looks like:

With that, we have an app using WebSockets with React, Redux, and Rails.

Exploring Program Derive Addresses (PDA's) with Solana, Anchor and React

Fernando Mendez — Mon, 13 Dec 2021 20:15:25 +0000

Note: As of the time of this writing (Monday, December 13, 2021), Solana's testnet environment (faucet/airdrop) seems to be having issues. Please select the devnet on the selector (or just don't change it, since is the default value). Remember to change your wallet to point to the devnet network.

Note: all the code for this post can be found here. There's a demo here showcasing the concepts in this post.

Use cases

Let's image the following scenarios. You built an dApp that uses tokens you created / minted. For testing purposes, you want to allow users to self-airdrop some amount of those tokens (on testings environments). The problem is -since you minted the tokens- the one with the authority to both mint more tokens or transfer them is you. That means you have to sign every transaction dealing with those mints.

Another scenario is a user wanting to trade some items with other users. For safety, the items to trade should be put in some sort of temporary account (escrow account) and only be released to a 3rd party they accept the offer. The difficulty is, if the escrow account belongs to the user, they need to approve / sign the transaction for the tokens to be released. We don't want the user to be involved in the release of the items directly.

In both scenarios, we need to have a sort of "proxy" that can sign a transaction on behalf of the owner of the program. For that, we'll need Program Derive Addresses (PDA's).

In the scenarios that I described above, we would need to use Cross-Program Invocations. In both scenarios, we would interact with the Token Program. For the case of airdropping, we will mint more of the existing tokens to a user and in the second case we will transfer tokens.

In both of these scenarios, it is the PDA that would have the authority to sign these transactions in our behalf.

PDA's defined

These are accounts that are owned by a program and not controlled by a private key like other accounts. Pubkey::create_program_address generates these addresses. This method will hash the seeds with program ID to create a new 32-byte address. There's a change (50%) that this may be a point on the ed25519 curve. That means there is a private key associated with this address. In such cases, the safety of the Solana programming model would be compromised. The Pubkey::create_program_address will fail in case the generated address lie on the ed25519 curve.

To simplify things, the method Pubkey::find_program_address will internally call the create_program_address as many times as necessary until it finds a valid one for us.

PDAs in action

To explore PDA's further, I decided to build a farm animal trading app. The animals that you trade are tokens. In this app, PDA are used in 2 different ways. The first way is an escrow account. Users put away (escrow) the tokens they are offering. These tokens will be release if either some other user accept the offer or the user initiating the offer decides to cancel it. In both cases, it is the escrow account itself that has the authority to sign the transferring of tokens to the destination.

Note: For the code snippets, I'll only be showing the relevant sections, and I'll be linking the line number on the repo. All the code can be found here.

Escrow accounts

First, we need to derive an address. This will be our escrow account(code).

    const offer = anchor.web3.Keypair.generate();
    const [escrowedTokensOfOfferMaker, escrowedTokensOfOfferMakerBump] = await anchor.web3.PublicKey.findProgramAddress(
      [offer.publicKey.toBuffer()],
      program.programId
    )

We store the bump so that we don't have to keep recalculating it by call the findProgrammAddress method and having to pass it down from the frontend.

In the contract / program this is how we use it (here you'll find the entire file). Here, we're creating an offer:

    anchor_spl::token::transfer(
        CpiContext::new(
            ctx.accounts.token_program.to_account_info(),
            anchor_spl::token::Transfer {
                from: ctx
                    .accounts
                    .token_account_from_who_made_the_offer
                    .to_account_info(),
                to: ctx
                    .accounts
                    .escrowed_tokens_of_offer_maker
                    .to_account_info(),
                authority: ctx.accounts.who_made_the_offer.to_account_info(),
            },
        ),
        im_offering_this_much,
    )

We're transferring the tokens from the account initiating the offer to the escrow account. We're also specifying how much we're transferring.

At this point, we can either accept or cancel an offer. For the cancelling part:

    // Transfer what's on the escrowed account to the offer reciever.
    anchor_spl::token::transfer(
        CpiContext::new_with_signer(
            ctx.accounts.token_program.to_account_info(),
            anchor_spl::token::Transfer {
                from: ctx
                    .accounts
                    .escrowed_tokens_of_offer_maker
                    .to_account_info(),
                to: ctx
                    .accounts
                    .where_the_escrowed_account_was_funded_from
                    .to_account_info(),
                authority: ctx
                    .accounts
                    .escrowed_tokens_of_offer_maker
                    .to_account_info(),
            },
            &[&[
                ctx.accounts.offer.key().as_ref(),
                &[ctx.accounts.offer.escrowed_tokens_of_offer_maker_bump],
            ]],
        ),
        ctx.accounts.escrowed_tokens_of_offer_maker.amount,
    )?;

    // Close the escrow account
    anchor_spl::token::close_account(CpiContext::new_with_signer(
        ctx.accounts.token_program.to_account_info(),
        anchor_spl::token::CloseAccount {
            account: ctx
                .accounts
                .escrowed_tokens_of_offer_maker
                .to_account_info(),
            destination: ctx.accounts.who_made_the_offer.to_account_info(),
            authority: ctx
                .accounts
                .escrowed_tokens_of_offer_maker
                .to_account_info(),
        },
        &[&[
            ctx.accounts.offer.key().as_ref(),
            &[ctx.accounts.offer.escrowed_tokens_of_offer_maker_bump],
        ]],
    ))

We're sending the tokens back to the account that initiated the offer. Notice that the authority that's signing-off the transaction is the PDA, since it "owns" the tokens. We're also closing the escrow account since it no longer needed.

The last relevant part is the "swapping" of tokens after accepting an offer:

        // Transfer token to who started the offer
        anchor_spl::token::transfer(
            CpiContext::new(
                ctx.accounts.token_program.to_account_info(),
                anchor_spl::token::Transfer {
                    from: ctx
                        .accounts
                        .account_holding_what_receiver_will_give
                        .to_account_info(),
                    to: ctx
                        .accounts
                        .account_holding_what_maker_will_get
                        .to_account_info(),
                    authority: ctx.accounts.who_is_taking_the_offer.to_account_info(),
                },
            ),
            ctx.accounts.offer.amount_received_if_offer_accepted,
        )?;

        // Transfer what's on the escrowed account to the offer reciever.
        anchor_spl::token::transfer(
            CpiContext::new_with_signer(
                ctx.accounts.token_program.to_account_info(),
                anchor_spl::token::Transfer {
                    from: ctx
                        .accounts
                        .escrowed_tokens_of_offer_maker
                        .to_account_info(),
                    to: ctx
                        .accounts
                        .account_holding_what_receiver_will_get
                        .to_account_info(),
                    authority: ctx
                        .accounts
                        .escrowed_tokens_of_offer_maker
                        .to_account_info(),
                },
                &[&[
                    ctx.accounts.offer.key().as_ref(),
                    &[ctx.accounts.offer.escrowed_tokens_of_offer_maker_bump],
                ]],
            ),
            ctx.accounts.escrowed_tokens_of_offer_maker.amount,
        )?;

        // Close the escrow account
        anchor_spl::token::close_account(CpiContext::new_with_signer(
            ctx.accounts.token_program.to_account_info(),
            anchor_spl::token::CloseAccount {
                account: ctx
                    .accounts
                    .escrowed_tokens_of_offer_maker
                    .to_account_info(),
                destination: ctx.accounts.who_made_the_offer.to_account_info(),
                authority: ctx
                    .accounts
                    .escrowed_tokens_of_offer_maker
                    .to_account_info(),
            },
            &[&[
                ctx.accounts.offer.key().as_ref(),
                &[ctx.accounts.offer.escrowed_tokens_of_offer_maker_bump],
            ]],
        ))

We do this is 3 steps. First, we send the tokens wanted to the user that initiated the offer. We then transfer the escrowed tokens to the user accepting the offer. Then, as with the last snipped, we're closing the escrow account since it no longer required.

Airdropping

The other way the application uses PDA is with airdropping. In this case, we want to allow users to self-mint (airdrop) a limited amount of something we own (the tokens). In those cases, the PDA has the authority to sign the minting of new tokens on our behalf.

Same as before, we're using the findProgramAddress to get a PDA:

    const cowSeed = Buffer.from(anchor.utils.bytes.utf8.encode("cow-mint-faucet"));
    const pigSeed = Buffer.from(anchor.utils.bytes.utf8.encode("pig-mint-faucet"));

    const [cowMintPda, cowMintPdaBump] = await anchor.web3.PublicKey.findProgramAddress(
      [cowSeed],
      program.programId);

    const [pigMintPda, pigMintPdaBump] = await anchor.web3.PublicKey.findProgramAddress(
      [pigSeed],
      program.programId);

The airdrop code simplifies to this:

    anchor_spl::token::mint_to(
        CpiContext::new_with_signer(
            ctx.accounts.token_program.to_account_info(),
            anchor_spl::token::MintTo {
                mint: ctx.accounts.mint.to_account_info(),
                to: ctx.accounts.destination.to_account_info(),
                authority: ctx.accounts.mint.to_account_info(),
            },
            &[&[&mint_seed, &[mint_bump]]],
        ),
        amount,
    )?;

Same as before, the most important thing to notice here is that the PDA itself has the authority to sign off transactions.

Putting all together.

There's a demo app deployed here. Both devnet and testnet have the app deployed. You can use the selector on the page to change between the two (if you do, remember to change what network you're pointing in your walled).

You can airdrop some SOL if you don't have any. Furthermore, you can airdrop some farm animals to start trading.

Note: Every 20 seconds, I'm pulling to an off-chain db to display the full list of offers available to all users.

Final thoughts.

This was another fun experiment with Solana. I wanted to keep everything on chain but ended up having an off-chain DB with all offers created to make them available to all users. I'll explore putting all the offers on-chain.

Overall, I'm enjoying my time playing with Solana. I'll keep experimenting and reporting back. Until the next time.

Resources

The animal icons came from this absolutely amazing creator's site: https://kenney.nl/
Background image sourced from: https://www.pixilart.com/art/pixel-farm-bb3c119b728eafd
Learned more about PDA implementations from (https://github.com/cqfd/quidproquo) and (https://github.com/project-serum/anchor/tree/master/tests/escrow)
https://spl.solana.com/

Building a simple on-chain point of sale with Solana, Anchor and React

Fernando Mendez — Fri, 26 Nov 2021 22:19:38 +0000

Note: All the code for this post can be found in this github repo.

A few days ago, I started playing with the Solana blockchain. I was initially interested because it was built on rust (I freaking love rust!). To explore it, I decided to build a basic point of sales (POS) for event tickets.

I initially started reading the code on the Solana Program Library and experimenting but decided to go with Anchor just get started building something more quickly.

I'm not going to describe how to install Solana or Anchor. There is already a fantastic guide written here

The first thing I really love about Anchor is that I was able to start with a test-driven development approach. I started with the first test:

 describe("ticketing-system", () => {
  const anchor = require("@project-serum/anchor");
  const assert = require("assert");

  const { SystemProgram } = anchor.web3;
  // Configure the client to use the local cluster.
  const provider = anchor.Provider.env();
  anchor.setProvider(provider);
  const program = anchor.workspace.TicketingSystem;
  const _ticketingSystem = anchor.web3.Keypair.generate();
  const tickets = [1111, 2222, 3333];

  it("Is initializes the ticketing system", async () => {
    const ticketingSystem = _ticketingSystem;
    await program.rpc.initialize(tickets, {
      accounts: {
        ticketingSystem: ticketingSystem.publicKey,
        user: provider.wallet.publicKey,
        systemProgram: SystemProgram.programId,
      },
      signers: [ticketingSystem],
    });

    const account = await program.account.ticketingSystem.fetch(
      ticketingSystem.publicKey
    );

    assert.ok(account.tickets.length === 3);
    assert.ok(
      account.tickets[0].owner.toBase58() ==
      ticketingSystem.publicKey.toBase58()
    );
  });
});

With this, I'm testing the ability to create 3 tickets, store it on-chain and ensure that all of them are owned by the program account.

To make the test pass, we have to work on the program account (e.g., lib.rs). First, let's create the structs that represent both our Ticket and the TicketingSystem

#[account]
#[derive(Default)]
pub struct TicketingSystem {
    pub tickets: [Ticket; 3],
}

#[derive(AnchorSerialize, AnchorDeserialize, Default, Clone, Copy)]
pub struct Ticket {
    pub owner: Pubkey,
    pub id: u32,
    pub available: bool,
    pub idx: u32,
}

The #[account] on the TicketingSystem automatically prepend the first 8 bytes of the SHA256 of the account’s Rust ident (e.g., what's inside the declare_id). This is a security check that ensures that a malicious actor could not just inject a different type and pretend to be that program account.

We are creating an array of Ticket, so we have to make it serializable. The other thing to note is that I'm specifying the owner to be of type Pubkey. The idea is that upon creation, the ticket will be initially owned by the program and when I make a purchase the ownership will be transferred.

The remaining structures:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user)]
    pub ticketing_system: Account<'info, TicketingSystem>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct PurchaseTicket<'info> {
    #[account(mut)]
    pub ticketing_system: Account<'info, TicketingSystem>,
    pub user: Signer<'info>,
}

The #[derive(Accounts)] implements an Accounts deserializer. This applies any constraints specified by the #[account(...)] attributes. For instance, on the Initialize struct we have had the payer = user constrains specifying who's paying for the initialization cost (e.g., when the program is deploying).

The following code handles the actual initialization:

    pub fn initialize(ctx: Context<Initialize>, tickets: Vec<u32>) -> ProgramResult {
        let ticketingSystem = &mut ctx.accounts.ticketing_system;
        let owner = ticketingSystem.to_account_info().key;

        for (idx, ticket) in tickets.iter().enumerate() {
            ticketingSystem.tickets[idx] = Ticket {
                owner: *owner,
                id: *ticket,
                available: true,
                idx: idx as u32,
            };
        }
        Ok(())
    }

After some fiddling and debugging, I finally get a passing test with anchor test:

  ticketing-system
    ✔ Is initializes the ticketing system (422ms)


  1 passing (426ms)

✨  Done in 8.37s.

Now that I have a list of on-chain Tickets I can retrieve, I want to see them. I decide to create a React app for this. Anchor already created an /app folder, let's use it.

The overall setup is very much like the one here, with the difference that I'm using Typescript.

The next React code will be shown without the imports. You can find the full code here:

The App.tsx contains code to detect if we're connected to a wallet or not:

...
function App() {
  const wallet = useWallet();

  if (!wallet.connected) {
    return (
      <div className="main-container p-4">
        <div className="flex flex-col lg:w-1/4 sm:w-full md:w-1/2">
          <WalletMultiButton />
        </div>

      </div>
    );
  } else {
    return (
      <div className="main-container">
        <div className="border-b-4 border-brand-border self-stretch">
          <h1 className="font-bold text-4xl text-center p-4 text-brand-border">Ticket Sales</h1>
        </div>
        <Tickets />
      </div>
    );
  }
}

export default App;

I created a few components for Ticket and Tickets. I also used tailwindcss to style them.

This is what Tickets look like:

function Tickets() {
  const wallet = useWallet();

  const [tickets, setTickets] = useState<TicketInfo[]>([]);
  const initializeTicketingSystem = async () => {
    const provider = await getProvider((wallet as any) as NodeWallet);
    const program = new Program((idl as any) as Idl, programID, provider);

    try {
      await program.rpc.initialize(generateTickets(3), {
        accounts: {
          ticketingSystem: ticketingSystem.publicKey,
          user: provider.wallet.publicKey,
          systemProgram: SystemProgram.programId,
        },
        signers: [ticketingSystem],
      });
      const account = await program.account.ticketingSystem.fetch(
        ticketingSystem.publicKey
      );
      setTickets(account.tickets);
    } catch (err) {
      console.log("Transaction error: ", err);
    }
  };

  return (
    <div>
      {tickets.length === 0 && (
        <button className="bg-brand-btn rounded-xl font-bold text-xl m-4 p-2 hover:bg-brand-btn-active" onClick={initializeTicketingSystem}>
          Generate Tickets
        </button>
      )}
      {tickets.map((ticket) => (
        <Ticket
          key={ticket.id}
          ticket={ticket}
          ticketingSystem={ticketingSystem}
          setTickets={setTickets}
        />
      ))}
    </div>
  );
}

export default Tickets;

Here, we provide a Generate Tickets button that will initialize the tickets on-chain. These RPC calls could be moved to an API file, but I'll keep there since it is the only place that needs it. The code for the Ticket is similar in structure. Here will call the purchase RPC call:

  ....
  const purchase = async (ticket: TicketInfo) => {
    const provider = await getProvider((wallet as any) as NodeWallet);
    const program = new Program((idl as any) as Idl, programID, provider);
    try {
      await program.rpc.purchase(ticket.id, ticket.idx, {
        accounts: {
          ticketingSystem: ticketingSystem.publicKey,
          user: provider.wallet.publicKey,
        },
      });

      const account = await program.account.ticketingSystem.fetch(
        ticketingSystem.publicKey
      );
      setTickets(account.tickets);
    } catch (err) {
      console.log("Transaction error: ", err);
    }
  };
  ....

All the styled components look like this:

A gif showing it in action:

You can try a live version ( pointing to the testnet.api ) here

For fun, I added a QR code that's based on the ticket number and the account that made the purchase.

Overall, this was a fun experiment. Based on my initial experimentation using the Solana SDK directly, there's a lot that Anchor is abstracting away. There's also good practices built into it (e.g., the 8 bytes discriminator for the program's account, lack of order when accessing accounts, etc.). I'll be spending more time with both Anchor and the Solana SDK itself to make sure I understand what's being abstracted away.

Finally, there are a few troubleshooting tips that might help you when using Anchor.

Remember to anchor build and anchor deploy before running anchor test. That ensures that you have the latest bytecode on the runtime. You will encounter a serialization error if you don't.
When you encounter custom errors such as this: "Transaction simulation failed: Error processing Instruction 0: custom program error: 0x66". Convert the number from hex -> integer, if the number is >=300 it's an error from your program, look into the errors section of the idl that gets generated when building your anchor project. If it is < 300, then search the matching error number here
When you get this type of error: "error: Error: 163: Failed to deserialize the account". Very often it's because you haven't allocated enough space (anchor tried to write the account back out to storage and failed). This is solved by allocating more space during the initialization.

For example, had to bump this to 64 to solve the issue. Was initially at 8:

  ...
  #[account(init, payer = user, space = 64 + 64)]
  pub ticketing_system: Account<'info, TicketingSystem>,
  ...

Alternatively (and the recommended option from what I've gathered) is to leave the space out for Anchor to calculate it for you. The exception is if you're dealing with a complex of Custom types that Anchor can't calculate for some reason.

If you for whatever reason you need to generate a new program ID (e.g., a fail deployment to devent or testdeve made that account address in use and is not upgradeable). You can simply delete the /deploy folder under target (e.g /root-of-your-anchor-project/target/deploy) and run anchor build again. That will regenerate the /deploy folder. After that, you just need to run this from your root project directory solana address -k target/deploy/name-of-your-file-keypair.json. You can take that output and upgrade both the declare_id() in your lib.rs and Anchor.toml with the new program ID. Finally, you have to run anchor build again to rebuild with the new program ID.

I still have a lot to explore, I find both Anchor and the current Solana ecosystem very exciting. Will continue to post my progress. Until the next time.