Firebase has SQL: Introducing Data Connect
Vložit
- čas přidán 15. 05. 2024
- Learn how you can now use relational data from Postgres Cloud SQL in your client-side applications with a type-safe auto-generated SDK by using Firebase Data Connect.
Sign up for Data Connect → goo.gle/fb-data-connect
Speaker: David East
Watch more:
Check out all the Cloud videos at Google I/O 2024 → goo.gle/io24-cloud-yt
Check out out all the Firebase sessions from Google I/O → goo.gle/io24-firebase-yt
Check out all the Web videos at Google I/O 2024 → goo.gle/io24-web-yt
Subscribe to Firebase → goo.gle/Firebase
#GoogleIO
Products Mentioned: Cloud - Databases - Cloud SQL
Event: Google I/O 2024 - Věda a technologie
I cant wait for fireship take on this
Great release Firebase team you are on 🔥
In love with the new Firebase logo 😍😍
Firebase, you’ve done it again!! 👏👏👏
SO EXCITED!!! Awesome job Firebase team, this is exactly what I felt like I was missing from Firebase.
Well done again David!
🙏🙏🙏
Just here to stay David is awesome
Sounds fantastic. Wake me up when C# is supported.
Firebase, a supabase alternative
Read that joke many times since Fireship made it yesterday.
A hasura alternative...?
@@matthewbeardsley7004 Amplify alternative
A GraphQL alternative
@@cedricol cool
Impressed. Would like to see a price breakdown vs supabase now
Just get Supabase. The price is astronomically different, at least based on what I looked at about 2 months ago. I doubt they've changed, and then you're in vendor lock. I'd run away from Firebase TBH
@@jrhager84 I don't think so I've been using firebase for a product for 4 years and it still has lower monthly cost than Supabase's pricing.
That was true also for a startup that we sold for 6 figures.
I've been waiting for firebase to produce a postgres product for a while now - and have been mulling over how to move to supabase. Now that this is here, I'm much less likely to do so.
Either way, you're vendor locked. Supabase may be OS but all your code is still designed for Supabase so what does it really change?
It's like some weird version of GraphQL
I felt the same way at first. But the SDK generation + typesafety dev loop is so great.
Sounds promising !
This remember me the time Angular migrated to Typscript. GraphQL is no more dead 😅
This looks very interesting
My goodness! Are Google Cloud pricing actually for real? Is this meant for anyone other than fortune 500 companies?
where did you saw the prices?
@@AlmightyPyro on the website in the description
@@AlmightyPyro On the pricing page, it shows there is a 3 month trial and then "Google Cloud" pricing. Which links to the Google Cloud SQL page.
@@jonathonchambers6460 they have a tone of different options. From $20 to $500/ month
You're either very poor, or looking at the wrong instance types. You can rent a SQL instance for a variety of prices. Compute I've gotten as low as like 5$ a month.
The learning curve is a little steep for a beginner like me but I am so excited to try this out
I think you'll find that it you can do quite a lot with just a little knowledge!
Often in engineering stuff looks more complicated than it is once you dive in and get your head around the basics. Good luck!
Does it support GraphQl subscriptions?
Wow now is a strong option i wish have this two years ago 😂 future looks promising
This is going to change the game!
Impressed !!! Love it.
Following a lot of the same patterns as EdgeDB, and I was just wishing there was a BaaS with a database like EdgeDB. Great stuff. Good luck making this competitively priced though
Very interesting. Will it support migration for the underlaying PostgreSQL database in case if you want to move out like in Supabase?
Data Connect works with a Cloud SQL for PostgreSQL database, so you can connect to it using any tool that can talk to Postgres.
this is so amazing
So much bleeding on the edge 😆 awesome stuff firebase
How will this scale compared to the nosql database you have in firebase? Is there going to be a way to move your old firebase db over?
Auto-migration between these different data models is not planned, but you can write a custom migration with the APIs of course. And we do plan to eventually also connect to Firestore, which would make that even easier. firebase.uservoice.com/forums/948424-general/suggestions/48434618-cloud-firestore-datasource
It is a little different than NoSQL - you have a fixed size instance that handles as much traffic as its memory and CPU can handle. Cloud SQL can scale to really massive use cases, but it's not as automatic as you might be used to with e.g. Firestore.
No automatic tools to move between dbs, but this is a request I keep hearing from folks. We'll think about it more.
finally something useful from firebase, maybe i will migrate back to firebase once again
Is there a way to migrate from firestore to data connect?
Love it but would love to see more features in firestore !
AWS amplify has been doing some of these stuff, but seeing them in firebase is real cool
Firebase is literally complete now
love it
One of the reasons that we use SQL instead of NoSQL is transactions and isolation levels but I haven't heard about these futures in your presentation, do we have them or not?
Everything within a single query / mutation is performed inside a transaction, and we'll likely introduce some additional features for transactional mutations in the future.
The price seems very high though!
Impressive! Now firebase is the alternative of supabase
When will this be ready for production with documentation?
What’s the lowest cost cloudsql instance? Are there plans to support generating flutter clients with data connect?
Great question: cloud.google.com/products/calculator?hl=en&dl=CiRkNDc3NmFiYi00YjI4LTRjNjQtOThlOC04NWIzMGY3M2E1MzMQBxokNTdBODYwRTUtQjQ3RC00ODYzLUJBNTItNzEzNUEwQjMzQkU3 So a bit over 9 dollars.
And yes, generating Flutter SDKs is planned - and will be available before/with the public preview later this year. DM me if you want to help me test it earlier :-)
looks awesome! but the main unanswered question for me is: can I use another 3rd party sql tool to read that data? or will be only accessible through a firebase layer request?
Yes you absolutely can. You have full access to the underlying Cloud SQL instance!
Given how Google handled stopping the deep link feature and the current uncertainty surrounding the future of Flutter, Google appears to be an unreliable partner. Therefore, I prefer to use a traditional SQL provider that doesn't require a new way of implementation.
wow 😃
keren 👏
Great 👍
WOAHHHHHH
It supports DML too?
I love the tooling!
Are you going to open source these stuff?
😂😂😂😂😂😂
@@portalteam5832 obviously i was being sarcastic
how does this support for mobile app game development?
This is crazy far out!!
Ok, but do you have a data view where we can view all the data in our sql table?
Or an sql query console, where we can see the results as a table?
You can use SQL Studio in the GCP console to do direct queries on the underlying Cloud SQL database.
Yes since it sounds like there is an underlying SQL instance, it's probably possible to view your data in any SQL client.
@mbleigh but do we have a table UI like Supabase?
@@kanjuicy585 idk supabase, but gcloud SQL doesn't currently. Based on firestore I'd assume they may end up having that kind of tooling, but I don't know for sure particularly in comparison to what other products have
@@kanjuicy585 right now there's a GraphQL playground for executing arbitrary queries and in Cloud SQL console you can execute arbitrary SQL queries. No table explorer right now.
Easy question: for a new project what would be better in terms of scalability and maintenance? SQL or Firestore?
It's hard to say without using it more.
But my guess is firestore may be slightly easier still since you don't need to define backend stuff.
But in terms of maintenance I think SQL will be better. Changing your data generates migrations and since you aren't binding your data model to your views in a denormalized database you don't have to refactor a bunch because you changed how you view your data. Some tasks are also easier, like searching text fields.
In terms of scalability postgres scales for quite a while before you need to denormalize/duplicate/cache some data. I think the scalability arguments people use are over-hyped. I've written dozens of apps for people that never needed denormalization. The few that have, it was very minor things like one field. Granted if you become the next Facebook or something you may need more, but that's a good problem to have, and is something you can add then
One thing I missed is this is backed by cloudsql. So it probably doesn't have automagic for scaling instance size, at least that I know of.
So firestore is probably easiest and best at scaling. There's still a lot of reasons I'd rather use this if it's any good though, which mostly relate to limitations and challenges in firestore. If your database is difficult or annoying to denormalize that's a great reason to use this.
Can I just connect directly to the database when server side?
Yes, you can connect directly to the Cloud SQL database from a server, you can also issue arbitrary GraphQL queries to Data Connect from the server (but clients can only issue predefined queries).
amazing! can we expect data connect inside firebase emulators?
Oh yeah! It already is! I was using the local Data Connect emulator with a local postgres DB before I deployed to prod.
@@DavidEast awesome. emulators are great for e2e testing and local dev iteration
Congrats, Firebase just discovered GraphQL.
What theeeee.....
🤯🤯🤯
Some concepts are similar to SAP CDS
Does Data Connect support realtime functionality? How about optimistic updates to data?
Not yet, but you can vote for realtime capabilities on our roadmap here: firebase.uservoice.com/forums/948424-general/suggestions/48434600-realtime-query-updates
Does it also build documentation?
Not yet, but it's definitely in the realm of possibility to do so. What would be your ideal form of generated documentation?
Now the real question, whats the pricing for this?
During the gated preview it's all free to use. We're really just looking forward for your feedback at this stage.
Cloud SQL has established pricing, although we're adding a free trial period to it.
Data Connect itself will use pay-as-you-go pricing with a *generous* free tier.
Exact details are still being worked out, and will be announced when we go to public preview later this year.
I'm glad that they finally got relational database support, but I don't like the approach using GraphQL. Overall it seems overengineered.
I really hope you'll give it a try and I think you'll see that the dev loop is designed to be simple rather than over-engineered.
I think they chose graphql because it's a flexible way for us to query what we want.
In many ways graphql is great for clients and difficult for the API developer but in this case, firebase is the API developer and we are the client.
But we do define our queries in advance in the backend. They forego the advantage of clients defining whatever query they want to make security easy. Which is a worthwhile trade, by having only certain queries available in advanced it's no more limited than a typical rest API.
is this comming for mysql also?
It's not currently on our roadmap, but I'd encourage you to suggest it here: firebase.uservoice.com/forums/948424-general
There should be an automaic migration from firestore to data connect postgresql
👍
I just want to have an individual from the public select what data they want, pay, and then have a csv file of the data they selected. why is that so hard?
This got heated up quickly, if I said that you have SQL now just use SQL why do u add all of this hassle
🤯
Ok they have brought SQL but not the experience of working with SQL, what's the point then ?
This is nice, really nice, but why not 2 months earlier 😅
Feels to me as Hasura
Firebase: now has AWS Amplify built in
Exactly what I was thinking. I'm using amplify like this and it sucks. Will go with Supabase.
Will it have a dart sdk?
Yup, that's in the cards - and should be available before/with the public preview later in the year. You can vote for it here: firebase.uservoice.com/forums/948424/suggestions/48437954
I hope there is an migration tool from firestore to data connect😅
Yeah but how does firebase handle Role Base Access Control vs Supabase? The deal killer
Data Connect has a novel security model that allows for a combination of RBAC and ABAC and can be used to secure at both row and column level. It's one of the most exciting features of the product to me 🙂
@@michaelbleigh8737 can we get a comparison to supabase RBAC?
Let's go GCP Linus
Where's my Fireship video on this?
World is coming back to wait Rails give me 10 years a go! i am happy i am using Rails
the only exciting thing during io
Interesting, but this video would be more useful to me if it gave a little context up front: pros and cons of Data Connect vs Firestore for different scenarios.
Pros are you don't have to use a denormalized document based database with certain limitations because all queries have to be highly performant queries because you pay per query.
Cons are you have to use a relational database and have a bit more effort to define things up front, and may need to manage scaling a bit more and have more upfront cost (it's backed by a cloudsql instance? So idk if it can auto scale the same).
Oh good, Google learned what is GraphQL :D
This looks like hasura on steroids aka llm rag ❤🎉
So they already use idx 🤔
I use IDX for everything!
@@DavidEast so you Google developers have early access to every product?
Wait what ?? I moved already to supabase...
I think the curve will be little steep
Please sign up for the preview! We have spent a ton of time designing the dev loop to be simple and to provide tooling to help along the way. We'd love to hear your feedback.
we can use that with golang?
Yup, I have the same question
Our admin API is wire-compatible with GraphQL, so you can likely use a GraphQL library in Go to talk to it. We're still thinking about how we want to do Admin SDKs for Data Connect.
There was a lot of jargon thrown around in this video... I have no clue what they are... And ive been developing wih firebase for quite a number of years.
A lot of it was graphql jargon, or normal SQL jargon.
So if you haven't used either of those it makes sense it'd sound unfamiliar.
Queries, mutations, migrations, so on.
There was also some ai jargon I wasn't familiar with myself. The embedding stuff.
Firebase the supabase alternative
Theres no reason to use Supabase now
why ?
Finally I can stop using Hasura
While incredibly cool, I'm not going to lie, the query CONSTANTLY shaking up and down as you write it and then pause and then write and then pause, is beyond frustrating.
You're telling me. We didn't have much time to get the production done on this and all videos have to be done really early. This was a current bug and it's been fixed since then.
Great but pricing…
If we’re all getting replaced by ai who exactly are you making this for
Honestly firebase outs everyone
hahahaha before, from asking AI is supabase have onAuthChange to is firebase had RLS and RPC 😂😂😂😂😂😂😂
Is this real? April fools was over a month ago
Why does the studio look like a preschool
Oh wow, thanks, I hate it. 🥰
Sorry, Supabase better :)
too costly, doesn't make sense
great now I only need web3 options and I would have everything in Firebase
sounds like GraphQL rip off
The end result is much different then graphql. Because it uses some graphql things, but it makes it easier at the cost of making the API exposed to clients not be graphql. Since you use graphql to define queries in advanced, clients can only call predefined queries much like a typical rest API.
@@ChaseAnderson5k ok so it uses GraphQL for API definitions but gives you REST endpoints?
@@JH-bb8in more or less. The Data Connect API is wire-compatible with GraphQL but only takes operationName and variables instead of also taking the query document itself. We then execute the predefined query of that name and return the results.
Can't see this being around for too long. Nightmare for data security as natural language isn't as easy to interpret and convert to practical. It would have been better if they kept to known coding language to help adoption. All this conversion and constant online connectivity requirement can be a burden for users expecting a rapid response.
SUPABASE always will and always been greater than you