[MUSIC PLAYING]
PETER FRIESE: Hey, everyone, and welcome to another episode
of Firebase Stories.
My name is Peter, and I'm a developer advocate
on the Firebase team.
And today, I'm here with Harini from Rowy,
who is the CEO and co-founder of Rowy.
Hey, Harini, How's it going?
HARINI JANAKIRAMAN: Hey, Peter.
Doing good.
Thanks for inviting me to chat.
PETER FRIESE: Yeah, it's good to have you on the show.
So, Harini, why don't you give us the elevator
pitch of what Rowy is?
HARINI JANAKIRAMAN: Yeah, sure.
So Rowy is a local platform that lets you manage your Firestore
data and build cloud functions as easy as using spreadsheets.
So we build Rowy, because we love building apps on Firebase,
but then only developers have access to the database.
And there was a lot of back and forth
that was needed to be done between developers
and non-technical teams.
So we wanted to bring access to the database in a spreadsheet
format that everybody's familiar with.
So that's why we built Rowy.
PETER FRIESE: That sounds pretty cool.
Yeah, I know that people are asking us all of the time,
why don't you build more features into the Firestore
data browser?
You can edit data and all of that,
but people are missing features.
And it seems like you are filling this gap, right?
HARINI JANAKIRAMAN: Yeah exactly.
So Firebase is great to build on, to get quickly set up,
and get your apps going, but certain kind of internal tools
that developers don't want to build,
so Rowy gives you that instant access to your database
in a spreadsheet UI.
So that's why we kind of wanted to avoid people
building internal tools over and over again.
And they can leverage Rowy.
PETER FRIESE: Maybe you can walk us through how it works
and maybe give us an understanding
of how it looks like.
HARINI JANAKIRAMAN: Yeah, sure.
So on my screen you can see that Rowy here
is connected to one of the projects,
but basically, you can connect to any number
of projects on Rowy.
And you can view your collections
like this in a spreadsheet table format.
PETER FRIESE: Mm-hmm.
HARINI JANAKIRAMAN: We support tons of column and field types.
So as you can see, multi select ratings, sliders, images,
files, and so on.
So we have a support for over 30 fields here.
So we can easily add columns.
And adding data rows is also as simple as adding rows.
You can filter and solve the data.
You can import and export data in bulk.
And also, you can invite your team members,
so that you can collaborate on the data with granular access
controls with custom roles for each member of your team.
PETER FRIESE: That's pretty cool.
So one thing that you showed just there
is the number of fields that you support.
So Firestore supports a number of basic fields,
but you support a lot more.
And I was wondering how you managed to implement that.
HARINI JANAKIRAMAN: Yeah, so at a UI level, we abstract away
the field type.
So for example, this field here, so if you actually
go into Firestore, you are able to actually look
how it looks like, which is a basic string element.
So we abstract away all the fields at a UI level,
so that each of these fields are able to map to the eight fields
that Firestore supports.
And also, we are building Rowy in open source,
so we have all these field types that you
can explore the code for.
You can also add your own column types
if you need something specific, so that's
something we are working on.
PETER FRIESE: That's pretty cool.
Yeah, I love that you can extend it.
Can you maybe show us how--
let's say, how would a telephone number field or an email field
look like?
HARINI JANAKIRAMAN: Here you have this email field.
Basically, you can also set default values for it.
And you can have validation and regex level.
So here, if I go into Firestore, you can see here, for example,
this email field gets stored as a basic string.
So essentially, you can do similar stuff for other things
as well.
So I can think of it, like, hey, there
is this multi select column, which is basically maps down
to an array of string.
So it kind of maps it down to the closest possible field
that Firestore supports.
PETER FRIESE: Yeah, nice.
So another thing that is probably really important
when you open the access to your database
to a number of people within your company,
you'll have people from all sorts of different departments,
and you want to make sure that not everybody can
see your customer's data, for example, not everybody
can modify it.
So I think access control is a really important topic.
How does Rowy support that?
HARINI JANAKIRAMAN: Yeah, 100%.
So this is something we know was top of our mind
when we are building it.
Opening up access to the database to non-technical team
members can be scary.
So we have introduced custom role-based access.
So for example, you can here define
which are the roles in your team that needs access
to this specific collection.
You can also define your own, say, suppose
you have marketing team.
You can add that, and then effectively, you
can say whether you need to give them read write access.
So for example, if you want to give these people only read
access, you can do so.
And here we suggest the specific files to a rule,
so all that you need to do is copy this over
to Firestore console and just paste it.
So you are able to basically have granular access
control at both higher level, collection level,
but also granular level, whether it's read write access or view
access, so you're able to fully control
what it is that who can access.
PETER FRIESE: And then you'd have to go into the rules file
and update the rule.
What happens if you, let's say, you
give read access to the marketing team.
And then later on, you decide, oh, but now we would also
give them write access?
Do you have to find the rule in the rules file,
and then manually edit that?
HARINI JANAKIRAMAN: Yeah, so you'll
be able to do that where here you can say,
and now you say, OK, now marketing team,
I need them to have write access as well.
So we suggest the rule.
And for the collections, all that you need to do
is go to here, and then for that collection,
just change the rule.
So it's as simple as just using files tools' existing
structure.
So this kind of allowed us to build a complex access policies
without having to do things from scratch.
PETER FRIESE: Yeah, I really like it.
So it seems very powerful and easily accessible
at the same time.
However, I mean, obviously, you still
have to know what you're doing there.
So you can, for example, if you mess the rules files up,
then you're probably in trouble.
So you need to pay a little bit of attention
to what you're doing right there.
HARINI JANAKIRAMAN: Yeah, exactly.
So only developers or admin access can do these changes.
So once they actually set up the table
and get all the rules in place, anyone else who's invited,
who is possibly non-technical, they don't have access
to change any of these, so they're just
interacting with this as a spreadsheet
and making modifications to things
that they are allowed to.
PETER FRIESE: That's pretty cool.
OK, cool.
So let's talk a little bit about how it was actually built.
So now we've seen how it looks and feels
like from the user's perspective,
but we're always interested in taking
a look behind the scenes.
So I guess, because you're building this
as a tool to augment Firestore, that obviously you
use Firestore under the hood, but which other Firebase
products do you use?
HARINI JANAKIRAMAN: Yeah, so we use a Firebase
Auth for Rowy app's authentication process, where
users can sign up and start using Rowy.
Apart from Firebase storage, we also use images and files
that you upload here.
It gets directly uploaded to Firebase Storage.
So in addition to Firestore, we use Firebase Storage.
We also use Cloud Functions heavily,
so any data-based change triggers--
so we have two special column types called
actions and derivatives.
And that kind of helps users build Cloud Functions.
And that kind of gets wrapped up and deployed in their own cloud
projects.
In that, we also allow users to use Secret Manager.
Yeah, and we also heavily use the Realtime listeners.
So to give that collaborative real-time experience,
so someone is changing a data in a table here,
someone else is also making a change,
we are able to build a real-time listener-based product easily
without having to do that from scratch as well.
PETER FRIESE: I am really curious about the Cloud
Functions part there.
You mentioned you've got those two different column types.
So I guess this is a part where you go from no code to low code
and give users the ability to implement
pieces of functionality to build real applications there.
HARINI JANAKIRAMAN: Exactly.
So here we have a sample demo app.
Essentially, if someone adds a row and drops in an image,
here, we can basically use any API or NPM packages.
So here we have a derivative column,
which is a Cloud Function column, which basically uses
one of the NPM packages to translate
this image into an actual text description of what it is.
So as we were talking, this kind of
is a database that's populating itself.
So we have another derivative column, which basically
then listens to this field text, and then uses Google Cloud's
text to speech to translate that to an audio file
and gets uploaded to Firebase Storage.
So you can basically focus on writing your business logic
this way, where if your data point changes,
something else happens.
And you're just writing that business logic,
and we take care of packaging that up and deploying it
as a Cloud Function in your back end in Firebase.
So we have another thing here, which
is like a quick action column, which also is similar,
but it's more action button-based.
So similarly, you can run a JavaScript code here
on click of a button here.
I'm just toggling this on.
So you can do pretty much anything with it.
PETER FRIESE: And so the Cloud Functions
are actually part of my project, so these are not stored
anywhere on your servers.
But in my project, I have full ownership of everything I do.
HARINI JANAKIRAMAN: Exactly.
So all this data that you see is all in your Firebase,
and all the data is on Firestore all the functions that
get created on Rowy is also deployed to your Firebase
itself.
PETER FRIESE: So one thing that's
pretty interesting, in this context, is environment.
So let's assume I have a production environment,
of course, and then a development environment,
and a test environment.
Does Rowy support migrating stuff
from my development environment to test, and then
to production?
HARINI JANAKIRAMAN: Yeah, so that's
something we constantly have to do ourselves when we probably
start off-building in develop, and then
move it to testing, and then to production.
So that's why we have this workspaces concept.
You can have any number of workspaces,
and each of these workspace can connect to different projects.
And you're able to move your data tables and functions
once you are already in development
to testing, and production, and so on.
PETER FRIESE: Another thing that I'm wondering
is how do you store all those specifications
about my data model?
So any settings that I make for my instance,
will these be stored in some sort of metadata files, or how
do you handle that?
HARINI JANAKIRAMAN: All the configuration
for your table structure and in your project
will be actually stored in your own Firestore collection.
We have a Rowy collection that gets created,
and it stores everything about your project
here, so we don't store any of your data outside of Rowy.
PETER FRIESE: And how does the installation process work like?
So when I want to use this in--
let's say I've got an existing Firebase
project, with an existing Firestore setup,
I've got a couple of collections in there.
Can I add Rowy to my existing project?
And if yes, how do I do that?
HARINI JANAKIRAMAN: Yeah, so you can
connect to any of your existing projects
or you can create brand new ones.
So all that you need to do is click here.
You can give your project a name.
And effectively, Rowy shows you a list of all the projects
that you have available, so you can pick any of them
and connect to them easily.
And once you connect you're able to then also easily
build tables.
So for example, I create a new table.
This can connect to your existing collection
or you can create a brand new collection right here.
PETER FRIESE: Oh, that's great.
So I could basically use this to, if I have an application,
but I don't want to implement all the data management backend
stuff to allow my team to add new data
or manipulate existing data, then
I could just add Rowy and have an admin interface
for basically zero work.
I just need to install it.
HARINI JANAKIRAMAN: Exactly, so you
can have different workspaces for different user groups.
You can connect to different projects.
You can also show only subset of tables that you want.
You don't need to show all your collections in the project.
So you can basically have full flexibility the way
you set it up.
PETER FRIESE: That's amazing.
So if people want to learn more about Rowy,
where should they go?
HARINI JANAKIRAMAN: You can get started from Rowy
from our website.
So you can get set up by just clicking
the Get Started button.
Because we are building an open source,
you can also try out the self-hosted version
if you're interested.
But this kind of gives you a guide at step
by step instructions from our website to get set up
and get started.
We also have a live playground where
you're able to explore many number of demo tables
and collections we have built. You can simply
clone them and get started.
So that kind of gives you, without even
creating an account, and give experience
of how it is to use Rowy.
And yeah, we have a Discord community
with Firebase developers and others
building with Rowy in low code, so we
would love to have you there.
PETER FRIESE: OK, great.
Well Harini, Thanks for coming on the show,
and taking us behind the scenes, and explaining what Rowy is
and how it works.
That was super exciting, and I think
this is a super useful tool for anyone who uses Firestore.
HARINI JANAKIRAMAN: Yeah, thanks, Peter, for having me.
PETER FRIESE: And that was another episode
of Firebase stories where we show you
how other developers, like yourself, use
Firebase technologies to build amazing applications
and toolkits.
Thanks for watching, and we will see you in the next one.
[MUSIC PLAYING]