Open DietBepis1 opened 1 year ago
As far as locally faking the endpoint goes, we could use something like json-server
: https://github.com/typicode/json-server.
For local configuration, could we not just set something like CICERO_ENDPOINT_URL
in .env
to the test endpoint locally vs. the real one in production?
I put together a small prototype locally using json-server
. You can inject the routes it generates into the apiRouter
after the other routes are defined, and all of them will work(i.e. /api/campaigns will work as usual, /api/representatives will return fake data from the json-server
schema defined in db.json
locally). We can just wrap this injection in a conditional that looks at the environment to ensure that it only happens locally.
I am a little confused by why this route should be a POST endpoint, however. It seems like if this is to simply return a list of representatives that should be GET? @DietBepis1 could you shed some light on that aspect?
Hey, is it ok if I join on this issue too? I've been wanting to work with API-related issues @DietBepis1 @knowaveragejoe
@christina-ml I'd be happy to have you, check out this PR:
I put together a small prototype locally using
json-server
. You can inject the routes it generates into theapiRouter
after the other routes are defined, and all of them will work(i.e. /api/campaigns will work as usual, /api/representatives will return fake data from thejson-server
schema defined indb.json
locally). We can just wrap this injection in a conditional that looks at the environment to ensure that it only happens locally. Hey @knowaveragejoe ! Good work setting that up. I think we can simply have that object stored in a JS object and return it under the server. However, I'd still like to have a look at what you've created and if it is good enough, we can go ahead and have that in the application. :)I am a little confused by why this route should be a POST endpoint, however. It seems like if this is to simply return a list of representatives that should be GET? @DietBepis1 could you shed some light on that aspect?
Well, from what I've understood, the reason why most services do that is because POST has more possibilities — A request body is something most HTTP request frameworks don't support for GET.
I put together a small prototype locally using
json-server
. You can inject the routes it generates into theapiRouter
after the other routes are defined, and all of them will work(i.e. /api/campaigns will work as usual, /api/representatives will return fake data from thejson-server
schema defined indb.json
locally). We can just wrap this injection in a conditional that looks at the environment to ensure that it only happens locally. Hey @knowaveragejoe ! Good work setting that up. I think we can simply have that object stored in a JS object and return it under the server. However, I'd still like to have a look at what you've created and if it is good enough, we can go ahead and have that in the application. :)I am a little confused by why this route should be a POST endpoint, however. It seems like if this is to simply return a list of representatives that should be GET? @DietBepis1 could you shed some light on that aspect?
Well, from what I've understood, the reason why most services do that is because POST has more possibilities — A request body is something most HTTP request frameworks don't support for GET.
Honestly, the POST request could be a GET. @paramsiddharth is correct that many GET requests (including in Express.js) will ignore the request body, but in this case, we are just passing the zipcode as a parameter in the Cicero call, and all the Authentication is sent in the request headers.
@trushmi is it ok if I work on this as well?
I am starting to run into issues with our "policy" for Cicero. Since it is such an integral part of our application, I think it is a high priority to create a fake endpoint for testing instead of relying on a trial key.
Back-end todos:
Other todos:
Here is the schema that is returned for each representative from Cicero: