konnosDashboard
README.md74 lines · main
1# counter
2
3the smallest possible briven app — one table, two functions, demonstrates the
4reactive query pipeline end-to-end without any UI complexity.
5
6## what's in here
7
8```
9counter/
10├─ briven.json project descriptor (filled by `briven link`)
11├─ briven/
12│ ├─ schema.ts one table: counters (id, count)
13│ └─ functions/
14│ ├─ getCount.ts reactive query · returns {id, count}
15│ └─ increment.ts mutation · upserts +1, returns new count
16└─ README.md you are here
17```
18
19## try it in 30 seconds
20
21```sh
22# 1. authenticate (skip if you already have credentials stored)
23briven login --project p_<id> --key brk_<...>
24
25# 2. copy, link, deploy
26cp -r examples/counter my-counter
27cd my-counter
28briven link
29briven deploy
30
31# 3. exercise the api
32briven invoke getCount
33briven invoke increment
34briven invoke increment --body '{"by":5}'
35briven invoke getCount
36```
37
38## react client
39
40```tsx
41import { BrivenProvider, useMutation, useQuery } from '@briven/react';
42
43function App() {
44 return (
45 <BrivenProvider config={{ projectId: 'p_<id>', apiKey: 'brk_<...>' }}>
46 <Counter />
47 </BrivenProvider>
48 );
49}
50
51function Counter() {
52 const { data } = useQuery('getCount', {});
53 const inc = useMutation('increment');
54 return (
55 <button onClick={() => inc({})}>
56 count: {data?.count ?? '…'}
57 </button>
58 );
59}
60```
61
62`useQuery('getCount')` subscribes to the `counters` table. When `increment`
63commits its UPDATE, postgres NOTIFY fires, the realtime service re-invokes the
64query, and every subscribed button re-renders with the new count.
65
66Two browser windows side by side make the reactive nature obvious — increment
67in one, watch the other refresh in real time.
68
69## next steps
70
71- per-user counters: extend `increment` to read `ctx.auth.userId` and use that
72 as the counter id, so each signed-in user has their own row
73- rate limit: the existing project rate-limit middleware already caps invokes
74 per-tier; for stricter per-user limits, gate inside the mutation handler
Preview

counter

the smallest possible briven app — one table, two functions, demonstrates the reactive query pipeline end-to-end without any UI complexity.

what's in here

counter/
├─ briven.json              project descriptor (filled by `briven link`)
├─ briven/
│  ├─ schema.ts             one table: counters (id, count)
│  └─ functions/
│     ├─ getCount.ts        reactive query · returns {id, count}
│     └─ increment.ts       mutation · upserts +1, returns new count
└─ README.md                you are here

try it in 30 seconds

# 1. authenticate (skip if you already have credentials stored)
briven login --project p_<id> --key brk_<...>

# 2. copy, link, deploy
cp -r examples/counter my-counter
cd my-counter
briven link
briven deploy

# 3. exercise the api
briven invoke getCount
briven invoke increment
briven invoke increment --body '{"by":5}'
briven invoke getCount

react client

import { BrivenProvider, useMutation, useQuery } from '@briven/react';

function App() {
  return (
    <BrivenProvider config={{ projectId: 'p_<id>', apiKey: 'brk_<...>' }}>
      <Counter />
    </BrivenProvider>
  );
}

function Counter() {
  const { data } = useQuery('getCount', {});
  const inc = useMutation('increment');
  return (
    <button onClick={() => inc({})}>
      count: {data?.count ?? '…'}
    </button>
  );
}

useQuery('getCount') subscribes to the counters table. When increment commits its UPDATE, postgres NOTIFY fires, the realtime service re-invokes the query, and every subscribed button re-renders with the new count.

Two browser windows side by side make the reactive nature obvious — increment in one, watch the other refresh in real time.

next steps

  • per-user counters: extend increment to read ctx.auth.userId and use that as the counter id, so each signed-in user has their own row
  • rate limit: the existing project rate-limit middleware already caps invokes per-tier; for stricter per-user limits, gate inside the mutation handler