twinlogix / typetta Goto Github PK

View Code? Open in Web Editor NEW

101.0 3.0 4.0 10.7 MB

Node.js ORM written in TypeScript for type lovers.

Home Page: https://twinlogix.github.io/typetta/

License: Apache License 2.0

TypeScript 99.89% Shell 0.01% JavaScript 0.10%

nodejs javascript typescript orm graphql mongodb mysql sqlserver sqllite3 sql

typetta's Introduction

Node.js ORM written in TypeScript for type lovers.

.

Docs - Examples

Typetta is an open-source ORM written in TypeScript that aims to allow seamless access to data in a typed fashion to all main SQL databases (MySQL, PostgreSQL, Microsoft SQL Server, SQLLite3, CockroachDB, MariaDB, Oracle e Amazon Redshift) and also to the NoSQL database MongoDB.

Typetta is pluggable into any TypeScript backend (including serverless applications and microservices) but in terms of gain we totally suggest using it in all GraphQL backends, because... because we simply love GraphQL.

How do I use Typetta?

With Typetta everything revolves around the data model, the entities that describe the application domain and all underlying relationships between them. This model is described in standard GraphQL, using all basic concepts (scalars, types, enumerations, etc...) and some custom directives.

Starting from the model output of the domain analysis, Typetta provides a range of code generators for:

Type definitions in TypeScript language for each entity in the model.
Data Access Object (aka DAO) for each entity type that has a corresponding data source. Each DAO is an object that the developer can also query with advanced CRUD operations.
An Entity Manager where the developer can configure each data source and retrieve the reference of any DAO.
A completely auto-generated GraphQL Endpoint with advanced CRUD operations to access and modify data.

Main Functionalities

Below is a brief description of what makes Typetta awesome:

Complete support of main SQL databases and also MongoDB.
Multiple databases, including the ability to cross query different databases.
Multiple connections and connection pooling.
Entity relationships: 1-1, 1-n, n-m.
Dynamic typing and corresponding data projections.
Pagination.
Can be extended using middlewares.
Customised scalars and serialisation of the database.
Autogenerated IDs.
Validation rules.
Virtual, computed and calculated fields.
Aggregation queries.
Ability to build custom queries.
Define data access security policies.
Embedded documents supported on MongoDB as well as SQL.
Automated code generation.
Effortless integration with GraphQL backends.
Optional automated GraphQL Endpoint generation for CRUD operations.
Transactions.
Logging.
Mocking.
Auditing.
Multi-tenancy partitioning.
Soft-delete.

Why Typetta?

Typetta fulfills the need of having a typed ORM connected to SQL and NoSQL databases designed with productivity and flexibility in mind.

The philosophy behind Typetta components has been to ensure ease of use and optimisation of development time, adding complexity (with direct access to data source) only when strictly needed.

In case you are still unsure, why use Typetta instead of other ORMs?

It's the ONLY TypeScript ORM that has full support for SQL and MongoDB databases.
A very strict typing system that 100% leverages TypeScript in providing types as responses based on the requested data type.
Using standard GraphQL as data modeling language opens the door to a whole set of instruments and third party tools.

typetta's People

Contributors

Stargazers

Watchers

Forkers

edobrb lorefnon atlinx fusiongalaxy

typetta's Issues

Transform the project structure with npm workspaces.

This could be necessary to add some other deliverables in the same project. We can also already separate typetta from typetta-generator.

Investigate and possibly add a caching functionality

We can take inspiration from https://typeorm.io/#/caching

GraphQL inheritance support

Change entity definition syntax from @mongoEntity and @sqlEntity to @entity @mongodb or @entity @sql

NB: in case the user only specifies @entity directives, the system allow generation and the DAO can only be used in a mock: true mode.

Related to #78

Check ArrayOperators support in MongoDB and evaluate how to support them in SQL.

GIve the possibility to specify required fields that are reference

type User @mongoEntity {
  id: ID! @id
  friendId: ID!
  friend: User! @innerRef
}

