Forem: Philip Perry

Getting In-App Purchases working for an Android App created with React Expo

Philip Perry — Sat, 09 Aug 2025 00:17:02 +0000

When I set out to add in-app purchases (IAP) to Interactive Audio Stories, I imagined this would be very simple as I’m not the first to do it. But the reality was a marathon of backend and frontend changes, endless debugging, and a lot of learning. Here’s how it unfolded.

Backstory

While users can read stories for free, all these AI credits cost me money so I decided to add a paid feature which allows users to generate their own interactive stories. They can login with a Google user and we keep track of how many stories they can create with a count field in the Firebase users collection. So initially count is set to zero, but when they make an in-app purchase it adds 1 to the existing value which will allow them to create one story (or more if they made multiple purchases before creating a story).

Choosing a Payment Library

Initially, I went with RevenueCat, but I found their implementation an overkill for a simple app like mine and more geared towards subscriptions. I also couldn’t get it to work as intended. Then I tried Adapty. What I didn’t understand at first it that Adapty does not support consumables. A consumable is a purchase that unlocks content that can be "consumed", e.g. for my app that would be "consuming" the generation of one story. So making an in-app purchase doesn't unlock the feature forever, but just for one time.

Finally, I came across https://github.com/hyochan/expo-iap which does exactly what I need. One needs to implement validation in the backend, but the app needs to make a call to the backend anyways in order to increment the count field.

Backend

Validating Receipts with Google Play

A key part of secure IAP is verifying the purchase server-side. This Go snippet shows how to call the Google Play API to validate a purchase token:

url := fmt.Sprintf("https://androidpublisher.googleapis.com/androidpublisher/v3/applications/%s/purchases/products/%s/tokens/%s",
    req.PackageName, req.ProductId, req.ProductToken)
reqGoogle, err := http.NewRequest("GET", url, nil)
reqGoogle.Header.Set("Authorization", "Bearer "+accessToken)
resp, err := client.Do(reqGoogle)

Annoyingly, the first draft which I generated with LLM passed in the access token as a query string instead of setting an authorization header and it took me a while to realise that. I don't know how vibe coders create these type of apps...

Getting the access token

In order to make the above request for verifying the purchase, one first needs to make a request to get the access token. To access the Google Play API, one needs to load service account credentials which is a json file that one needs to create and download from Google cloud.

func getGoogleAccessToken() (string, error) {
    ctx := context.Background()
    credPath := os.Getenv("GOOGLE_APPLICATION_CREDENTIALS")
    if credPath == "" {
        return "", fmt.Errorf("GOOGLE_APPLICATION_CREDENTIALS env var not set")
    }
    log.Printf("[Receipt] Loading Google credentials from: %s", credPath)
    jsonData := readFileOrPanic(credPath)
    // Log client_id from the service account JSON
    var credMeta struct {
        ClientID string `json:"client_id"`
    }
    if err := json.Unmarshal(jsonData, &credMeta); err == nil {
        log.Printf("[Receipt] Service Account client_id: %s", credMeta.ClientID)
    } else {
        log.Printf("[Receipt] Could not parse client_id from service account JSON: %v", err)
    }
    creds, err := google.CredentialsFromJSON(ctx, jsonData, "https://www.googleapis.com/auth/androidpublisher")
    if err != nil {
        return "", err
    }
    log.Printf("[Receipt] Successfully loaded Google credentials")

    token, err := creds.TokenSource.Token()
    if err != nil {
        return "", err
    }
    return token.AccessToken, nil
}

Frontend

This is how we handle the button click handlePurchase. One thing worth noting is that for Android we pass in skus while for iOS it's sku. I decided to pass in both, even though we don't support iOS at the moment...

const handlePurchase = async () => {
    let productId = 'my_product';

    try {

      await requestPurchase({
        request: {
          sku: productId,
          skus: [productId],
        },
        type: 'inapp',
      });
    } catch (error) {
      console.log("products loaded", products),
        console.error('The purchase failed:', error);
    }
  }

This is the part of the frontend code that makes a request to the backend verification:

