DEV Community

Cover image for Devlog-OSS-Finder-02: First Deployment Done
Barbora Klusackova
Barbora Klusackova

Posted on

Devlog-OSS-Finder-02: First Deployment Done

#opensource #aws #devlog #softwaredevelopment

MVP Complete: Open Source Repository Explorer

Date: January 23, 2026

Status: MVP Complete — Now Public

OSS Finder Main Page Screenshot

What I Built

A full-stack web application for discovering open-source repositories on GitHub.

Users can:

  • Search repositories by keyword
  • Filter by programming language
  • View repository stats and metadata

Live: https://open-source-finder-zeta.vercel.app/

GitHub: https://github.com/baradev/oss-repo-finder

Tech Stack

Frontend

  • React 19 + TypeScript
  • Vite
  • Tailwind CSS

Backend

  • Fastify + TypeScript
  • GitHub API integration
  • Environment configuration with dotenv

Dev Tools

  • ESLint + Prettier (code quality and consistency)
  • GitHub Actions (CI/CD pipeline)

What I Learned

Frontend / Backend Separation & Independent Deployment

Development

  • Backend runs on port :3001, frontend on :5173
  • Frontend communicates with backend via REST API (CORS configured)
  • Can develop and test each layer independently
  • Each has its own package.json and npm scripts

Deployment

  • Frontend → Deployed on Vercel (static/SPA hosting)
  • Backend → Deployed on Render (Node.js server)
  • Fully independent deployment pipelines
  • Environment variables configured for cross-service communication:
    • VITE_API_URL — backend endpoint (frontend side)
    • CORS_ORIGIN — allowed frontend domain (backend side)

Why This Matters

  • Enables separate scaling for frontend and backend
  • Allows frontend updates without redeploying backend
  • Supports different hosting strategies
  • Establishes a clean API contract between services

This is a meaningful shift from the monolithic apps I used to build — much more maintainable and scalable.

Building Microservices-Ready from the Start

I was recently asked about monolithic vs microservices architectures in an interview.

Though this project is small, I intentionally structured it for future flexibility.

The backend is already:

  • An isolated service with its own deployment
  • Exposes a clean REST API
  • Decoupled from the frontend
  • Scalable and replaceable without breaking the UI

If needed, it could evolve into multiple microservices (e.g., GitHub API service, search/cache service, authentication service) — all without touching the existing frontend.

Key takeaway: Start simple but structured. Avoid over-engineering, yet keep concerns separated from the start.

CI/CD with GitHub Actions

Implemented automated checks on every pull request:

  • Code formatting
  • Linting
  • Type checking
  • Build verification

This streamlined development flow ensures quality and consistency across pushes and pull requests.

Architecture diagram

What's Next

  • Add pagination (supported by backend, not yet in UI)
  • Implement sorting options (stars / updated / help-wanted)
  • Display total result count
  • Add automated tests
  • Experiment with EC2 backend deployment
  • Experiment with Kiro

Notes to Self

  • Plan workflows better — avoid unnecessary context switching and time loss
  • Continue focusing on clarity, separation, and maintainability in future projects

Top comments (0)