MARK MIRCHANDANI: Augmented reality
helps people experience digital information in a new way.
Join us as we to talk to Torch about how they're
enabling anyone to build AR experiences
on this episode of Stack Chat.
Thanks for joining us, Josh.
Tell us a little bit more about what Torch does.
JOSH FAUST: Thanks for having me, Mark.
Torch is an AR design and publishing platform.
So we are a mobile first workflow
for building AR inside of AR.
We let designers very quickly prototype and develop
augmented reality experiences they can then
share with other people.
MARK MIRCHANDANI: So what does the architecture
look like for people who are going
to go in and build an AR app?
JOSH FAUST: So we had three main goals when building Torch 1.0.
We wanted the camera first, mobile first workflow.
We wanted to allow people to easily bring in whatever assets
they had whether it's images, video, 3D models, all of that.
And then we wanted to enable collaboration
and semi-realtime collaboration between users on the platform.
So we went with Firebase for the mobile device portion of that
because it allowed us to not really pay attention
to a lot of what we needed to do to offload computation
into the Cloud.
Working on a mobile device, we're already
very limited with CPU and GPU.
We're running computer vision to do AR,
we're running realtime 3D rendering at 60 frames
a second.
So we needed to be able to shift some of that computation
into the Cloud.
And Firebase lets us do that really
easily by calling Cloud Functions,
by using realtime databases, things like that.
For Asset import, we wanted to be
able to support all sorts of file types
and to do it in a very fast and efficient manner.
And so we did that through a combination
of Firebase Functions and GKE.
So rather than trying to do any kind of computationally
expensive processing on the mobile device,
we ship Assets to the Cloud, run them
through a Cloud processor in GKE,
and then ship them back into Functions
where we then update Firestore.
And that lets the mobile device know that everything's ready.
Some examples of what we do in the Cloud
are encoding images into GPU formats.
We do model conversions between various 3D file formats.
We process video for realtime, things like that.
And then for collaboration, we are really
leaning heavily on Firestore.
So we use realtime snapshotting in order
to let multiple clients be writing
to the same set of documents and realtime
update everything that's happening as it's happening.
We do this a little bit differently
than you might think.
So we're not using single documents as a document store.
We're doing time series data.
And what's awesome is as events sourcing
where every event that has ever happened in a project,
we know and we track.
And then to build up the final result,
you run through every event and generate the full scene
document or the full project document.
And then for performance and bandwidth reasons,
every once in a while in a Cloud Function,
we will what we call checkpoint those events.
And so that takes those events up until a certain time,
turns it into the final project format.
And so then to retrieve a project,
we retrieve the latest checkpoint
in any event that has happened since.
MARK MIRCHANDANI: So it sounds like a lot
of the realtime collaboration, of course,
depends on Firestore.
What made you choose Firestore as the right way
to handle this?
JOSH FAUST: So we had two main reasons for that.
Because we're primarily a mobile app
and we didn't want to write any Cloud infrastructure that we
didn't really need to, direct access to the DBE from mobile
and from Cloud Functions was really important to us.
On the other side of that, that's
a really double edged sword because it
means that you need to be really careful about your schema
management and making sure that you're not doing anything bad
on either side of those.
And so what we ended up doing is building a type safe layer
in TypeScript for access to the database that makes sure
that programmers are not willy nilly adding
to the schema, changing things when we don't know about it.
And then we've also added the ability to version and document
and migrate between versions.
So the second reason we chose Firestore
is due to that snapshotting that I talked about earlier where
we can just set up callbacks and get live data as things change.
And it's just really easy to hook into UI, to hook
into application state.
And so it just-- it provides us with a programming model that
makes all that really easy.
MARK MIRCHANDANI: So it sounds like you may have
made some changes over time.
If you could go back and re-architect this
based on what you learned over the process,
what would you do differently?
JOSH FAUST: So the first thing is,
if we were to redo it today, Cloud Run now exists.
And so a lot of what we actually built up
in GKE to do Asset processing we could
do without having to build what we built in GKE.
And so we would probably move as much of our--
as much of the code that is in GKE and Cloud Functions
into Cloud Run.
But it didn't exist at the time, so oh, well.
The second thing is schema management.
The schema that we first chose for Assets
made it very expensive for us to determine,
does a user have access to this Asset?
And so what we've ended up with is, in order to security store
Assets but also make it very cheap
for users, for clients to access any information they need
to download in Asset, we do real time syncing of Asset data
into the project.
So any information that a client needs in order
to recreate the project gets mirrored into the project
itself.
MARK MIRCHANDANI: Thanks for telling us
about how you actually built this application
to help other people build their own applications.
JOSH FAUST: Absolutely.
Thanks for having me.
MARK MIRCHANDANI: Get started with Cloud Firestore
by checking out this quick start guide.
Thanks for watching.
And make sure to subscribe for more great Google Cloud
Platform content.
We'll see you next time on Stack Chat.
[MUSIC PLAYING]