useEffect(() => {
    if (currentPurchase) {
      const completePurchase = async () => {
        console.log('Current purchase:', currentPurchase);
        try {
          // Parse the purchase receipt
          let verifiedPurchase = JSON.parse(currentPurchase?.transactionReceipt);
          const packageName = "com.artisanphil.myaudiostory";
          const productToken = verifiedPurchase.purchaseToken;
          const productId = verifiedPurchase.productId;

          // Call backend for receipt validation
          const res = await fetch(`${API_BASE}/receipt/validate`, {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
              packageName,
              productToken,
              productId,
              userId: userInfo.id,
            }),
          });
          const data = await res.json();
          if (!res.ok || !data.valid) {
            Alert.alert('Purchase Invalid', 'Your purchase could not be validated. Please contact support.');
            return;
          }

          // Finish the transaction
          await finishTransaction({
            purchase: currentPurchase,
            isConsumable: true, // Set true for consumable products
          });

          // Grant the purchase to user
          console.log('Purchase validated and completed successfully!');
          await refreshUserData(userInfo, "storage", setUserInfo);
        } catch (error) {
          console.error('Failed to complete purchase:', error);
        }
      };

      completePurchase();
    }
  }, [currentPurchase]);

Note that we pass in isConsumable: true when finishing the transaction.

There is a bit more to it, but best to consult the official documentation at https://expo-iap.hyo.dev/docs/api/use-iap/

Conclusion

Programming isn’t always smooth sailing, even for seasoned developers, and that’s part of what makes it interesting. Since I couldn’t find any existing article for this particular use case, I wanted to share my own experience in the hope it saves you a few bumps along the way.

Coding is Messy – Or Why Developers Are Still Indispensable

Philip Perry — Sat, 19 Jul 2025 06:34:50 +0000

With all the talk of AI replacing developers, it is easily forgotten that developing software is essentially still a human activity. AI certainly can help speed up the process, but there are so many complexities involved that require human intervention. Talking with the stakeholders is certainly something that a vibe coder can do, but I’m referring to the code itself. While AI might be able to quickly scaffold an initial program, when it comes to making changes, human developers still possess the critical understanding of the requirements, architectural implications, and long-term maintainability to effectively adapt and evolve the codebase.

One skill needed by software developers that is often overlooked is perseverance. This is especially true when it comes to working with libraries or external systems. For example, I’ve recently been trying to get billing to work for an Android app (a small side-project). While the libraries keep getting updated, I found that the maintainers oftentimes forget updating the documentation. Recently I found that the code that I needed to use was on the migration page, but nobody had updated the documentation page itself. Sometimes AI can be good at returning the actual implementation one is looking for, but more often than not, it will return a hallucinated function name. In these cases, vibe coding will lead nowhere…

Another area where human software developers are needed is debugging an issue. In order to be able to reproduce an issue, one needs to painstakingly step through the code, view the logs and examine data at each step. Again, an AI agent can help with these steps, but it requires human guidance as there can be many points of failures, some which might be outside of the codebase itself.

From the nuanced conversations with stakeholders to the messy reality of debugging a tricky issue or wrestling with poorly documented legacy code, AI simply isn't equipped to handle the full spectrum of challenges.

Versioning in Go Huma

Philip Perry — Fri, 10 Jan 2025 17:09:42 +0000

We want to have a separate documentation for each version in Go Huma, e.g. /v1/docs, /v2/docs, etc.

This can be done by setting the docs path like this:

config.DocsPath = "/{version}/docs"

We can use middleware to get the version from the path in the request and load the description used in the docs depending on the version:

config := huma.DefaultConfig("API V"+versionNumberString, versionNumberString+".0.0")
                overviewFilePath := filepath.Join("/app/docs", fmt.Sprintf("v%s", versionNumberString), "overview.md")
                overview, err := ioutil.ReadFile(overviewFilePath)
                if err != nil {
                    log.Fatalf("Error reading file: %v", err)
                }

                config.Info.Description = string(overview)

And we can import all routes that we want to display in the docs based on the version. This will also load them so that they can be used as actual endpoints.

This is the complete code for routing:

