Jiffy is a model-based RESTful application services generator written in Go. It was developed as an experiment to offer an alternative avenue when developing native applications for SAP Hana, but also works nicely with Postgres, MariaDB, SQLite and MSSQL. The jiffy application allows a developer to treat the data persistence layer as an abstraction, thereby allowing retargeting of the backend db system without the need to recompile.
See https://1414c.github.io/jiffy for current documentation.
- Update for modules support
- Send a DEPARTING message to the group when a SIGKILL, SIGTERM or os.Interrupt is detected
- Add CDeparting Message Type constant
- Add CinFlushMemberMap channel command constant
- Add CStatusDeparted process status constant
- Add CerrMemberMapFlushFailed error constant
- Add DeleteByIndex(...) to OrderedMapI interface
- Add Flush() method to OrderedMapI interface and add implementation to OMap
- Add UpdFailedDepartedProcesses() to OrderedMapI interface and add implementation to OMap
- Add SendDeparting(...) method
- Add Self-ping network up/down check + Join in TxRxGMMessage(...)
- Add automatic JWT renewal option. If the parameter is set (in minutes), any access that occurs between expiry-time - renewal time will result in the issuance of a new JWT. Renewed JWT's will have to be regenerated based on the latest auth information in the buffers.
- Switch to https://github.com/jackc/pgx for postgres support.
- Add support for relationships (or the suspension of them) in the generated jiffy test-suites.
- Address logging(?)
- consider FAQ for calling db functions
- create a few runnable examples in Docker containers
- create an environment service
- create a $metadata service
- update docs to better explain end-point functions
- examine initial startup / auth cache
- generated apps 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 / session management via jwt
- built-in support for the creation of signing-keys for jwt
- configurable jwt expiry (exp claim)
- bcrypt salt/pepper based authentication scheme where passwords are never stored in the db
- JSON configuration (model) file(s) for Entity, Index and Relationship definitions
- models support persistent and non-persistent fields
- automatically creates backend database artifacts based on the model file (tables, indices, sequences etc.)
- supports 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 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 working static query end-points based on the model file
- 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 information