• Table of contents
• Golang API server
  • Possible API changes
    • limit=0
  • ActiveRecord-style callbacks/hooks
    • Existing code

Golang API server¶

Possible API changes¶

limit=0¶

Rails API implements limit=0 by returning zero items. It would simplify the Go client and server code to change the semantics so limit=0 means "no limit / let the server choose a limit". Using limit=0 to count records would still work, but responses would be bigger; it would be more efficient to use limit=1&select=[].

ActiveRecord-style callbacks/hooks¶

Currently thinking about how to structure the callbacks that happen when updating and saving a record.

Types of callbacks:

• Fix-ups: modifying a column value, for example, stripping signatures from manifest_text
• Fill-ins: setting certain columns implies filling in another value (for example, setting portable_data_hash from manifest_text)
• Transitions: check that it semantically valid to go to record state Y from record state X (eg X and Y may both be valid, but going (X → Y) may not be valid)
• Permissions: check that the user making the request is allowed to make that modification
• Validations: check that a given record value is valid

Callbacks are very sensitive to ordering. For example, a record may not pass Validation until a Fix-up has been applied. Transition checks may occur before or after Fill-ins or Fix-ups. It is desirable to perform permission checks as early as possible to avoid doing unnecessary work on a request that will be rejected.

Callback types have different contracts:

Fix-up and Fill-in operations potentially modify the update operation. Transition and Permission validations rely on both the before and after state. Plain Validation checks only look at the current state, but may apply to both create and update requests.

Existing code¶

Struct validation https://github.com/go-ozzo/ozzo-validation

Generate Golang structs from Rails ActiveRecord

https://github.com/t-k/ar2gostruct