router := chi.NewMux()
    router.Use(func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            urlPathParts := strings.Split(r.URL.Path, "/")
            versions := []string{"v1", "v2", "v3"}
            if helpers.Contains(versions, urlPathParts[1]) {
                versionPath := urlPathParts[1]
                if versionPath == "" {
                    http.Error(w, "version does not exist", http.StatusInternalServerError)
                }
                versionNumberString := strings.TrimPrefix(versionPath, "v")
                versionNumber, _ := strconv.Atoi(versionNumberString)
                config := huma.DefaultConfig("API V"+versionNumberString, versionNumberString+".0.0")
                overviewFilePath := fmt.Sprintf("docs/v%s/overview.md", versionNumberString)
                overview, err := ioutil.ReadFile(overviewFilePath)
                if err != nil {
                    log.Fatalf("Error reading file: %v", err)
                }

                config.Info.Description = string(overview)
                api := humachi.New(router, config)

                switch versionNumber {
                case 1:
                    api = v1handlers.AddV1Middleware(api)
                    v1handlers.AddV1Routes(api)
                case 2:
                    api = v2handlers.AddV2Middleware(api)
                    v2handlers.AddV2Routes(api)
                default:
                    api = v3handlers.AddV3Middleware(api)
                    router = v3handlers.AddV3ErrorResponses(router)
                    v3handlers.AddV3Routes(api)
                }
            }

            next.ServeHTTP(w, r)
        })
    })

    config := huma.DefaultConfig("API V3", "3.0.0")
    config.DocsPath = "/{version}/docs"

    humachi.New(router, config)

Adding filter query parameters in Go Huma

Philip Perry — Fri, 29 Nov 2024 19:25:33 +0000

From what I have been able to find out, Huma unfortunately doesn't support array query filters like this: filters[]=filter1&filters[]=filter2 (neither leaving the brackets out, e.g. filter=filter1&filter=filter2). I came across this Github issue that gives an example of separating the filters by comma https://github.com/danielgtaylor/huma/issues/325, so that's what we ended up doing: filters=postcode:eq:RM7%28EX,created:gt:2024-01-01

I found a way to use repeated query parameters, so that I don't need to separate them by comma after all. It can be done using the explode option in the struct tag. So below you will find the updated implementation (I deleted the old one).

The query string will look like this: filters=postcode:eq:RM7%28EX&filters=created:gt:2024-01-01

Documenting filters

Unlike the body parameters, which one can simply specify as structs and then they get both validated and generated in the documentation, the documentation and validation for filters has to be done separately.

The documentation can simply be added under the description attribute of the Huma.Param object (under Operation):

Parameters: []*huma.Param{{
            Name: "filters",
            In:   "query",
            Description: "Filter properties by various fields.\n\n" +
                "Format: field:operator:value\n\n" +
                "Supported fields:\n" +
                "- postcode (operator: eq)\n" +
                "- created (operators: gt, lt, gte, lte)\n",
            Schema: &huma.Schema{
                Type: "string",
                Items: &huma.Schema{
                    Type:    "string",
                    Pattern: "^[a-zA-Z_]+:(eq|neq|gt|lt|gte|lte):[a-zA-Z0-9-:.]+$",
                },
                Examples: []any{
                    "postcode:eq:RM7 8EX",
                    "created:gt:2024-01-01",
                },
            },
            Required: false,
        }},

We can now define our PropertyFilterParams struct for validation:

type FilterParam struct {
    Field    string
    Operator string
    Value    interface{}
}

type PortfolioFilterParams struct {
    Items []FilterParam
}

func (input *PortfolioQueryParams) Resolve(ctx huma.Context) []error {
    equalityFields := []string{"property_id", "external_id", "address", "action_text"}
    greaterSmallerFields := []string{"households", "occupants"}
    dateFields := []string{}

    var errs []error
    for idx, f := range input.Filters {
        _, err := parseAndValidateFilterItem(f, equalityFields, greaterSmallerFields, dateFields)
        if err != nil {
            errs = append(errs, &huma.ErrorDetail{
                Location: fmt.Sprintf("query.filters[%d]", idx),
                Message:  err.Error(),
                Value:    f,
            })
        }
    }

    return errs

}

func (s *PortfolioFilterParams) Schema(registry huma.Registry) *huma.Schema {
    return &huma.Schema{
        Type: huma.TypeString,
    }
}

