William/v2 prototype#40
Conversation
swansontec
force-pushed
the
william/v2-prototype
branch
from
d89f1fc to
e030330
Compare
The v2 API passes the key in the payload.
swansontec
force-pushed
the
william/v2-prototype
branch
from
e030330 to
615dddd
Compare
| export const asPushMessage: Cleaner<PushMessage> = asObject({ | ||
| title: asOptional(asString), | ||
| body: asOptional(asString), | ||
| data: asObject(asString) |
samholmes
left a comment
samholmes
left a comment
There was a problem hiding this comment.
Some feedback to discuss
| export type PushEventState = | ||
| | 'waiting' // Waiting for the trigger | ||
| | 'cancelled' // Removed before the trigger happened | ||
| | 'triggered' // The trigger happened, but not the effects | ||
| | 'complete' // The trigger and effects are done | ||
| | 'hidden' // Removed after being triggered |
There was a problem hiding this comment.
Are cancelled and hidden internal states? If a client removes a push event it is not returned by the public API, but it remains in the DB with either of these states?
If I understand correctly, triggered is the state just before completing the event (so this is also an internally-concerned state). I think we should word this as // The trigger and event is done, because at least on the client-side, the word "effect" is the derived state(s) from the action/event; and the action/event is the cause of the effect.
| export interface NewPushEvent { | ||
| readonly eventId: string | ||
| readonly broadcastTxs?: BroadcastTx[] | ||
| readonly pushMessage?: PushMessage | ||
| readonly recurring: boolean | ||
| readonly trigger: PushTrigger | ||
| } |
There was a problem hiding this comment.
Doesn't this belong in the pushApiTypes.ts?
|
|
||
| const apiKey = 'demo-api-key' | ||
| const deviceId = 'example-device' | ||
| const loginId = base64.parse('EE+tBb5wM63qwCDVidzwUQThH9ekCSfpUuTQYujSmY8=') |
There was a problem hiding this comment.
Is this loginId a test loginId?
| /** | ||
| * All push server HTTP methods use "POST" with JSON. | ||
| */ | ||
| async function postJson(uri: string, body: unknown): Promise<unknown> { |
There was a problem hiding this comment.
I wish I had noticed this function early. I like it and would prefer to use it in the GUI (if not now, then later).
| await postJson( | ||
| 'http://127.0.0.1:8001/v2/device/update/', | ||
| wasPushRequestBody({ | ||
| apiKey, | ||
| deviceId, | ||
| data: wasDeviceUpdatePayload({ loginIds: [loginId] }) | ||
| }) | ||
| ) |
There was a problem hiding this comment.
This would be the isomorphic dream:
import pushServer from 'https://push.edge.app/api'
pushServer.device.update({ apiKey, deviceId, data: { loginIds: [loginId] } })This magic would be enabled with URL imports in our client-side environments (something Deno or Bun enables) and using a special HTTP server framework (ala serverlet) which could syndicate a public API derived from the defined routes at the /api route.
TL;DR: Another thing to add to the side-project/experiment list.
| ) | ||
| } catch (error) { | ||
| if (asMaybeConflictError(error) == null) throw error | ||
| await addEvent(connection, event, new Date(created.valueOf() + 1)) |
There was a problem hiding this comment.
Would this recursion thrash? The created date param wont prevent the recursive call to no longer conflict. We may want a delay here?
| /** | ||
| * Handles all the effects once a row has been triggered. | ||
| */ | ||
| export async function triggerEvent( |
There was a problem hiding this comment.
Where is this used? Or is it used in a later PR?
2 participants
Almost everything should be here now from the server point of view, but it needs to be tested, and we need the publisher, rates checker, and blockchain checkers still.