prisma-home-challenge

Prisma Home Challenge

This is my take on Prisma's Home Challenge.

This is a Next.js project made in Typescript and bootstrapped with 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 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:

yarn dev

Open 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.