func parseAndValidateFilterItem(item string, equalityFields []string, greaterSmallerFields []string, dateFields []string) (FilterParam, error) {
    parts := strings.SplitN(item, ":", 3)

    field := parts[0]
    operator := parts[1]
    value := parts[2]

    if contains(equalityFields, field) {
        if operator != "eq" && operator != "neq" {
            return FilterParam{}, fmt.Errorf("Unsupported operator %s for field %s. Only 'eq' and 'neq' are supported.", operator, field)
        }
    } else if contains(greaterSmallerFields, field) {
        if !validation.IsValidCompareGreaterSmallerOperator(operator) {
            return FilterParam{}, fmt.Errorf("Unsupported operator %s for field %s. Supported operators: eq, neq, gt, lt, gte, lte.", operator, field)
        }
    } else if contains(dateFields, field) {
        if !validation.IsValidCompareGreaterSmallerOperator(operator) {
            return FilterParam{}, fmt.Errorf("Unsupported operator %s for field %s. Supported operators: eq, neq, gt, lt, gte, lte.", operator, field)
        }
        if !validation.IsValidDate(value) {
            return FilterParam{}, fmt.Errorf("Invalid date format: %s. Expected: YYYY-MM-DD", value)
        }
    } else {
        return FilterParam{}, fmt.Errorf("Unsupported filter field: %s", field)
    }

    return FilterParam{Field: field, Operator: operator, Value: value}, nil
}

And this is how the PortfolioQueryParams struct looks like:

type PortfolioQueryParams struct {
    PaginationParams
    Filters []string `query:"filters,explode" doc:"Filter portfolio by various fields"`
}

This is how adding PortfolioQueryParams to the route looks like (note that the Operation code itself, including the filter description, is under getAllPropertyOperation - I didn't paste the complete code for that, but hopefully you get the gist of it). If validation fails, it will throw a 422 response. I also added how we can loop through the filter values that got passed:

huma.Register(api, getAllPropertyOperation(schema, "get-properties", "/properties", []string{"Properties"}),
        func(ctx context.Context, input *struct {
            models.Headers
            models.PortfolioQueryParams
        }) (*models.MultiplePropertyOutput, error) {

            for _, filter := range input.Filters{
                fmt.Println(filter)
            }

            return mockMultiplePropertyResponse(), err
        })
}

I hope this helps someone. Let me know in the comments, if you found a better solution.

Why we chose the Go Huma framework to develop our API endpoints

Philip Perry — Thu, 07 Nov 2024 20:58:58 +0000

At the company where I work as a software engineer, we are in the process of developing an API that communicates with our micro services and will be used by our own products as well as being an API that our clients can use. Our overall deciding factor for choosing Golang for this was speed. Apart from fast execution time, Go also offers low memory consumption and efficient concurrency.

When it came to the first step of specifying the endpoints, we were looking for a solution to do so in code as we wanted to avoid a discrepancy between code and documentation. Our CEO had used the same approach using Python FastApi, so we googled for a FastApi solution for Go and came across Huma. With Huma one can automatically generate OpenAPI documentation from code and it generates a nice-looking documentation using stoplight elements. It generates the JSON schema from Go types and uses static typing for path/query/header params, bodies, response headers, etc. It does input model validation & error handling automatically based on the json schema.

We’ve found the framework fairly flexible and it allows for instance to use one own's router, although we just stuck with Chi which it uses as the default one. There are some downsides, for instance it doesn’t seem to support array query parameters, so we’re separating filters by comma. But that hasn’t been a deal breaker.

I plan to write more about my experience and learnings with Go Huma in future posts, but so far I have found it fit for purpose.

Follow me on my journey learning Go

Philip Perry — Tue, 05 Nov 2024 21:29:18 +0000

I'm developing a little game using Go in the backend and React with TypeScript for the frontend. In my day job I mostly work with PHP using the Laravel framework, so Go is a new programming language for me and I find the best way to learn is by doing. So follow me on my journey on building this project. I'm already half way done, but I'll share any future PRs with you.

The game is called Suspect Recall. You can view what I have so far here: https://www.suspectrecall.com First you see a suspect for a few seconds and then you have to remember which attributes that suspect had. I'll be improving the design a bit later, although that's not the focus of this project.

Next on the todos is fetching a random suspect. I opened a PR for that part of the code: https://github.com/artisanphil/suspect_recall/pull/4 Code reviews are welcome! I also plan to save the answers so that I can get an idea of how many people try out the website and how many mistakes they make.

An overview of the code structure

Originally I used to have two folders, backend and frontend, but I found it actually works best to have the backend code in the root and the frontend folder inside the backend folder.
We don't need to deploy the frontend code, just the code that gets created from the build. Find out in the Readme file how to run the code for local development.

If you just downloaded the project, you will need to run npm install in the frontend folder to pull the dependencies into the folder 'node_modules'.
Create a .env file in the frontend folder and add REACT_APP_MODE=development. This is so that when running frontend code with live reload, it will call the api endpoints which run on another port. Then run npm run start.

We can now go to localhost:3000 and view the frontend. As you will see, the api endpoints won't work, so let's go to the root folder and run go run .. Note that we needed to allow cross-domain requests when running locally, as it's running on another port (port 8080, frontend is on 3000).

c := cors.New(cors.Options{
        AllowedOrigins:   []string{"http://localhost:3000"},
        AllowedHeaders:   []string{"Origin", "Content-Type", "Accept"},
        AllowCredentials: true,
    })

When running on production, it will all run on the same port as we just run the backend code after having built the frontend code with npm run build which creates the static files. BTW, I deployed the code to Google App Engine.

Please review this PR where I add a new api for dynamically fetching a suspect (which is currently hard-coded) and calling that endpoint in the frontend: https://github.com/artisanphil/suspect_recall/pull/4

Thanks in advance for any comments on how the code can be improved and I'll do my best to answer any questions that you might have.

In order to view future progress, please watch this repository: https://github.com/artisanphil/suspect_recall

Fitting a square peg into a round hole - a painful lesson

Philip Perry — Tue, 20 Feb 2024 08:22:05 +0000

Software development encompasses far more than mere syntax mastery. The real challenges lie in communication and strategic planning. Let me share a story that illustrates this point vividly.

We recently encountered a requirement that lacked a straightforward solution. Rather than immediately pushing back, we embarked on a journey to meet it head-on.

The requirement was seemingly simple: retrieve a child item of a parent where no direct 1-to-1 relationship existed. Initially, our solution involved returning the latest created child item. However, the first round of QA exposed that the logic wasn't that simple. We delved deeper, crafting more intricate solutions, only to face scrutiny during the subsequent QA round.

The new QA reviewer rightly questioned the convoluted logic, foreseeing its potential pitfalls and the inevitable maintenance challenges it posed. After consultation with the product team, we collectively agreed that the necessity of returning this child item was questionable.

If we had understood this earlier, we could have saved a lot of time. At this stage the logic was already used in several places, so it will take a few days to rip it out.

Reflecting on this experience, I realise several key lessons. Firstly, I must dedicate more time to understanding data sources thoroughly. Even seemingly straightforward scenarios can conceal hidden complexities, especially in cases lacking direct relationships.

Secondly, early engagement with the product team is crucial when complexities arise. Transparency about potential challenges facilitates collaborative exploration of alternative solutions. While our initial logic might have sufficed for most cases, it wasn't a sustainable solution.

Despite holding the title of senior engineer, this experience felt like an initiation rite, revealing the true breadth of responsibilities inherent in my role. Moving forward, I commit to thorough scenario analysis, even if it delays project initiation. By preemptively addressing potential issues, we can develop simpler yet robust solutions that deliver tangible value without succumbing to over-engineering.

Integrating SSO with Laravel Auth Provider

Philip Perry — Mon, 29 Jan 2024 19:30:09 +0000

At my company we have our own SSO server (based on Laravel passport) and we use our sdk (Laravel package) that provides the middleware and other functionality to communicate with the SSO server and we add to all our microservices.

We decided to add the functionality of the SDK so that our SSO user data gets passed into the Auth provider. The Auth facade allows one to do things like fetching the logged-in user with Auth::user(). Thankfully Laravel allows one to extend the user provider

One of the methods that can be overwritten is retrieveById. Our code to fill the Auth user looks something like this (simplified):

<?php
namespace Company\SSO\Auth\UserProviders;

use Illuminate\Contracts\Auth\Authenticatable
use Illuminate\Contracts\Auth\UserProvider;

class SSOUserProvider implements UserProvider
{
  public function retrieveById($identifier): ?Authenticatable
  {
    $user = SSO::webUser(); //this fetches the web user from  our SSO server

   if(!$user) { 
    return null;
   }

  /**
  * LaravelUser is a class that we created that implements the
  * Authenticatable contract 
  */
  return new LaravelUser(
    $user->id,
    $user->name,
    $user->email,
    $user->emailVerifiedAt,
    $user->isAdmin,
    $user->createdAt,
    $user->updatedAt,
    $user->activeGroup 
  );
 }
}

