Building an AI Resume Analyzer with Serverless Technology#

The Traditional Backend Problem#

Before discovering Puter.js, building an app like this meant; setting up authentication, database setup, file storage, AI integration, backend API. That’s easily 40-60 hours of work before writing any frontend code.

The Puter.js Revolution#

With Puter.js, I added ONE script tag:

1
<script src="https://js.puter.com/v2/"></script>

And suddenly I had access to:

• OAuth authentication (no configuration)
• Cloud file storage (unlimited)
• Key-value database (instant)
• Multiple AI models (free)
• All without a single line of backend code

This wasn’t just convenient—it fundamentally changed my development approach.

The Challenge#

While Puter.js works perfectly with vanilla JavaScript, integrating it into React required careful consideration. Questions arose:

• How do I ensure Puter loads before my components try to use it?
• How do I share authentication state across components?
• How do I avoid prop drilling for Puter functions?
• How do I handle loading states elegantly?

The Solution: Zustand + Puter#

I created a custom wrapper using Zustand that became the heart of the application:

1
export const usePuterStore = create<PuterStore>((set, get) => ({
2
  isLoading: true,
3
  auth: { isAuthenticated: false, user: null },
4

5
  init: async () => {
6
    const puter = getPuter();
7
    if (puter) {
8
      await get().checkAuthStatus();
9
      set({ isLoading: false });
10
    }
11
  },
12

13
  signIn: async () => {
14
    const puter = getPuter();
15
    await puter.auth.signIn();
16
  },
17

18
  fs: {
19
    upload: async (files) => {
20
      const puter = getPuter();
21
      return await puter.fs.upload(files);
22
    }
23
  }
24
  // ... more functions
25
}));

The Learning Curve#

Creating this wrapper taught me:

When to wrap external libraries: Not every library needs wrapping. But when you need:

• Shared state across components
• Loading state management
• Type safety improvements
• Consistent error handling

A wrapper like this is invaluable.

Zustand vs Redux: Zustand is a simpler alternatives. No actions, no reducers—just functions that update state.

The Challenge#

Displaying PDFs on the web is harder than it sounds. I needed to:

1. Accept PDF uploads
2. Display thumbnails on the homepage
3. Allow full PDF viewing
4. Keep file sizes reasonable

Solution: PDF.js + Canvas API#

I built a custom conversion function:

1
const convertPDFToImage = async (file: File): Promise<File> => {
2
  // Load PDF
3
  const arrayBuffer = await file.arrayBuffer();
4
  const pdf = await pdfjsLib.getDocument(arrayBuffer).promise;
5

6
  // Get first page
7
  const page = await pdf.getPage(1);
8

9
  // Render to canvas
10
  const canvas = document.createElement('canvas');
11
  const context = canvas.getContext('2d');
12

13
  const viewport = page.getViewport({ scale: 2 });
14
  canvas.width = viewport.width;
15
  canvas.height = viewport.height;
16

17
  await page.render({ canvasContext: context, viewport }).promise;
18

19
  // Convert to PNG
20
  return new Promise((resolve) => {
21
    canvas.toBlob((blob) => {
22
      const imageFile = new File([blob], 'resume.png', {
23
        type: 'image/png'
24
      });
25
      resolve(imageFile);
26
    }, 'image/png');
27
  });
28
};

What I Learned:

Canvas API is powerful: Pixel manipulation. Render anything, convert to image, done.

PDF.js handles complexity: Loading multi-page PDFs, different formats, compression; all handled by the library.

Promises can nest: This function uses Promises within Promises. Understanding async flow is crucial.

What’s New?#

React Router v7 introduced a game-changer: route-level data loading.

Before (Manual Loading):

1
function ResumePage() {
2
  const [resume, setResume] = useState(null);
3
  const [loading, setLoading] = useState(true);
4

5
  useEffect(() => {
6
    loadResume().then(setResume).finally(() => setLoading(false));
7
  }, [id]);
8

9
  if (loading) return <Spinner />;
10
  return <ResumeView resume={resume} />;
11
}

After (Router Loading):

1
// Just define the loader
2
export async function loader({ params }) {
3
  return await loadResume(params.id);
4
}
5

6
// Component receives data as props
7
function ResumePage({ data }) {
8
  return <ResumeView resume={data} />;
9
}

Benefits:

1. No loading state boilerplate: Router handles it
2. Parallel data fetching: Multiple loaders run simultaneously
3. Error boundaries: Built-in error handling
4. Type safety: TypeScript knows the data shape

This pattern eliminated about 30% of my state management code.

The Conversion Experience#

This project changed my mind completely. Here’s why:

Caught bugs before runtime:

1
// TypeScript caught this immediately
2
const score = feedback.overalScore; // Typo!
3
// Property 'overalScore' does not exist on type 'Feedback'
4
// Did you mean 'overallScore'?

Self-documenting code:

1
interface Feedback {
2
  overallScore: number;
3
  ats: ATSFeedback;
4
  toneAndStyle: CategoryFeedback;
5
}
6

7
// I know exactly what this function expects and returns
8
function analyzeResume(resume: File): Promise<Feedback>

Refactoring confidence: When I restructured the Feedback interface, TypeScript showed me every place that needed updating. No hunting through files.

Editor intelligence: My IDE knew what properties existed, what functions were available, and what types were expected.

Key Insight: TypeScript is about writing better code and not more code.