Connecting webpage views to webhook response?

1

I’m creating a webhook that receives an OAuth install code from a 3rd party app and then complete the process of installation and authentication. I’d like to display an ‘installing’ page to users while this work is being done, and then a ‘success’ or ‘error’ page once the process is complete.

I see you can return a body as part of the response from a webhook function – does anyone have recommendations on how to –

  1. connect rendered HTML (or a view within a framework like React or Svelte) to the body response?
  2. send an initial response (e.g. ‘installing’ view) firs and then a subsequent response (e.g. ‘success’ view) later?

Thanks

2

Hello Clayton!

I need to discuss your issue with our developers to give you a full response. I’ll let you know soon.

Lada Kokotova | Technical Support Engineer

1 Like
3

Hey Clayton - Webhooks are usually used to allow 3rd party applications (other servers) to send/receive callbacks. In this case, the 3rd party app that seems to be creating the 0Auth install code would call the webhook endpoint and receive a response, however the flow would leave your client application (user app) in the dark…

If I’m understanding your context correctly, I’d approach the problem like this.

Schema:
Create a table called InstallCodes that has a status field with options [pending, installing, success, failure], code and any other relevant fields.

  1. User requests OAuth install code from client application (User Front End + button click event).
  2. A Mutation is sent that creates a new InstallCode record with status set to pending.
  3. A Subscription request gets established that listens for updates on that InstallCode record.
  4. A Trigger.after function runs on InstallCode.create that makes the request to the 3rd Party Service.
    4.1 If the OAuth code gets returned in the response, great.
    4.2 If the OAuth code is returned via a webhook, you need to deploy a webhook to accept the request.
  5. Once the Oauth code is obtained (webhook or trigger) update the InstallCode record with the code and set status to “Installing”.

Depending on whether the Install happens on the Front end client app or a server application will dictate whether the code can be collected from the running Subscription or a new Query. HOWEVER, either way, this method allows you to listen to updates on the InstallCode.status field and then reflect those state changes on your front-end in real-time, as opposed to relying on HTML in a response body.

1 Like
4

Sebastian, thank you for the detailed reply. This helps a lot. I’ll see if I can put it into practice, and circle back if any issues crop up implementing something along these lines. Thanks again.

5

@sebastian.scholl Creating a reference record with status flags plus triggers/subscriptions sounds like a way to create an event pipeline of sorts in 8base. Am I following this correctly?

Do you have any thoughts on ways you could retry those events when they fail in 8base?

For example, when a function that is triggered by the change of status fails to complete its work to progress the status to its next step and the action needs to be retried or replayed again later.

And similarly, any ways of creating alerts from those failed actions?

Thanks for any other insights on this.

6

Yeah, conceptualizing it as an event pipeline makes sense and is a good way of looking at it.

I’m a little fuzzy on where/when you’re intended to implement the retry feature. I can’t think of a way to re-invoke a trigger FROM within itself. You could do it with code though.

I do NOT recommend using this code lol. However, the idea should make sense.

// My trigger function
export default function (event, ctx) {
  // some code  
  let count = 0
  let response;

  const numberOfRetries = 5
  
  do {
     try {
       response = functionThatDoesActionWhichMayFail()
     } catch {
       console.log("Got error. Attempt " + count++);
     }
  } while (count < numberOfRetries || response == undefined)
  // more code
}
7

Thanks @sebastian.scholl, I think that could work in some cases.

In general, I’m looking at how I could best implement an event-driven architecture that can be resilient with things like automatic retries and the ability to access and replay events when things fail.

8

Keep us updated on your findings!