Epic: Database Operations (Post ORM Backend Implementation)

[manishapriya94]

This epic for earth day 4/21 has moved here

User Story:

• User has authenticated
• Has added their name into the signature box
• Has added their address into the address box
• User moves to next step (new window triggered) payment added
• Successful payment triggers 'send message' button
• Send message button creates a letter to send to the representative
  • Send message triggers a POST to back-end to make a call to LOB API
  • Successful 'send message' should also trigger a POST to back-end to save record into the DB

Development Task

Send User Letter to Lob

• Create POST Function in /api/lob endpoint (lob.js)
• Configure endpoint to accept JSON Objects with Letter information
• Lob API POST request - Letters API
• Send 200 status code upon successful call to Front End
  • Saved in Lob addressbook
• Add Documentation to Wiki Endpoint
• Sample implementation in documentation

Save User Letter Data

• Create Table in PostgresDB via KNEX migration
• Seed User Letter Data
• Create new endpoint /api/userletter endpoint
• Add app.js route information for /api/userletter endpoint
• Create GET function /api/userletter
• Configure to return all user letters that have been created
• Create POST function: user_addressbook  amplify-back-end#124
• Configure endpoint to accept JSON Objects with Letter information
• Use Knex ORM to build insert query
• Send 200 status code upon successful call to Front End
• Add Documentation to Wiki Endpoint
• Sample implementation in documentation

[manishapriya94]

@BeeXiong: Can we bring over the whole record from campaigns when it comes to the template_id for GET? (In the way we did for reps, we can bring over array of campaigns)

@mahrsbar thoughts?

[manishapriya94]

FrontEnd:

• sending user info for sender info
• sending recipient address of representative

[BeeXiong]

@BeeXiong: Can we bring over the whole record from campaigns when it comes to the template_id for GET? (In the way we did for reps, we can bring over array of campaigns)

@mahrsbar thoughts?

I will add a campaigns endpoint that will retrieve all campaigns in an array.

With that said...

The Amplify Endpoint also retrieve's an array of campaigns.

• To avoid having to update multiple functions if something were to change with the campaigns table, I'll be removing the /api/amplify endpoint.
• We should now use /api/campaigns endpoint --> wiki

[BeeXiong]

This is the page that needs to be updated with the new URL

[mahrsbar]

The current amplify endpoint already retrieves all the campaigns which is what I used. There's only three so yeah. But I will update it to api/campaigns. Actually, I don't know if we need to change it? I cleared it up with Manisha.

[BeeXiong]

So this is where I see the back end coming into play and where we need to add endpoints...

• User has authenticated
• Has added their name into the signature box
• Has added their address into the address box
• User moves to next step (new window triggered) payment added
• Successful payment triggers 'send message' button
• Send message button creates a letter to send to the representative
  • Send message triggers a POST to back-end to make a call to LOB API
  • Successful 'send message' should also trigger a POST to back-end to save record into the DB

[mahrsbar]

I would update to include "Has added their address" which would also be sent to LOB API, before the following point:

Has added their name into the signature box

The design has been updated as such. The postal code will still be used for search but we need the full address of the user to send to LOB.

[BeeXiong]

Update @manishapriya94's original post with Dev Task.

One item to point out ⬇️

• Should we trigger the saving of data within our DB in the backend or frontend?

Having the back end automatically save data just saves the front end another call / resending that user letter information in JSON form

[mahrsbar]

• To avoid having to update multiple functions if something were to change with the campaigns table, I'll be removing the /api/amplify endpoint.
• We should now use /api/campaigns endpoint --> wiki

@BeeXiong the search still requires api/amplify{zipcode}, this needs to be changed to api/campaigns{zipcode}. Are you able to clean up the wiki and remove the amplify table as well? I assume we're just sticking with api/campaigns for everything.

[BeeXiong]

I think we can keep the api/amplify/{zipcode} endpoint because it actually exposes the Google Civic API. There's nothing coming from the Database.

I can switch it to api/campaigns/{zipcode} if it's easier. Just thought we create that separation between the stuff coming from the DB and stuff coming from other api's.

[mahrsbar]

I think it's a bit confusing because api/amplify no longer exists so api/amplify/{zipcode} loses context. The term amplify isn't very intuitive as related to zip codes but open to changing it to something else so you don't lose the differentiation.

[BeeXiong]

Would api/representative/{zipcode} make sense?

[mahrsbar]

Yess, that works great.

[manishapriya94]

Hey @BeeXiong, @nawazkhan just added some changes to the way the API was routed OpenSourceFellows/amplify-back-end#114 and then added the post function OpenSourceFellows/amplify-back-end#115

[manishapriya94]

Notes from meeting 11/4
By next week we want to do the following

@manishapriya94

• update lob documentation in wiki

@BeeXiong:
In lob.js lines 135:

• for the user address that makes up from: create address which combines address verification and returns an address_id string
• frontend uses this string to create a lob post request in line 18

@mahrsbar:

• For to, format representative data from google civic api by lob address object attributes:

Lob:

Google Civic API:

@nawazkhan:

• In file, check if successful payment by stripe and then route to lob post on line 20 in lob.js

[manishapriya94]

Resolved by create_letter function in lob.js