profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/airhorns/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Harry Brundage airhorns Ottawa harry.me Developer developer. Working on making development suck less at https://gadget.dev

airhorns/codejam 3

a node.js application written for the mcgill codejam in 48 hours

airhorns/body-fractals 2

OpenGL fractal renderer controlled by your body via Kinect!

airhorns/backbone 1

Give your JS App some Backbone with Models, Views, Collections, and Events

airhorns/batman 1

Fighting Crime and Kicking Apps

airhorns/batman-rails 1

Easily use batman.js with Rails 3.1

airhorns/ble-gateway 1

Teensy node service for receiving BLE beacons and firing them onto an MQTT bus

pull request commentfastify/fastify-passport

[WIP] Support custom SessionManager

@AaronPorts probably yes, want to prepare a PR? I think it'd be good to keep support for both session managers for a bit while the community transitions over

mgcrea

comment created time in 3 days

issue commentfastify/fastify-websocket

Use Set-Cookie header within websocket request

Yeah, or, other folks layer in authentication (or whatever side channel information they need to share) into a first, special kind of message between the websocket client and server. graphql-ws for example has an init message between the server and the client that can hold any arbitrary payload which is handy: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#connectioninit

The browser Websocket constructor doesn't let you set headers really, so it's hard to send any data other than cookies from the client also.

ulrichrobin

comment created time in 3 days

pull request commentjoin-monster/join-monster

Add the ability for scalars to be powered by sqlTables

Ok, rebased, fixed this to actually get run by the tests, and fixed the tests!

airhorns

comment created time in 9 days

push eventgadget-inc/join-monster

Vasundhara Mehta

commit sha 9e5480dde1cdafea35f758f9fe4965d96c0f778c

allow for page size limit

view details

Vasundhara Mehta

commit sha 24913a8e315def49912cf6462c04d65556ddb28f

add default page size field

view details

Vasundhara Mehta

commit sha 63be8e11bc43d5bdb35cacaa9fc2c8f2a983b3a3

fixed bug, updated version and changelog

view details

Vasundhara Mehta

commit sha 46e864e69a97110985c6fcbaeca6f6bd338f9896

fix bug with page size logic and add test for same

view details

Harry Brundage

commit sha 320d8dc7159f37d8ed390da3d9e2c8093e744410

Merge pull request #462 from vasdhara/feature/page-size-limit allow for page size limit

view details

Harry Brundage

commit sha 45b21569919ced1ea456549bab7a6b6ff2f6e6d5

Update TypeScript alwaysFetch definitions to permit arrays of column names

view details

Harry Brundage

commit sha 74e3b8ff3aaeb313f4e052f7b6b7c05c91e095be

Add the ability for scalars to be powered by sqlTables join-monster excels at retrieving exactly the fields asked for by a given GraphQL query, but sometimes, there isn't an exact 1-1 correspondence between the desired fields in a GraphQL API and the table structure powering the system. Sometimes, data is normalized in the database or broken out into many tables for performance or reporting reasons or whatever, and join-monster supports these non 1-1 mappings fine with sqlExpr, alwaysFetch, and custom resolvers just fine, except when the "virtual" field is a scalar. I've ended up having to use a few custom scalars in my application, mostly from the `graphql-scalars` package as well as a couple other random ones, and I have one that is powered by a whole other table in the actual database schema. As an example, I have a `Post` object with normal fields that map to columns, but then a `tags` field on the Post that should return a string of tags, where the Tag is a custom scalar to apply some special parsing and formatting to the tag. The tags are stored in their own tags table in the database. To expose this using `join-monster`, I could create a whole new `GraphQLObjectType` to represent Tags and then have a `{name, id}` field or whatever, but I feel like that is changing the design of the API to accomodate join-monster (and GraphQL to an extent), instead of making the nicest API for developers, which would just be a plain old array of strings. So, I'd like to be able to do a `GraphQLList` of `Tag`, where `Tag` is a `new GraphQLScalar`, and have `join-monster` traverse that join and fetch my tags from the database. Turns out the only thing preventing this was the whitelist of types that `join-monster` looks for `sqlTable` on, so that's the only actual functional change in this PR. This is probably a pretty rare thing, but it's super handy for these custom scalars, as well as the JSON scalar escape hatch that folks might use to escape the strict typing shackles of GraphQL when they need to.

view details

push time in 9 days

push eventjoin-monster/join-monster

Vasundhara Mehta

