Firebase - A real-time server

Firebase
Aneeq Anwar
Software Engineer (iOS)

What is Firebase?
 Firebase is a scalable, real-time back for
your application.
It allows developers to build rich,
collaborative applications without the hassle
of managing servers or writing server-side
code

Firebase is Platform
Independent!
 Firebase has support for the web, iOS, OS X,
and Android clients.
 In addition, it has a Node.js and a Java library
designed for server-side use.
 The Firebase web client supports all mainstream
browsers (IE 7+, Firefox 3+, Chrome, Safari,
Opera, and major mobile web browsers), and it
works on any network connection.

How does it work?
 Developers install firebase by including a
library in their applications.
 This library provides a data structure that is
automatically synchronised between all of
your clients and with our servers.
 If one client changes a piece of data,
every other client observing the same
piece of data will be updated as well
within milliseconds.

Is Firebase just for “real-time” apps?
 Not at all!
 Firebase is for anybody that wants to write apps
without having to run backend servers or write
server code.
 Many developers prefer focusing on frontend
HTML and JavaScript rather than building,
deploying, and maintaining server-side backend
code.
 Even if real-time isn’t critical to your application,
Firebase can help you build your application
faster and scale seamlessly.

Firebase features
 Custom server code
Firebase fully support access from your backend
servers.
When used in this configuration, you still get all of
the benefits of using Firebase as your data store
(way less code, easier scaling, real-time updates,
etc.), while gaining the flexibility to run whatever
custom backend logic you need.

Firebase features
 Custom server code (Contd.)
It has a Node.JS client, a Java Client and a REST
API specifically for this purpose.
This allows you to do your own data processing,
custom validation, etc. on your own servers while
still relying on Firebase for data storage and real-
time propagation of updates.

Firebase features
 First class security
Firebase is intended for business-critical
applications, and it take the safety of your
data very seriously.
All of your data is stored redundantly and
off-site backups are made nightly.

Firebase features
 Offline support
Firebase transparently reconnects to the
Firebase servers as soon as you regain
connectivity.

Firebase features
 Offline support (Contd.)
In the meantime, all Firebase operations done
locally by your app will immediately fire events,
regardless of network state, so your app will
continue functioning correctly.

Firebase features
 Offline support (Contd.)
Once connectivity is reestablished, you’ll receive
the appropriate set of events so that your client
“catches up” with the current server state,
without you having to write any custom code.

Firebase features
 Real-time Synchronisation
Data updating speed of firebase is very fast.
Firebase is designed to be fast enough for high
performance real-time applications like network
games.

Firebase features
 Real-time Synchronisation (Contd.)
It maintain persistent connections between
clients and its servers so that data can be
pushed in both directions without delay, and it’s
servers are optimised for extremely low latencies.
As such, you can expect typical network
latencies (generally less than 100ms) for data
updates between clients.

Firebase features
 Data to store
At a high-level you can store any type of data in
Firebase, from game state to chat messages to
images or other media files.

Firebase features
 Data to store (Contd.)
At a low-level, it support basically the same data
types as JSON: Strings, Numbers, Booleans, and
Objects (which in turn contain Strings, Numbers,
Booleans, and more Objects).

Who uses Firebase
 Atlassian (JIRA)
 Codecademy
 Twitch
 And many more…

Firebase Data Structure
 When a new Firebase is created, it is
assigned its own unique hostname.
For example, if you were to create a
Firebase for your SampleChat application, it
could live at:
http://SampleChat.firebaseIOdemo.com/

 We refer to these URLs that point to data as
locations.
 Firebase locations can store strings, numbers,
booleans, or nested children.

 Nested children allow you to structure your
data hierarchically.
 For instance, SampleChat has a list of users,
which are located at:
https://SampleChat.firebaseIO-demo.com/users

 The data for users 'fred' and 'jack' is stored at these
nested locations:
https://SampleChat.firebaseIO-demo.com/users/fred
https://SampleChat.firebaseIO-demo.com/users/jack
 In this example, 'fred' and 'jack' are said to be children of
'users', and 'users' is said to be the parent of 'fred' and
‘jack'.

 Note that Firebase locations can contain either data (a
string, number, or boolean) or children, but not both.
 Locations for data can nest as deeply as you like. For
example, the last name for user 'fred' is located at:
https://SampleChat.firebaseIO-
demo.com/users/fred/name/last

Firebase Integration
1. Download latest Firebase.framework from
firebase.com
2. Unzip the above file and drag the .framework
folder to your XCode project under Frameworks

3. Firebase depends on these other frameworks. Add
them to your project:
 libicucore.dylib
 libc++.dylib
 CFNetwork.framework
 Security.framework
 SystemConfiguration.framework

4. Firebase makes use of Objective-C classes and
categories, so you'll need to add this under "other linker
flags" in build settings:
 -ObjC

