Alternatives to Prisma logo

Alternatives to Prisma

AWS AppSync, Apollo, Hasura, Sequelize, and TypeORM are the most popular alternatives and competitors to Prisma.
1.2K
955
+ 1
54

What is Prisma and what are its top alternatives?

Prisma is an open-source database toolkit. It replaces traditional ORMs and makes database access easy with an auto-generated query builder for TypeScript & Node.js.
Prisma is a tool in the Object Relational Mapper (ORM) category of a tech stack.
Prisma is an open source tool with 39.9K GitHub stars and 1.6K GitHub forks. Here’s a link to Prisma's open source repository on GitHub

Top Alternatives to Prisma

  • AWS AppSync
    AWS AppSync

    AWS AppSync automatically updates the data in web and mobile applications in real time, and updates data for offline users as soon as they reconnect. AppSync makes it easy to build collaborative mobile and web applications that deliver responsive, collaborative user experiences. ...

  • Apollo
    Apollo

    Build a universal GraphQL API on top of your existing REST APIs, so you can ship new application features fast without waiting on backend changes. ...

  • Hasura
    Hasura

    An open source GraphQL engine that deploys instant, realtime GraphQL APIs on any Postgres database. ...

  • Sequelize
    Sequelize

    Sequelize is a promise-based ORM for Node.js and io.js. It supports the dialects PostgreSQL, MySQL, MariaDB, SQLite and MSSQL and features solid transaction support, relations, read replication and more. ...

  • TypeORM
    TypeORM

    It supports both Active Record and Data Mapper patterns, unlike all other JavaScript ORMs currently in existence, which means you can write high quality, loosely coupled, scalable, maintainable applications the most productive way. ...

  • Zscaler
    Zscaler

    It is a global cloud-based information security company that provides Internet security, web security, firewalls, sandboxing, SSL inspection, antivirus, vulnerability management and granular control of user activity in cloud computing, mobile and Internet of things environments. ...

  • Mongoose
    Mongoose

    Let's face it, writing MongoDB validation, casting and business logic boilerplate is a drag. That's why we wrote Mongoose. Mongoose provides a straight-forward, schema-based solution to modeling your application data and includes built-in type casting, validation, query building, business logic hooks and more, out of the box. ...

  • Dome9
    Dome9

    It delivers full visibility, control and faster time to protection as organizations scale in AWS, Azure and Google Cloud environments. ...

Prisma alternatives & related posts

AWS AppSync logo

AWS AppSync

197
30
A managed GraphQL service with real-time data and offline programming
197
30
PROS OF AWS APPSYNC
  • 9
    GraphQL
  • 6
    Real-Time
  • 3
    Offline
  • 3
    Apollo
  • 2
    Fully managed and scalable GraphQL Resolver!
  • 2
    Backed by Amazon
  • 2
    BaaS
  • 2
    AWS
  • 1
    Enterprise Security
