Skip to content

Latest commit

 

History

History
123 lines (92 loc) · 4.67 KB

Q&A.md

File metadata and controls

123 lines (92 loc) · 4.67 KB

Implementation and Conceptual Questions

The Brief

  • Fork this repository
  • Create a source folder to contain your code.
  • In the source directory, please create a PHP or Python web application
  • Your application should accomplish the following:
    • Connect to the GitHub API
    • Find the nodejs/node repository
    • Find the 1000 most recent commits (only hashes)
    • Create a model and store the 1000 most recent commits in the database. Make sure to avoid any duplicates.
    • Create a route and view that displays the recent commits by author from the database.
    • Keep your solution flexible enough to be able to later on provide support for the bitbucket-api/gitlab-api, etc...

Challenge created by Circunomics.

How would your solution differ if you had to call another external API to store and receive the commits?

Assumptions

  • There's an external HTTP API we call to store and retrieve commits.
  • The external API accepts JSON arrays of commits (similar to CommitDTO::toArray()).
  • The external API has endpoints like:
    • POST /commits to save many commits
    • GET /commits with query parameters (provider, owner, repo, offset, limit)
  • It returns JSON, ideally grouped or paginated.

CommitRepository

The only changes needed are the methods in the CommitRepository must be updated to allow for requests to an external API.

Benefits

  • Zero changes to service and API classes.
  • Clean separation of concerns.
  • Easy to test and mock with fake HTTP responses.

Other Potential Improvements

  • Consider caching external results to reduce API calls.

Imagine this mini-project needs microservices with one single database

Microservices should be loosely coupled and independently deployable. Sharing a database introduces coupling.

Considerations

  • Avoid tight DB coupling: If the database is shared, encapsulate all SQL access within one service per table.
  • Define clear service contracts.
  • Add health checks and logging per service.
  • Use OpenAPI / Swagger to document service endpoints.

Microservices

  1. VersionControlFetcherService

    • Fetches commits via GitHub/GitLab APIs.
    • Runs periodically or on-demand.
    • Writes commits to the database.
    • Queue-supported for rate-limiting and retries.

  2. CommitStorageService

    • Abstracts commit persistence.
    • Handles deduplication and batch inserts.
    • Owns the commits table schema.
    • Exposes an internal API for write access.

  3. CommitQueryService

    • Exposes endpoints for reading.
    • Optimized for read patterns (caching, pagination).
    • No write access to DB.

  4. WebGateway/UIService

    • Handles web routes (/view, /get, /index).
    • Talks to CommitQueryService and optionally VersionControlFetcherService.
    • Lightweight logic; presentation-focused.

  5. ErrorLogging/MonitoringService

    • Receives logs/events/errors from other services.

Database

One PostgreSQL or MySQL instance with at least the following tables:

  • commits (central table)
  • services_log (for debug/errors)
  • If supported, materialized views for reporting

Each service accesses the DB through its own repository layer (no direct cross-service SQL).

Communication Between Services

  • Use REST or gRPC for internal service-to-service calls.
  • Use message queues for async fetching, commit ingestion, or retries.

Deployment Layout

/services
  /fetcher             # fetch commits
  /storage             # handles inserts
  /query               # read-only APIs
  /web-gateway         # UI + routes

Use containers per service. Define their own Dockerfile, composer.json, and tests.