Add sorts to findOne

Add `maxDepth` param into find operations

maxDepth: 0 -> relations are disabled
maxDepth: 1 -> only relations attached to the main entity
maxDepth: n -> ...

Add also a default value as the limit (pageSize)

Support @id composed by more than one field

The generation error given when @id is missing refers to a @mongodb entity even if only @entity is specified in the model.

Support deletion paranoid mode

In paranoid mode all deletions are logic, done by setting a deletedAt date field and every other API should automatically filter for records with deletedAt null.

API `findOne` supports sorting

https://twinlogix.github.io/typetta/chapters/client/sorting

Add the ability to filter an entity based on a condition of a relation.

There should be the possibility to add a condition that returns a record only if some/every/none of its related entities satisfy another given condition.

Add validation system for single field of and entity

Add validate directives`:

type User @mongoEntity {
  email: String! @validate(logic: "email")
}

The validation logic 'email' is implemented in the specific DAOContext.

Add some ready to use validation logics and it's specific directive. Example:

type User @mongoEntity {
  email: String! @email
  views: Int! @positive
}

Create ESLint custom rules to check Typetta syntax.

`start` was renamed in `skip` in pagination

https://twinlogix.github.io/typetta/chapters/client/pagination

Transactions: evaluate the possibility to add a transaction function.

Sometimes a transaction function that wraps all the operations can be easy to use than passing a transaction reference to all the operations. Both options have pros and cons.

Following an example:

const trx = await knexInstance.transaction({ isolationLevel: 'snapshot' })
try {
     await dao.transaction(trx, () => {
         const user = await dao.user.findOne({ 
              filter: { id: '1fc70958-b791-4855-bbb3-d7b02b22b39e' },
              projection: { id: true, balance: true }
          )
          await dao.user.updateOne({ 
              filter: { id: user.id },
              changes: { balance: user.balance + 10 }
          });
      );
      await trx.commit()
} catch(e) {
     await trx.rollback()
}

Change name from computed fields to virtual fields.

Virtual fields sounds better.

Evaluate and possibly add a relation integrity management for both SQL (database support) and MongoDB (applicative support)

Add support for update operator

Like $push, $unset, ecc...

Generating from a model with no entities the generated file has compilation errors.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

chore(deps): update dependency tzinfo to v2

Detected dependencies

bundler

docs/Gemfile

github-pages ">= 228"

jekyll-feed "~> 0.6"

tzinfo "~> 1.2", ">= 1.2.10"

tzinfo-data undefined

wdm "~> 0.1.0"

kramdown-parser-gfm undefined

github-actions

.github/workflows/build-and-test.yml

actions/checkout v3

actions/setup-node v3

.github/workflows/codeql-analysis.yml

actions/checkout v3

github/codeql-action v1

github/codeql-action v1

github/codeql-action v1

html

docs/_layouts/default.html

html5shiv 3.7.3

npm

package.json

@graphql-codegen/add 3.2.3

@graphql-codegen/cli 2.16.5

@graphql-codegen/plugin-helpers 3.1.2

@graphql-codegen/schema-ast 2.6.1

@graphql-codegen/typescript 2.8.8

@graphql-codegen/typescript-resolvers 2.7.13

@graphql-codegen/visitor-plugin-common 2.13.8

chalk 4.1.2

commander 9.5.0

dataloader 2.2.2

dedent 0.7.0

graphql 16.8.1

graphql-tag 2.12.6

inquirer 8.2.6

is-plain-object 5.0.0

lodash 4.17.21

object-hash 2.2.0

prettier 3.0.3

type-fest 2.19.0

yaml 2.3.3

uuid 8.3.2

@trivago/prettier-plugin-sort-imports 4.2.0

@types/dedent 0.7.0

@types/inquirer 8.2.6

@types/jest 27.5.2

@types/lodash 4.14.195

@types/node 18.18.5

@types/object-hash 2.2.1

@types/sha256 0.2.0

@types/uuid 8.3.4

@typescript-eslint/eslint-plugin 5.62.0

@typescript-eslint/parser 5.62.0

@apollo/server 4.9.3

bignumber.js 9.1.1

eslint 8.51.0

jest 27.5.1

make-coverage-badge 1.2.0

mongodb-memory-server 8.13.0

prettier 3.0.3

release-it 15.11.0

rimraf 3.0.2

sha256 0.2.0

ts-jest 27.1.5

typedoc 0.24.8

typescript 4.9.5

sqlite3 5.1.4

knex 2.5.1

mongodb 5.8.0

redis 4.6.7

node >=12.6

pnpm >=6.14.1

graphql 16.8.1

Check this box to trigger a request for Renovate to run again on this repository

`tenantSecurityPolicy` does not limit aggregate

Documentation first version.

Investigate and possibly add the ability to manage multi-tenancy

We can take inspiration from Hibernate multi-tenancy support described here https://www.baeldung.com/hibernate-5-multitenancy

Rename AggregatePostProcessing param "sort" in "sorts" to be coherent to FindParams.

Fix geopoint scalar

Currently not working on MongoDB and SQL

Add raw update support

Like RawFilter and RawSort it would be nice to support RawUpdate.
Related to #15.

Moving from TSLint to ESLint.

TSLint is now deprecated.

Database introspection and GraphQL automatic generation

Fix $text filter condition and evaluate how to support it on SQL databases.

Proposal:

add a $contains, $startsWith, $endsWith conditions that will be translated in some regex in MongoDB and in some LIKE in SQL.
add a $search condition only for MongoDB DAO (there's no support for full text search in every SQL dbs)

Consider to rename 'start' param in 'skip'

skip is more clear than start (no ambiguity about 0-based or 1-based)
with cursor based pagination start does not make sense, skip it does

Improvements to scalar adapters typing.

Every scalar adapter should be optional, even for custom scalars. The default should be an identityAdapter.
When a user define a scalar adapter he should have the ability set only a part of the adapter and other methods fallback to identityAdapter.
Exactly as datasources, scalar adapters should have mongo/sql params only if the the DAOContext has mongo/sql data sources. When there's no entity with a driver the DAOContext should not receive configurations for that driver.
If the ID scalar is configured to be generated by the user, its scalar adapter should be required and the generate method should be also required.

Mocking functionality

Adding the ability to have a mocked DAOContext where no driver is specified and, by default, the only data source is sqlite in memory database (the user doesn't need to create and pass it to init).

This inmemory database is created if the user pass an explicit mock: true parameter to the DAOContext.

Migrations

As a first step of a migration tool we can evaluate the introduction of an explicit migration mechanism, where the user write itself the up/down methods of the migration using the driver directly anche the framework only applies the in a secure way.

A second step could be the one where the platform infers the migration from the model, but it requires a strict connection between model and database schema (introspection/generation).

Investigate and check DocumentDB compatibility.

Add a logging strategy

Monitoring and alerts

Design a monitoring and alerts management with the ability to:

trace slowest operations, most time consuming operations, most invoked operations, ecc
show configurable metrics of data access
add alerts with configurable thresholds

Add an option for clearer `ModelProjection` return

Now ModelProjection utility type return alway an object with the concatenation of the projection (& { __projection: P }). This is useful for a better type checking but it obfuscates the return type of find operations.

Proposal:
add disableProjectionReturn settings in the codegen.yml (default as false) that disable this behaviour.

disableProjectionReturn: false

disableProjectionReturn: true

const server = new ApolloServer({ 
  schema: application.createSchemaForApollo(),
  context: () => {
    return {
      dao: mockedDAOContext()
    }
  }
});

this gives error and

const server = new ApolloServer({ 
  schema: application.createSchemaForApollo(),
  context: () => {
    return {
      dao: mockedDAOContext({})
    }
  }
});

and this it doesn't.