commit sha 9e5480dde1cdafea35f758f9fe4965d96c0f778c

allow for page size limit

view details

Vasundhara Mehta

commit sha 24913a8e315def49912cf6462c04d65556ddb28f

add default page size field

view details

Vasundhara Mehta

commit sha 63be8e11bc43d5bdb35cacaa9fc2c8f2a983b3a3

fixed bug, updated version and changelog

view details

Vasundhara Mehta

commit sha 46e864e69a97110985c6fcbaeca6f6bd338f9896

fix bug with page size logic and add test for same

view details

Harry Brundage

commit sha 320d8dc7159f37d8ed390da3d9e2c8093e744410

Merge pull request #462 from vasdhara/feature/page-size-limit allow for page size limit

view details

push time in 9 days

PR merged join-monster/join-monster

Reviewers
allow for page size limit

Description

Allows server to enforce max page size limit

References

Fixes #416

Testing

Test API users and comments have been updated with sqlPageSize: 100 and can be used for testing. PR was developed in Javascript, MacOS, Chrome.

  • [x] This change adds test coverage for new/changed/fixed functionality

Checklist

  • [x] I have added documentation for new/changed functionality in this PR via updating docs files

Question: Do I need to add comments or update the change log for documentation? Unclear which files to update.

+214 -5

2 comments

13 changed files

vasdhara

pr closed time in 9 days

issue closedjoin-monster/join-monster

Enforce maximum page size

I have a paginated field and everything about join-monster looks fine, but I wish I had some sort of validation on first argument of my query.

I don't want my client to query for a thousand items at once, just for, let's say, a hundred. But I didn't find any kind of validation like this. Is this implemented somehow, but I didn't find it, or at roadmap in a near future? I guess it could be something like this, at field specs:

{
  ...
  sqlPaginate: true,
  sqlPageLimit: 100,
  ...
}

closed time in 9 days

hugobarreiro
PullRequestReviewEvent

create barnchgadget-inc/baseweb

branch : build-689469b9d

created branch time in 10 days

created taggadget-inc/fastify-renderer

tagfastify-renderer-v0.1.23-gitpkg-f66f737

Fast server side rendering for Fastify using Vite

created time in 10 days

create barnchgadget-inc/fastify-renderer

branch : imperative-render

created branch time in 10 days

Pull request review commentgadget-inc/fastify-renderer

Update RenderBus to use streams

