What is AWS AppSync and what are its top alternatives?
Top Alternatives to AWS AppSync
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. ...
Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds. ...
- AWS Mobile Hub
AWS Mobile Hub is the fastest way to build mobile apps powered by AWS. It lets you easily add and configure features for your apps, including user authentication, data storage, backend logic, push notifications, content delivery, and analytics. After you build your app, AWS Mobile Hub gives you easy access to testing on real devices, as well as analytics dashboards to track usage of your app – all from a single, integrated console. ...
- AWS Amplify
The Realm Mobile Platform is a next-generation data layer for applications. Realm is reactive, concurrent, and lightweight, allowing you to work with live, native objects. ...
- Firebase Realtime Database
It is a cloud-hosted NoSQL database that lets you store and sync data between your users in realtime. Data is synced across all clients in realtime, and remains available when your app goes offline. ...
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. ...
An open source GraphQL engine that deploys instant, realtime GraphQL APIs on any Postgres database. ...
AWS AppSync alternatives & related posts
- Type-safe database access10
- Open Source9
- Auto-generated query builder8
- Increases confidence during development6
- Supports multible database systems5
- Built specifically for Postgres and TypeScript4
- Productive application development4
- Supports multible RDBMSs1
- Robust migrations system0
- Doesn't support downward/back migrations1
related Prisma posts
I just finished a web app meant for a business that offers training programs for certain professional courses. I chose this stack to test out my skills in graphql and react. I used Node.js , GraphQL , MySQL for the #Backend utilizing Prisma as a database interface for MySQL to provide CRUD APIs and graphql-yoga as a server. For the #frontend I chose React, styled-components for styling, Next.js for routing and SSR and Apollo for data management. I really liked the outcome and I will definitely use this stack in future projects.
In my last side project, I built a web posting application that has similar features as Facebook and hosted on Heroku. The user can register an account, create posts, upload images and share with others. I took an advantage of graphql-subscriptions to handle realtime notifications in the comments section. Currently, I'm at the last stage of styling and building layouts.
For the #Backend I used graphql-yoga, Prisma, GraphQL with PostgreSQL database. For the #FrontEnd: React, styled-components with Apollo. The app is hosted on Heroku.
- Realtime backend made easy367
- Fast and responsive268
- Easy setup239
- Backed by google126
- Angular adaptor82
- Great customer support35
- Great documentation30
- Real-time synchronization25
- Mobile friendly21
- Rapid prototyping18
- Great security14
- Automatic scaling12
- Freakingly awesome11
- Angularfire is an amazing addition!8
- Super fast development8
- Ios adaptor6
- Firebase hosting6
- Awesome next-gen backend6
- Built in user auth/oauth6
- Speed of light4
- Very easy to use4
- Brilliant for startups3
- It's made development super fast3
- Low battery consumption2
- Free hosting2
- Cloud functions2
- Push notification2
- JS Offline and Sync suport2
- Free authentication solution2
- The concurrent updates create a great experience2
- I can quickly create static web apps with no backend2
- Great all-round functionality2
- Easy Reactjs integration1
- Easy to use1
- Free SSL1
- CDN & cache out of the box1
- Faster workflow1
- Google's support1
- Good Free Limits1
- Can become expensive31
- No open source, you depend on external company15
- Scalability is not infinite15
- Not Flexible Enough9
- Cant filter queries6
- No Relational Data3
- Very unstable server3
- No offline sync2
- Too many errors2
related Firebase posts
This is my stack in Application & Data
My Utilities Tools
Google Analytics Postman Elasticsearch
My Devops Tools
Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack
My Business Tools
related AWS Mobile Hub posts
- Better with Relations and Security3
- Flexible Auth options2
- Continuous deployment1
- Backed by Amazon1
- Free tier is limited2
- Steep Learning Curve1
related AWS Amplify posts
I am currently working on a long term mobile app project. Current stack: Frontend: Dart/Flutter Backend: Go, AWS Resources (AWS Lambda, Amazon DynamoDB, etc.) Since there are only two developers and we have limited time and resources, we are looking for a BAAS like Firebase or AWS Amplify to handle auth and push notifications for now. We are prioritizing developing speed so we can iterate quickly. The only problem is that AWS amplify support for flutter is in developer preview and has limited capabilities (We have tested it out in our app). Firebase is the more mature option. It has great support for flutter and has more than we need for auth, notifications, etc. My question is that, if we choose firebase, we would be stuck with using two different cloud providers. Is this bad, or is this even a problem? I am willing to change anything on the backend architecture wise, so any suggestions would be greatly appreciated as I am somewhat unfamiliar with Google Cloud Platform. Thank you.
- Elegant API3
- Cloud Syncing3
- React Native Support2
- Strong Adoption Growth1
- No offline support for web till now1
related Realm posts
- Very fast5
- Poor query1
related Firebase Realtime Database posts
We are building a social media app, where users will post images, like their post, and make friends based on their interest. We are currently using Cloud Firestore and Firebase Realtime Database. We are looking for another database like Amazon DynamoDB; how much this decision can be efficient in terms of pricing and overhead?
- From the creators of Meteor12
- Great documentation3
- Real time if use subscription2
- Open source1
related Apollo posts
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.
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.
- Easy GraphQL subscriptions16
- Easy setup of relationships and permissions15
- Automatically generates your GraphQL schema14
- Minimal learning curve14
- No back-end code required12
- Works with new and existing databases12
- Instant production ready GraphQL11
- Great UX10
- Low usage of resources2
- Cumbersome validations2