CONS OF AWS APPSYNC
    Be the first to leave a con

    related AWS AppSync posts

    Apollo logo

    Apollo

    2.4K
    25
    GraphQL server for Express, Connect, Hapi, Koa and more
    2.4K
    25
    PROS OF APOLLO
    • 12
      From the creators of Meteor
    • 8
      Great documentation
    • 3
      Open source
    • 2
      Real time if use subscription
    CONS OF APOLLO
    • 1
      File upload is not supported
    • 1
      Increase in complexity of implementing (subscription)

    related Apollo posts

    Nick Rockwell
    SVP, Engineering at Fastly · | 46 upvotes · 4.1M views

    When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

    So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

    React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

    Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

    See more
    Adam Neary

    At Airbnb we use GraphQL Unions for a "Backend-Driven UI." We have built a system where a very dynamic page is constructed based on a query that will return an array of some set of possible “sections.” These sections are responsive and define the UI completely.

    The central file that manages this would be a generated file. Since the list of possible sections is quite large (~50 sections today for Search), it also presumes we have a sane mechanism for lazy-loading components with server rendering, which is a topic for another post. Suffice it to say, we do not need to package all possible sections in a massive bundle to account for everything up front.

    Each section component defines its own query fragment, colocated with the section’s component code. This is the general idea of Backend-Driven UI at Airbnb. It’s used in a number of places, including Search, Trip Planner, Host tools, and various landing pages. We use this as our starting point, and then in the demo show how to (1) make and update to an existing section, and (2) add a new section.

    While building your product, you want to be able to explore your schema, discovering field names and testing out potential queries on live development data. We achieve that today with GraphQL Playground, the work of our friends at #Prisma. The tools come standard with Apollo Server.

    #BackendDrivenUI

    See more
    Hasura logo

    Hasura

    334
    144
    An open source GraphQL engine that deploys instant, realtime GraphQL APIs on any Postgres database.
    334
    144
    PROS OF HASURA
    • 23
      Fast
    • 18
      Easy GraphQL subscriptions
    • 16
      Easy setup of relationships and permissions
    • 15
      Automatically generates your GraphQL schema
    • 15
      Minimal learning curve
    • 13
      No back-end code required
    • 13
      Works with new and existing databases
    • 12
      Instant production ready GraphQL
    • 11
      Great UX
    • 4
      Low usage of resources
    • 4
      Simple
    CONS OF HASURA
    • 3
      Cumbersome validations

    related Hasura posts

    Sequelize logo

    Sequelize

    882
    143
    Easy-to-use multi SQL dialect ORM for Node.js
    882
    143
    PROS OF SEQUELIZE
    • 42
      Good ORM for node.js
    • 31
      Easy setup
    • 21
      Support MySQL & MariaDB, PostgreSQL, MSSQL, Sqlite
    • 14
      Open source
    • 13
      Free
    • 12
      Promise Based
    • 4
      Recommend for mongoose users
    • 3
      Typescript
    • 3
      Atrocious documentation, buggy, issues closed by bots
    CONS OF SEQUELIZE
    • 30
      Docs are awful
    • 10
      Relations can be confusing

    related Sequelize posts

    Dieudonné ALLOGNON
    Junior Fullstack Developer · | 5 upvotes · 337.4K views

    Hey! I am actually in internship and have an app to create for my structure. It will be an intern app which will allow crud dashboard actions with some data provided by the use of an API of one of the structure partner and make a correspondence to data contained in a private database. Since it's an intern app, I thought about Electron for a desktop app because I did a lot of web with Laravel and the structure goes more for the desktop app. But it will be my first occasion working with this tech.

    Is Electron a good choice? Wich ORM should be more complete and adapted to this between Sequelize and TypeORM? (Database will be MySQL) Some charts will be displayed in the app. Is there a library (preferably without jQuery) that suits this stack?

    Thank you !

    See more
    Max Musing
    Founder & CEO at BaseDash · | 5 upvotes · 101.8K views

    Node.js is a great option for real-time applications, especially in conjunction with Socket.IO.

    In terms of databases, I'd go with PostgreSQL. MongoDB has its benefits (schema-less, sharding, map-reduce), but for most CRUD-based apps, it makes sense to store the bulk of your data in a relational database (of which PostgreSQL is the best IMO). You can throw in MongoDB if you have a specific need for it. There's certainly no need to use both MySQL and PostgreSQL.

    As for GraphQL, it can be nice to work with since you don't need to predefine specific data endpoints on your backend, instead shifting the power to your frontend in requesting the data it needs. It's also useful for public APIs, when you don't know what data users want (see Github's API). It can be useful at the early stage when you're prototyping and want to be able to fetch data quickly, but certainly isn't necessary.

    At BaseDash we use Node.js, ExpressJS, Socket.IO, PostgreSQL, and Sequelize to fit our use case of database management and real-time operations.

    See more
    TypeORM logo

    TypeORM

    601
    81
    An ORM that can run in NodeJS and others
    601
    81
    PROS OF TYPEORM
    • 30
      Typescript
    • 12
      Supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Ser
    • 9
      Easy setup
    • 9
      Cons of TypeORM
    • 7
      Promise Based
    • 7
      Works in NodeJS, Browser, Ionic, Cordova and Electron p
    • 6
      Support MySQL & MariaDB, PostgreSQL, MSSQL, Sqlite
    • 1
      Support MongoDB
    CONS OF TYPEORM
    • 5
      Completely abandoned by its creator
    • 3
      Too complex for what it does
    • 2
      Doesn't really support native javascript
    • 1
      Not proper/real type safety
    • 1
      Cannot use query on any relation

    related TypeORM posts

    Simon Reymann
    Senior Fullstack Developer at QUANTUSflow Software GmbH · | 27 upvotes · 5.1M views

    Our whole Node.js backend stack consists of the following tools:

    • Lerna as a tool for multi package and multi repository management
    • npm as package manager
    • NestJS as Node.js framework
    • TypeScript as programming language
    • ExpressJS as web server
    • Swagger UI for visualizing and interacting with the API’s resources
    • Postman as a tool for API development
    • TypeORM as object relational mapping layer
    • JSON Web Token for access token management

    The main reason we have chosen Node.js over PHP is related to the following artifacts:

    • Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
    • Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
    • A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
    • Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
    See more
    Martin Johannesson
    Senior Software Developer at IT Minds · | 14 upvotes · 2.9M views

    At IT Minds we create customized internal or #B2B web and mobile apps. I have a go to stack that I pitch to our customers consisting of 3 core areas. 1) A data core #backend . 2) A micro #serverless #backend. 3) A user client #frontend.

    For the Data Core I create a backend using TypeScript Node.js and with TypeORM connecting to a PostgreSQL Exposing an action based api with Apollo GraphQL

    For the micro serverless backend, which purpose is verification for authentication, autorization, logins and the likes. It is created with Next.js api pages. Using MongoDB to store essential information, caching etc.

    Finally the frontend is built with React using Next.js , TypeScript and @Apollo. We create the frontend as a PWA and have a AMP landing page by default.

    See more
    Zscaler logo

    Zscaler

    39
    0
    Secure, simplify and transform IT with cloud security platform
    39
    0
    PROS OF ZSCALER
      Be the first to leave a pro
      CONS OF ZSCALER
        Be the first to leave a con

        related Zscaler posts

        Mongoose logo

        Mongoose

        2.1K
        56
        MongoDB object modeling designed to work in an asynchronous environment
        2.1K
        56
        PROS OF MONGOOSE
        • 17
          Several bad ideas mixed together
        • 17
          Well documented
        • 10
          JSON
        • 8
          Actually terrible documentation
        • 2
          Recommended and used by Valve. See steamworks docs
        • 1
          Can be used with passportjs for oauth
        • 1
          Yeah
        CONS OF MONGOOSE
        • 3
          Model middleware/hooks are not user friendly

        related Mongoose posts

        Repost

        Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

        Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

        Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

        Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

        See more

        REST API for SaaS application

        I'm currently developing an Azure Functions REST API with TypeScript, tsoa, Mongoose, and Typegoose that contains simple CRUD activities. It does the job and has type-safety as well as the ability to generate OpenAPI specs for me.

        However, as the app scales up, there are more duplicated codes (for similar operations - like CRUD in each different model). It's also becoming more complex because I need to implement a multi-tenancy SaaS for both the API and the database.

        So I chose to implement a repository pattern, and I have a "feeling" that .NET and C# will make development easier because, unlike TypeScript, it includes native support for Dependency Injection and great things like LINQ.

        It wouldn't take much effort to migrate because I can easily translate interfaces and basic CRUD operations to C#. So, I'm looking for advice on whether it's worth converting from TypeScript to.NET.

        See more
        Dome9 logo

        Dome9

        10
        0
        Secure Your Cloud with Confidence
        10
        0
        PROS OF DOME9
          Be the first to leave a pro
          CONS OF DOME9
            Be the first to leave a con

            related Dome9 posts