+import { Readable } from 'stream'++export interface Stack {+  content: string[]+  hasEnded: boolean+  contentStreamed: boolean+  stream: Readable+}+ /** Holds groups of content during a render that eventually get pushed into the template. */ export class RenderBus {-  stacks: Record<string, string[]> = {}+  stacks: Record<string, Stack> = {}   included = new Set<string>() -  push(key: string, content: string) {-    this.stacks[key] ??= []-    this.stacks[key].push(content)+  private createStack(key) {+    const stack: Stack = (this.stacks[key] = {+      content: [],+      hasEnded: false,+      contentStreamed: false,+      stream: new Readable(),+    })++    stack.stream._read = function () {+      if (stack.hasEnded && stack.contentStreamed) {+        this.push(null)+      } else {+        this.push(stack.content.join('\n'))+        stack.contentStreamed = true+      }+    }++    return stack+  }++  push(key: string, content: string | null) {+    if (!this.stacks[key]) this.createStack(key)+    if (this.stacks[key].hasEnded) return

Ya I think thats a good idea, that'd be a developer's mistake or ours

AyoubElk

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentgadget-inc/fastify-renderer

Update RenderBus to use streams

 export class ReactRenderer implements Renderer {   }    private renderStreamingTemplate<Props>(app: JSX.Element, bus: RenderBus, ReactDOMServer: any, render: Render<Props>) {+    this.runHeadHooks(bus)

Ah duh, makes sense that there might be pre rendering hooks too.

AyoubElk

comment created time in 13 days

Pull request review commentgadget-inc/fastify-renderer

Update RenderBus to use streams

 import template from 'stream-template'  /** Data passed to the template function by the renderer */ export interface TemplateData<Props> {-  head: string-  tail: string+  head: NodeJS.ReadableStream+  tail: NodeJS.ReadableStream

👍 Makes sense to me! I think it may be a bit awkward at some points to have to convert all the stuff you might want to write into stream write calls, but if we're gonna do streaming, that is the deal!

AyoubElk

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentjoin-monster/join-monster

allow for page size limit

 const Post = new GraphQLObjectType({ ```  The `limit` can be an integer or a function that returns an integer. This feature is only supported if pagination is supported for you SQL dialect.++### 4. Max and Default Page Size in Pagination++If you want to limit the maximum number of results allowed in a list field,+you can use the `sqlPageLimit`.+To set a default page size use `sqlDefaultPageSize`. without a sqlDefaultPageSize, server defaults to a max limit as per the db in use.

Ah ok, that makes sense to me how it is!

vasdhara

comment created time in 14 days

Pull request review commentjoin-monster/join-monster

allow for page size limit

 export interface FieldConfigExtension<TSource, TContext, TArgs> {   ) => string   sqlJoin?: SqlJoin<TContext, TArgs>   sqlPaginate?: boolean+  sqlPageLimit?: number+  sqlDefaultPageSize?: number

👍

vasdhara

comment created time in 16 days

Pull request review commentjoin-monster/join-monster

allow for page size limit

 test('should handle an interface type', async t => {   }   t.deepEqual(expect, data.user.writtenMaterial) })++test('should not allow pagination with greater than pageSizeLimit at the root', async t => {+  const query = makeUsersQuery({ first: 1000 })+  const { data, errors } = await run(query)++  t.deepEqual(data.users, null)+  t.deepEqual(errors[0].message, 'Maximum page size of User type, is 100')

I think that comma shouldn't be there right? 'Maximum page size of User type, is 100' -> 'Maximum page size of User type is 100

vasdhara

comment created time in 16 days

Pull request review commentjoin-monster/join-monster

allow for page size limit

 const Post = new GraphQLObjectType({ ```  The `limit` can be an integer or a function that returns an integer. This feature is only supported if pagination is supported for you SQL dialect.++### 4. Max and Default Page Size in Pagination++If you want to limit the maximum number of results allowed in a list field,+you can use the `sqlPageLimit`.+To set a default page size use `sqlDefaultPageSize`. without a sqlDefaultPageSize, server defaults to a max limit as per the db in use.

I think it would actually default to no limit right? That's what I experienced locally on Postgres at least, there's just no LIMIT clause in the output SQL

vasdhara

comment created time in 16 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentjoin-monster/join-monster

allow for page size limit

 const User = new GraphQLObjectType({  The `type`, `args`, and `resolve` are made simple with these helpers, but can all be done manually. In a manner similar to prior examples, we need to tell Join Monster how to get the data with a `JOIN`. Both **one-to-many** and **many-to-many** are supported. Place either the `sqlJoin` or `sqlJoins` alongside the connection type and you're ready to handle requests for paginated data. -| Pros | Cons |-| ---- | ---- |-| simple setup | not scalable to large amounts of data |-| write your own custom paging logic |  |-| portable to all SQL dialects |  |

I think these formatting changes are good but they are unrelated to this PR so probably shouldn't be included in it

vasdhara

comment created time in 17 days

Pull request review commentjoin-monster/join-monster

allow for page size limit

 export function populateASTNode(     // we'll set a flag for pagination.     if (fieldConfig.sqlPaginate) {       sqlASTNode.paginate = true+      if (fieldConfig.sqlPageLimit) {+        if (+          fieldConfig.sqlPageLimit < sqlASTNode.args.first ||+          fieldConfig.sqlPageLimit < sqlASTNode.args.last+        ) {+          throw new Error(+            `Maximum page size of ${gqlType.name} type, is ${fieldConfig.sqlPageLimit}`+          )+        }+      }

This accounts for the case where the query specifies a first or last argument, but if the query doesn't specify an argument at all, then this condition will never be triggered, allowing a query to fetch all the data without any page size at all. I think we should prevent that as that's the kind of performance pathology that is specifically really bad!

I see two ways forward:

  • default the page size to the sqlPageLimit if it is set
  • add another parameter like sqlDefaultPageSize which would allow a default smaller than the maximum.

Thoughts?

vasdhara

comment created time in 17 days

PullRequestReviewEvent

created taggadget-inc/esbuild-dev

tagesbuild-dev-v0.7.2-gitpkg-34425f6

_Real_ fast development reloading for server side TypeScript projects.

created time in 23 days

created taggadget-inc/esbuild-dev

tagesbuild-dev-v0.7.2-gitpkg-402b8c0

_Real_ fast development reloading for server side TypeScript projects.

created time in 23 days