What is Jiffy?

What does Jiffy do?

Jiffy is a model-based RESTful application services generator written in Go. Think of Jiffy as an accelerator: Jiffy generates a complete backend services application, and that generated application is what will be compiled and then run in production.

Jiffy generates a robust go-based application that treats the data persistence layer in a generic manner. This allows the generated application to connect to number of different database systems (outlined below), without any code changes. Generated applications can be targeted at SAP Hana; Postgres, MySQL, MSSQL or SQLite simply by updating one configuration file.

What does a Jiffy application provide?

Jiffy consumes simple JSON model-files and uses them to generate a working, secure and extensible application server codebase. Generated applications need no additional coding to run, although in most situations custom checks should be added via extension-points present in the generated codebase.

Jiffy applications provide the following features:

  • Generated applications can be connected to Postgres, MSSQL, SAP Hana, SQLite or MariaDB
  • No database specific code is compiled into the binary; an app can be pointed from SQLite to SAP Hana with no code changes
  • Login / authorization management via JWT
  • Built-in support for the creation of signing-keys for JWT (RS256, RS384, RS512, ES256, ES384, ES512)
  • Support for JWT’s created by other IDP’s (RS256, RS384, RS512, ES256, ES384, ES512)
  • Bcrypt salt/pepper based authentication scheme (passwords are never stored in the db)
  • JSON configuration (model) file(s) for Entity, Index, Foreign-Key and Relationship definitions
  • Models support persistent and non-persistent fields
  • Generated apps create and alter database artifacts based on the model file (tables, indices, sequences etc.)
  • Support for single and composite index declarations via the model file
  • Built-in support for https
  • Built-in normalization and validation in the model-layer
  • Each entity’s corresponding service can be enabled and disabled on a per-app-server (process) basis based on config
  • Generates a working set of CRUD-type RESTful services for each entity in the model file
  • Get/set type end-points support \$count, \$limit=n, \$offset=n, \$orderby=field_name (\$asc|\$desc)
  • Supports and generates working end-points for hasOne, hasMany and belongsTo entity relationships
  • Generates static query end-points
  • End-points are secured by way of scope inspection (JWT claims) in the route handler middleware
  • End-point security is generated by default via a auths -> auth-groups -> user arrangement
  • Generates a comprehensive set of working tests (go test)
  • Generated code is easily extended either via direct editing, or through an extension-point concept in the model and controller-layers
  • A leader-election-based group-membership service exists between running instances of the application to facilitate internal caching of user ACL and session information across nodes
  • Jiffy applications are designed for bare-metal, VM, containerized and managed container deployment (Kubernetes)

How does Jiffy interface to the underlying database?

Jiffy sits on top of a thin ORM that was written to talk to the SAP Hana in-memory db and then extended to the other supported DBMS systems. The ORM code is very simple and can easily be extended to support other databases. Bear in mind that the generated queries are designed to accommodate the lowest-common-denominator-type CRUD access. It is expected that a serious deployment will involve extending the generated codebase to optimize access in certain scenarios.

ORM’s sound like a bad idea to a lot of people. That being said, as soon as one wishes to support more than one type of backend DBMS, a level of abstraction (like a thin ORM) starts to look a bit more appealing. However…

If you look at the generated code and don’t like what you see, the ORM handle exposes the standard go/sql and the awesome jmoiron/sqlx libraries to the developer. The generated ORM code can simply be replaced with hand-coded SQL.