# Prisma Home Challenge

This is my take on Prisma's Home Challenge.

This is a [Next.js](https://nextjs.org/) project made in [Typescript](https://www.typescriptlang.org/) and bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).

## Architecture

For an application like this, my candidates were

- Create React App: Easy to set up, but really heavyweight in terms of dependencies.
- Vite: Really fast CRA alternative, but also very minimalistic. I would had to spend time working on routing and other configurations.
- Gatsby & Next.js: SSG and routing comes out of the box, very handy for an app like this.

So based on this, my two top candidates were Gatsby & Next.js, I decided to go with Next.js because of personal preference :)

as a side note the api doesn have cors configured correctly, so i couldnt query directly from fe, and for the challenge i set up a proxy to bypass this
Aside from my reasons of choosing Next.js, I ended up creating a proxy for the API, since every request from a client application to `https://prisma-fe-dev-assignent.vercel.app/api/` was blocked by CORS policy (this was a workaround to get the API working).

I added the option to choose between the original API or the proxy: adding the env variable `NEXT_PUBLIC_API=https://prisma-fe-dev-assignent.vercel.app/api` would make the client application to use the original backend instead of using proxy.

I also used [TailwindCSS](https://tailwindcss.com) to speed up the development process.

## Getting Started

First, create a `.env.local` file with the contents of `.env.example`

Then run the development server:

```bash
yarn dev
```

Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.

## Feedback on the API

There are a couple of things that I would do differently if I could change the API:

1. Change CORS policy to allow fetch by any origin (only because this is a public API)
2. Improve responses:
   a. Server should return client error responses (40X) if the data was invalid, not 500 (Server error response).
   b. It would be nice if `/login` endpoint returns user data instead of just a message
   c. Double check message content (there was a tiny typo in the failed response for `/login`)
   d. I would change the result of `/user/{id}` to return a user with an `id: int` instead of `id: string` to keep consistency with the other endpoints.

## Improvements

I would improve the UX of the application:

- Better handling of form states (error message doesn't dissapear until new submission )
- Do not resend data if the form inputs didn't change
- Customize inputs to use personalised messages and validations.