Skip to content

Latest commit

 

History

History
98 lines (75 loc) · 4.37 KB

README.md

File metadata and controls

98 lines (75 loc) · 4.37 KB

Gites

This is Gites - the best place to search through GitHub repositories. It is a simple and easy-to-use search engine that allows you to find the repositories you need.

Getting Started

  1. Rename .env.local.example to .env.local
  2. Install deps npm install
  3. Run the development server:
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

Architecture Decisions

Provider vs. URL State Using context and a provider makes sense in many cases, especially when the application is too small to introduce a complex state management library. On the other hand, it is almost always too large to use useState for everything.

I tested both approaches for a while, and in the case of the first one, too much load shifts to the client side. Additionally, introducing context and a provider necessitates installing additional libraries, increases the amount of code, and reduces its readability. I opted to keep the search parameters in the URL, which also allows for easy sharing of search input data.

Cache By using a provider that had to operate on the client side, communication with the API would also need to be handled in the browser. Initially, I considered using the client-side library React Query for working with the API and caching. The choice between API types for such a small application is insignificant to me, so I followed how queries are handled in Fourthwall and chose REST API.

If I had chosen, for example, the GraphQL GitHub API, I would still have selected the React Query library because the library supporting Apollo Client in SSR has been in the experimental phase for over a year. Moreover, the basic library is heavy (unpacked 7.3 MB).

I focused on an implementation based on SSR and caching, which was introduced with the new version of the Next framework (from v13). This approach provided benefits in:

  • Application speed
  • Simplicity and code readability
  • Easy management of search state (URL)

Technical Choice Explanation

Framework Next.js: My choice was guided by several factors:

  • Team stack: The tech stack of the team I am joining (resources).
  • Time to complete the task (resources).
  • Type of application: If we were to focus more on static content, I might consider Astro due to excellent solutions like Frontend Islands. In this case, there isn't much of that content, and Next.js also offers many features, such as SSR.

TypeScript: Standard for avoidyng many type related errors.

Tailwind CSS: A utility framework that allows me to focus on more important aspects of building the application. Due to limited time, I chose this solution.

MVP Implementation

  • Init repo and config
  • Layout
  • Search input field
    • Deterministic results for identical URL search parameters
      • search param
      • pagination
      • sorting
  • API layer
  • Results table with sortable columns:
    • Name
    • Owner
    • Stars
    • Created at
  • Pagination
  • RWD
  • Readme

Future Improvements

  • The RepositoriesTable component could be replaced with a generic Table using appropriate props and generic types.
  • Instead of disabling the search, display a message that is more user-friendly. The user doesn't necessarily need to immediately associate the disabled button with the lack of a search query.
  • Add more columns for sorting. We can sort the results of our query by the number of stars, forks, help-wanted-issues, or how recently the items were updated. Since we only have stars, we can only manage the order.
  • not-found page
  • Empty state
  • Error states
  • Cache settings
  • More info in results table
  • Loading states
  • Transitions
  • Tests - since it is a super small app, I’ll do it only if I have some time left
    • Vitest ft React Testing Library
  • Adding repo to favorites
  • Repository detailed preview (nested views)
    • Latest commits etc.
  • Light/Dark theme
  • Search history
  • Search type between repos an users
  • Add Github Auth to synchronise favorites repos
  • Log errors in Sentry or AppSignal
  • Integration with OpenAI API for a simple repo summary

Known Limitations

  • Scale: For a more complex application, I would consider dividing it into multiple contexts, but it would need to be something significantly larger with several distinct features.