The custom user provider needs to be added to the auth.php config and resolved in the boot method of the ServiceProvider class. You can read about this here: Adding custom user providers

We actually went a step further and also added custom guards by using Auth::extend() in the boot method of the ServiceProvider. For that we pretty much followed what is described here: Adding custom guards

Scribe not extracting docblocks

Philip Perry — Sat, 30 Sep 2023 18:31:36 +0000

Scribe can use PHP docblocks for generating documentation. On a newer Laravel project this no longer worked and initially I thought it might be related to a newer version of Scribe as we didn't have that version in other projects where we were using an older version of Scribe. But a downgrade was causing conflicts, so I couldn't evaluate this. However, it seemed odd that apart from one Github issue, nobody was complaining. So that pointed towards a configuration issue, but I couldn't see anything different inside the scribe config file.

Finally, after debugging the GetFromDocBlocks strategy class, my colleague came across the fact that the getDocComment method is a PHP reflection method. This led to a Google search where we found this Stackoverflow post: https://stackoverflow.com/questions/42087433/reflectionmethod-getdoccomment-doesnt-seem-to-work-on-php-5-5

It turns out, that for this project we were using OpCache, but had the configuration opcache.save_comments set to false. After changing the setting opcache.save_comments=1 and rebuilding the Docker container, Scribe worked as expected!

This one was slightly tricky to debug and credit goes to my colleague who patiently debugged the issue with me.

Evaluating Nuxt as a Laravel Fullstack developer

Philip Perry — Sun, 17 Sep 2023 16:36:30 +0000

As a full-stack developer, choosing the right technology stack for your web projects is crucial to achieving efficiency, maintainability, and performance. Two popular options for integrating Laravel on the backend with a JavaScript framework on the frontend are Nuxt and Inertia. In this article, we'll explore the advantages of Nuxt and why, after careful consideration, I came to the conclusion that when using Laravel, Inertia is often a better choice for seamless integration.

The Advantages of Nuxt

Before diving into the reasons behind choosing Inertia, let's first highlight some of the advantages of Nuxt, which is a powerful Vue.js framework designed to simplify frontend development:

Server-Side Rendering (SSR): Nuxt offers built-in support for SSR, which can greatly improve SEO and page load times by rendering pages on the server before sending them to the client. This is beneficial for applications that require strong SEO and initial rendering performance.

Code Splitting: Nuxt automatically splits your JavaScript code into smaller chunks, optimizing the initial load times of your application. This can lead to a better user experience, especially on slower network connections.

Routing Made Easy: Nuxt provides a straightforward and flexible routing system that allows developers to define routes in a declarative manner. This simplifies the creation of complex routing structures.

Vue Ecosystem Integration: Nuxt seamlessly integrates with the Vue.js ecosystem, allowing you to use Vue components and libraries without extra configuration.

Out-of-the-Box Features: Nuxt comes with various pre-configured features like Vuex for state management, async data fetching, and automatic transitions between pages.

Now, let's discuss why, despite these advantages, Inertia might be a more suitable choice for Laravel developers in certain scenarios.

Inertia: My preferred choice for integrating Laravel and Vue.js

Simplified Backend Logic: Inertia is designed to keep most of the logic on the backend side (using Laravel) while allowing for dynamic frontend updates. This is particularly advantageous when you have a Laravel-based API already in place, as it reduces the need for a separate frontend codebase and makes it easier to maintain the application.

Familiar Blade Templates: With Inertia, you can continue to use Laravel's Blade templates on the frontend, reducing the learning curve for developers who are already familiar with Laravel. This means you can leverage the power of Laravel's templating engine without major changes.

Seamless Data Fetching: Inertia provides a straightforward way to fetch and display data on the frontend without the need for complex API requests. It sends JSON responses from the backend directly to the Vue components, making data retrieval and rendering efficient.

Server Setup Simplified: Unlike Nuxt, which introduces complexity in setting up a separate server for SSR, Inertia leverages the existing Laravel infrastructure, reducing the need for additional server configuration and maintenance.

Nitro Server

While looking into Nuxt, I learned about Nitro. Nitro is an open-source TypeScript framework designed to build ultra-fast web servers. If you need to build a performant application, comparing Nitro's performance with Laravel (using Octane) could be a valuable exercise, especially if speed and efficiency are critical for your project. I thought this is worth mentioning as one possible reason to consider using Nuxt over Laravel.