Creating Firebase References
 Firebase* sampleChatRef = [[Firebase alloc] initWithUrl:@“https://SampleChat.firebaseIO-demo.com"];
 Firebase* childRef = [sampleChatRef childByAppendingPath:@“users"];
This is equivalent to:
 Firebase* childRef = [[Firebase alloc] initWithUrl:@“https://SampleChat.firebaseIO-demo.com/users"];
 Firebase* parentRef = [childRef parent];
parentRef and sampleChatRef now point to the same location.

Creating Firebase References
 Firebase* usersRef = [sampleChatRef childByAppendingPath:@"users"];
 Firebase* fredRef = [usersRef childByAppendingPath:@“fred"];
is equivalent to:
 Firebase* fredRef = [sampleChatRef childByAppendingPath:@"users/fred"];

Writing Data to Firebase
First we get a reference to the location of the user’s name data:
 Firebase* nameRef = [[Firebase alloc] initWithUrl:@"https://SampleChat.firebaseIO-
demo.com/users/fred/name"];
And then we write data to his first and last name locations:
 [[nameRef childByAppendingPath:@"first"] setValue:@"Fred"];
 [[nameRef childByAppendingPath:@"last"] setValue:@“Swanson"];
Alternatively, we can do:
 [nameRef setValue:@{@"first": @"Fred", @"last": @"Swanson"}];

Writing Data to Firebase
If you want to write multiple children of a Firebase location at the same time without overwriting other existing data,
you can perform an "update" operation as shown:
 [nameRef updateChildValues:@{@"first": @"Fred", @"last": @“Swanson"}];
 Adding a Completion Callback
[dataRef setValue:@"text" withCompletionBlock:^(NSError *error, Firebase* ref)
{
if(error)
{
NSLog(@"Data could not be saved: %@", error);
}
else
{
NSLog(@"Data saved successfully.");
}
}];

Reading Data from Firebase
Firebase is a real-time database, so data is never read synchronously. Instead, you read data by attaching a
callback to a Firebase reference as shown:
NSString* url = @"https://SampleChat.firebaseIO-demo.com/users/fred/name/first";
Firebase* dataRef = [[Firebase alloc] initWithUrl:url];
[dataRef observeEventType:FEventTypeValue withBlock:^(FDataSnapshot *snapshot)
{
NSLog(@"fred's first name is: %@", snapshot.value);
}];

We can observe different types of events:
 Value
 Child Added
 Child Changed
 Child Removed
 Child Moved

All reads are done through asynchronous callbacks
If the referenced data is already cached, your callback will be
called immediately, but if this is the first time the data was
accessed by this client, Firebase will need to request the data
from the Firebase servers first.

Callbacks are triggered both for the initial state of your data and
again any time data changes
In the above example, our callback will be called again if Fred's
first name ever changes.

Callbacks receive snapshots of data
A snapshot is a picture of the data at a particular Firebase
location at a single point in time.
It contains all of the data at that location, including any child
data. If you want to convert this data to a native format (such as
a JavaScript object on the web or a Dictionary in Objective-C),
you must do so explicitly.

Firebase is intelligent about aggregating callbacks
Firebase ensures that only the minimum required dataset is
loaded from the server, and the calling of callbacks and
generation of snapshots is extremely efficient.
As a result, you should feel comfortable attaching many
callbacks and having multiple callbacks of different types
attached to the same location.

Events that are triggered on your client do not always correspond
exactly with the write operations that were performed on other
clients
For example, if two other clients were to set the same piece of
data at approximately the same time, there is no guarantee that
two events will be triggered on your local client. Depending on
the timing, those two changes could be aggregated into a single
local event. Regardless, eventually all clients will have a consistent
view of the data, even if the events triggered in the process may
differ from client-to-client.

Reading data once:
[dataRef observeSingleEventOfType:FEventTypeValue withBlock:^(FDataSnapshot *snapshot)
{
// do some stuff once
}];
This is equivalent to:
__block FirebaseHandle handle = [dataRef observeEventType:FEventTypeValue
withBlock:^(FDataSnapshot *snapshot)
{
// do some stuff
...
// Remove the callback
[dataRef removeObserverWithHandle:handle];
}];

Using a Cancel Callback:
Firebase* fredRef = [[Firebase alloc] initWithUrl:@"https://SampleChat.firebaseIO-
demo.com/users/fred/name/first"];
[fredRef observeEventType:FEventTypeValue withBlock:^(FDataSnapshot *snapshot)
{
// Read succeeds.
NSLog(@"We have permission.");
} withCancelBlock:^(FDataSnapshot *snapshot)
{
// Read fails.
NSLog(@"We do not have permission.");
}];

Detaching Callbacks:
 [dataRef removeObserverWithHandle:someCallbackHandle];
If you would like to remove all callbacks at a location, you can do so as shown:
 [dataRef removeAllObservers];

References:
 https://www.firebase.com/docs/ios-quickstart.html
 https://www.firebase.com/docs/data-structure.html
 https://www.firebase.com/docs/creating-
references.html
 https://www.firebase.com/docs/writing-data.html
 https://www.firebase.com/docs/reading-data.html
 https://www.firebase.com/docs/faq.html

Firebase - A real-time server

Related slideshows

More Related Content

Firebase - A real-time server