Regardless of protocol/software used, I think it could still be called an answer to Firebase, since AppSync and Firebase are both "backend-as-a-service" systems with realtime updates, useful for rapid app development.
That’s an architectural difference. Firebase predates graphql. I think the idea is at a high level they both target the same type of customer and use case, i.e. rapid development. No?
That’s not the problem GraphQL was invented to solve AFAIK. Subscriptions were added to graphql later. As I understand it graphql was created to abstract various api endpoints and tie the nodes together with resolvers so that queries would be more efficient. Firebase is a real-time db. When you hit it you hit a single endpoint. That’s very different. I can’t imagine anyone well versed in graphql and Firebase and their histories conflating the two but yet my other comments to this are getting downvoted.
From the outside, it would appear that AppSync's main goal is to provide a realtime data/sync solution, and that their choice to use GraphQL was likely a design decision rather than the entire reason for AppSync's existence.
Of course, I say this as an outsider, not familiar with the details of the project, and having only read what's on the AppSync website. If AppSync really does exist solely to deliver GraphQL to the world, hopefully you can understand how this might not be apparent to other HN commentors.
Anyway just trying to explain how there could be confusion, after reading a bunch of the comments on here.
Yeah, that’s still just an architectural difference. Nobody is conflating graphql and Firebase. It’s AppSync and Firebase. AppSync gives you more flexibility with the back end thanks in part to graphql, which is cool, but for most people it’s in the same “rapid development” solution category as Firebase.
You can wire up DynomoDB and Lambda functions for the backend and expose them with a single API. This is so cool. It is lacking RDS though, a deal-breaker for me.
I wonder why most companies building simple CRUD apps still don't use those services (AppSync, Firebase, Graphcool, etc)? Seems like cheaper than hiring a backend developer + a devops.
ah, thanks, that's what i wanted to ask. Since it's MQTT, how does it support iOS when the app is in the background? or it won't support that scenario on iOS? On Android, does it also use MQTT to maintain a connection? instead of using FCM/GCM? On the browser, how's the MQTT connection maintained? does it have service worker support for "offline" use cases?
I haven’t been able to ascertain that from the docs. There could be different transports for web and iOS. All I know is web uses MQTT over web sockets and the Apollo library is used for offline and cache support.
Thanks for the response. I should have been more specific, what's AppSync's mechanism for push notification for the 3 platforms: FCM (GCM?) for Android? APNs for iOS? HTML5 Push API for browsers?
There are other services that do push notifications - most notably, Amazon Pinpoint (for the analytics driven type user segmentation and campaigns) and SNS (for the more automated single push).
Similarly, look to Amazon Cognito for user sign-in / sign-up / etc., AWS Lambda and API Gateway for cloud-based API, and other services for machine-learnign, AI, chatbots, database services, analytics, etc.
AWS AppSync is only for the data access / offline / real-time component.
Seems like another way to lock you into a proprietary cloud (Firebase or AWS backend).
Why not just take a client side library and an open-source backend, and host it on EC2 or some general purpose computer server hosted anywhere? This way your CLIENTS have a choice too.
Having used graph.cool I can say there's a significant amount of lock-in. Authorization can be pretty specific to the implementation and often impacts your schema. Secondly the extensions that have a lot of the logic are implemented differently every time. AppSync uses Apache Velocity Template Language (VTL), seems like a huge lock-in there. Don't be fooled by the GraphQL sticker, there's a significant amount of lock-in if you go with any of the SaaS(BaaS) products.
I avoid EC2 instances as much as possible. If you are just using a cloud provider to host your VMs, you’re really not taking advantage of “being in the cloud”.
As far as lock in, it’s just like “providing a facade over your database access so you. n change databases. Few people ever change database backends.
48 comments
[ 2.7 ms ] story [ 106 ms ] threadI'm just saying AWS bought Scaphold to deliver a BaaS alternative to Firebase...
This has been out for a few months now. Any experiences with it?
So far it's amazing.
It leverages Apollo for offline/GraphQL capabilities and Apache VTL to bind resources.
It also integrates really nicely with AWS Amplify.
One thing that was a bit of an annoyance was access levels.
You can authenticate with the GraphQL api using a Key, IAM or Cognito JWT
Key is for development only.
IAM does not expose Cognito Groups to VTL
JWT requires an active session.
So we had to create a "fake" account for non-signed in access.
Use case being, a "guest" can read data from the API but only "admins" can write data to the API
AppSync is very different from Firebase but not that different from the other graphql-as-a-service companies.
Of course, I say this as an outsider, not familiar with the details of the project, and having only read what's on the AppSync website. If AppSync really does exist solely to deliver GraphQL to the world, hopefully you can understand how this might not be apparent to other HN commentors.
Anyway just trying to explain how there could be confusion, after reading a bunch of the comments on here.
Is this using AWS IoT?
I don’t know.
I don't know, but when using AWS, SNS is the push based solution.
Similarly, look to Amazon Cognito for user sign-in / sign-up / etc., AWS Lambda and API Gateway for cloud-based API, and other services for machine-learnign, AI, chatbots, database services, analytics, etc.
AWS AppSync is only for the data access / offline / real-time component.
Why not just take a client side library and an open-source backend, and host it on EC2 or some general purpose computer server hosted anywhere? This way your CLIENTS have a choice too.
If you can install Wordpress why not this?
SAFE network will solve all this soon.
[1] https://github.com/daptin/daptin
[2] https://github.com/daptin/daptin/pull/28
As far as lock in, it’s just like “providing a facade over your database access so you. n change databases. Few people ever change database backends.