Conclusion

In conclusion, the choice between Nuxt and Inertia depends on your specific project requirements and team dynamics. In a team where frontend and backend developers work on separate codebases, using Nuxt could make more sense. In addition, Nuxt offers powerful SSR capabilities and a rich Vue.js ecosystem integration, but it can introduce additional complexity, particularly in cases where you want to maintain a single codebase for both frontend and backend.

Inertia simplifies the integration of Laravel and Vue.js, making it a great choice for Laravel developers who want to leverage their existing backend expertise.

Please leave a comment and let me know if you agree and disagree and what your experience is.

Using Laravel Policy with middleware to protect routes

Philip Perry — Sat, 26 Aug 2023 11:11:32 +0000

So my goal was to only allow the logged in user to view or make changes to data that belongs to him. How do I know which data belongs to him? In the model LanguagePack I save his user id. Any other data like the WordList model has a relation to language pack.

A user accesses the data via an url like this:

/languagepack/wordlist/1

So I don't want him to be able to change the id to 2 if that language pack wasn't created by him and then see and edit that data.

To do this I created a policy class that looks like this:

<?php

namespace App\Policies;

use App\Models\LanguagePack;
use App\Models\User;
use Illuminate\Auth\Access\HandlesAuthorization;

class LanguagePackPolicy
{
    use HandlesAuthorization;

    public function view(User $user, LanguagePack $languagePack)
    {
        return $user->id === $languagePack->userid;
    }    

    public function update(User $user, LanguagePack $languagePack)
    {
        return $user->id === $languagePack->userid;
    }    

    public function delete(User $user, LanguagePack $languagePack)
    {
        return $user->id === $languagePack->user_id;
    }    
}

Then I created a middleware for getting the language pack model from the route and running the policy check by authorizing actions. If the action is allowed, it will continue the request, otherwise it throws a 403 error and aborts the request.

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class AuthorizeLanguagePack
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure(\Illuminate\Http\Request): (\Illuminate\Http\Response|\Illuminate\Http\RedirectResponse)  $next
     * @return \Illuminate\Http\Response|\Illuminate\Http\RedirectResponse
     */
    public function handle(Request $request, Closure $next)
    {
        $languagePack = $request->route('languagePack'); 

        if ($languagePack) {
            $user = $request->user();

            if ($user->can('view', $languagePack) ||
                $user->can('update', $languagePack) ||
                $user->can('delete', $languagePack)) {
                return $next($request);
            }

            abort(403, 'Unauthorized');
        }       

        return $next($request);
    }
}

The middleware has to be registered in the file src/app/Http/Kernel.php like this:

protected $routeMiddleware = [
     //add to the list of route middlewares
     'authorize.languagepack' => \App\Http\Middleware\AuthorizeLanguagePack::class,
    ];

And finally we add the middleware key authorize.languagepack to the routes in web.php:

Route::middleware(['auth', 'authorize.languagepack'])->group(function () {
 Route::get('/dashboard', [DashboardController::class, 'index'])->name('home');    
    Route::get('languagepack/create', [LanguageInfoController::class, 'create']);
    Route::get('languagepack/edit/{languagePack}', [LanguageInfoController::class, 'edit']);
    Route::get('languagepack/wordlist/{languagePack}', [WordlistController::class, 'edit']);
})

There are probably other ways to achieve the same result. Let me know in the comments if you know of a better way...

Why use git worktree?

Philip Perry — Mon, 21 Aug 2023 19:39:12 +0000

git worktree is a command that I came across the first time today while browsing the git documentation. The example section explains a possible use case pretty well:

From https://git-scm.com/docs/git-worktree:

You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use git-stash to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it. Instead, you create a temporary linked worktree to make the emergency fix, remove it when done, and then resume your earlier refactoring session.

$ git worktree add -b emergency-fix ../temp master
$ pushd ../temp
# ... hack hack hack ...
$ git commit -a -m 'emergency fix for boss'
$ popd
$ git worktree remove ../temp

While I'm not sure if the above scenario is something where I would use it, I can see it as a useful feature for experimenting. For example, I might have a half working solution that I could stash, but if I want to switch between one approach and another idea that I have, then I think using work trees would work much better (saves me from having to keep committing code that I'm not sure will work). What do you think? Have you used git worktree?