-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mock API for the front end #97
Comments
I know I asked for the issue but it was actually for @rmcguire6 Thanks for creating it though @cMikolai |
@silentkdev We can close this one, too, right? |
i'm a little torn on this one. It might be helpful to have a mock api we can switch in and out to experiment with while developing for the front end, as we might still be waiting on database schemas to be changed since not everyone knows how to do that. |
Mhm, that's a good point actually. Let's add it to the points-to-discuss list (... that I will have to start now 🤣 ) |
So, I've been thinking you're right @silentkdev. We definitely need a mock api/database for some testing to not mess with what we will have in production. Also, to make access easier for developers when it comes to Chingu externals etc |
btw I am pushing this into v2 now |
Just a note, when people are developing and working on stuff they won't affect what's in production. The development database is distinct from the production one. My main concern was that if someone working on a feature didn't have experience with postgresql it might be difficult for them to test out different things that required different data and data schemas then the ones we have from the current schema. |
@silentkdev I updated the user story and details for this one, would you mind adding additional details? Also, your thoughts on if this needs split up into multiple stories (need the API in Next / need it to point to a dev DB in dev / etc...) |
So circling back around to this finally, maybe we could use the Next API functionality as our mock api. We can use something like Faker.js in the route handlers to generate the fake data we're trying to experiment with. This would be much easier for someone to test quickly with than messing with the postgres schema. It also could help us iterate quicker on the shape of our data as well. Something important to note would be that all the calls to the API would happen client-side for testing and experimenting whereas once we were going to add the logic in permanently we would need to make those calls in the Next getServerProps/getStaticProps methods. |
Story:
As a developer I would like a mock API to use in development so that I have quick and easy access to data without involving the production DB.
Details:
The text was updated successfully, but these errors were encountered: