- Photon
- Can I still access my database directly (e.g. using raw SQL)?
- Is Photon.js an ORM?
- Will Photon.js support more databases (and other data sources) in the future?
- How can I see the generated queries that Photon.js sends to my database?
- How do schema migrations work with Photon.js?
- Is Photon.js production-ready? Should I start using it?
- Does Photon.js support GraphQL schema delegation and GraphQL binding?
- How to handle connection pooling for Photon.js in serverless environments?
- Lift
- Other
While it's currently not possible to use Photon.js to directly access your database, this feature has a priority on our list and is one of the first things we are working on during the Preview period. You can track the progress of this feature here.
In the meanwhile, you can use Photon.js alongside other lightweight query builders such as knex.
ORMs are typically object-oriented mapping layers that map classes to tables. A record is represented as an object that not only carries data but also implements various behaviors for storage, retrieval, serialization and deserialization of its own data, sometimes it also implements business/domain logic. Photon.js acts more as a query builder returning plain objects with a focus on structural typing rather than rich object behavior.
Yes. Photon.js is based on Prisma's query engine that can connect to any data source that provides a proper connector implementation. There will be built-in connectors such as the current ones for PostgreSQL, MySQL and SQLite.
However, it's also possible to build your own connectors, more documentation on that topic will follow soon.
There will be rich query analytics for Photon.js soon. For now you can set the debug option to true when instantiating your Photon instance. Learn more in the docs.
Photon.js is not opinionated on how exactly you migrate your database schema. You can keep your existing migration system and re-introspect your database schema after each migration to update Photon. Learn more in the docs. You can also always use Lift to perform your migrations based on Prisma's declarative data model definition.
Photon.js is not yet production-ready, it has a number of severe limitations that don't make it suitable for production uses and heavy loads. You can track the progress of the release process on isprisma2ready.com. While it shouldn't be used for critical applications yet, Photon.js is definitely in a usable state. You can help us accelerate the release process by using it and sharing your feedback with us.
GraphQL schema delegation connects two GraphQL schemas by passing the info object from a resolver of the first GraphQL schema to a resolver of the second GraphQL schema. Schema delegation also is the foundation for GraphQL binding.
Prisma 1 officially supports both schema delegation and GraphQL binding as it exposes a GraphQL CRUD API through the Prisma server. This API can be used to as foundation for an application-layer GraphQL API created with GraphQL binding.
With Prisma 2, Prisma's query engine doesn't expose a spec-compliant GraphQL endpoint any more, so usage of schema delegation and GraphQL binding with Prisma 2 is not officially supported. To build GraphQL servers with Prisma 2, be sure to check out GraphQL Nexus and its nexus-prisma integration. GraphQL Nexus provides a code-first and type-safe way to build GraphQL servers in a scalable way.
The query engine that's powering the Photon.js API is maintaining a database connection pool. In serverless environments (or when running your application in containers, e.g. using Kubernetes), this connection pool might loose its effectiveness due to the infrastructure it's being deployed on. You can read more about this topic in the docs.
As of now, the recommended workaround is to use a tool like PgBouncer. We are further exploring some options, such as enabling a "DB proxy server" (e.g. using a specific generator that generates a Docker image to host Photon's query engine) that manages the connection pool for you (similar to the the Prisma 1 architecture).
Also note that there some cloud offerings start to have solutions for connection pooling out-of-the-box, such as AWS Aurora.
There's absolutely no lock-in with Lift. To stop using Lift, you can delete your Prisma schema file, all existing migration folders on your file system and the migrations table in your database/schema.
Each migration is represented via its own directory on your file system. The name of each directory contains a timestamp so that the order of all migrations in the project history can be maintained. Each of these migration directories contains detailed information about the respective migration, for example which steps are executed (and in what order) as well as a human-friendly markdown file that summarizes the most important information about the migration, such as the source and the target data model definition of the migration. This information can also be found in the migrations table in your database/schema.
Also, the lift CLI constantly prints the migration statements and more information when you're running its commands.
Lift is not yet production-ready, it has a number of severe limitations that don't make it suitable for production uses. You can track the progress of the release process on isprisma2ready.com.
While it shouldn't be used for critical applications yet, Lift is definitely in a usable state. You can help us accelerate the release process by using it and sharing your feedback with us.
Yes, Prisma 1 will continue to be maintained. However, most Prisma engineering resources will go into the development of Prisma 2 (i.e. Photon and Lift).
There will be no new features developed for Prisma 1.
Check out the specs repo which contains the technical specifications for future Prisma 2 features. Get involved by creating issues and sharing feedback!