Over the past several weeks,

we have spent a lot of time learning how to

build and deploy a full-fledged REST API server

by mastering technologies like the Express Framework and INNOSQL database like MongoDB.

This approach gives you full control over how you build and deploy your back-end server.

But in many situations,

we may have very little time to configure a server and then deploy it quickly.

So for example, you are a startup that needs to reach the market very, very quickly,

then you may want to quickly scaffold out the back-end server together with

a front-end application and reach the market very, very quickly.

In those circumstances, can we provide

the back-end support in the form of

a service that can be quickly configured and deployed?

That is exactly what we will discuss in more detail in this lecture and the

subsequent exercises in this lesson and the following lesson.

So, as we have learned in this course,

we have mastered the technologies,

the frameworks necessary for us to build a full-fledged back-end REST API server.

Now of course, as we have learned over the past several weeks,

this approach requires us to set up our own server and then configure the server,

we need to set up our back-end database and then

configure the various aspects of the back-end database.

We need to develop the REST API and various routes for our REST API,

and also we may need to build in

additional services like delivering push notifications to the user,

user management, social networking services, and so on.

So, all these mean that developing a full-fledged bank-end requires a lot of effort.

Now, can we package this whole approach into a service that can be

quickly configured and deployed without having

to spend so much time configuring our server?

Now you're looking at me strangely and saying,

"You spent the past three weeks training us in

all these technologies and now you're saying that it is very easy to

configure a server using a back-end as

a service to provide all these various features from our back-end."

Well, every approach comes with its own advantages and disadvantages.

Let's learn a little bit more about back-end as a service before we decide

whether the full-fledged server development approach

that we have learned so far is the right way for us,

or quickly configuring and deploying back-end

as a service is the approach that will satisfy our needs.

So, what exactly is back-end as a service?

The back-end is a service is designed as a model for providing

mobile and web developers to link their applications to the back-end cloud.

So typically, the back-end as a service is hosted in the cloud and then you expose

the back-end to the front-end through

a well-designed interface like the REST API endpoints.

A fully packaged back-end as we see in this lesson,

is a relatively recent phenomenon and has been taking the web world by storm.

We will look at some examples in a bit more detail.

Now, this provides a bridge between the front-end and the back-end data storage and

the back-end database management through a unified API.

And also many of these back-end as a service providers provide

their own software development kit which will enable

you to quickly get started on front-end development.

This approach of course frees up the developers from having to concentrate on

building a back-end and instead concentrate on their front-end development,

or trying to design and deploy the user experience within

the front-end be it in the form of

an angular application or be it in the form of a mobile app.

Now, if you are familiar with cloud computing,

I'm sure you've heard terms like infrastructure as a service,

platform as a service and software as a service.

Now, the mobile back-end as a service, or BaaS,

is essentially building upon this approach and targeting mobile and web developers

with access to back-end cloud services and a much more packaged environment.

So, this is how the back-end as a service enables you to

leverage the cloud back-end for supporting your front-end application.

Of course the next question that arises in your mind is what does

the back-end as a service provide for you typically?

A typical back-end as a service provides for you pushing

notifications automatically built into the back-end cloud support.

It provides you with file storage and sharing of files.

It provides you with social network integration.

Many of these back-end service providers provide

social network integration automatically for you.

It provides you with messaging and chat capabilities which you can

leverage within your front-end to provide better user experience.

It also provides you with user management.

As we have seen when we built our user management and

authentication support within our Express plus MongoDB server,

we had to build in the full-fledged authentication server,

we needed to build in the back-end services,

we needed to do the token management both on the back-end

and on the front-end and authentication of the user and so on.

All these can be packaged and delivered to you as a unit with

the software development kit that comes with the back-end as a service.

And also, back-end since it is a package service,

they also built in a lot of usage analysis tools which enable you to

get a quick overview of how the users are interacting with your back-end.

So, this usage tools give you a lot of

insight into the user behavior from within your back-end.

Also, many of these back-end services provide you with a method of

building and deploying your own custom logic

within the back-end to meet your specific requirements.

Of course, they provide you with the framework within which you can

design your custom business logic to meet your specific needs.

So to summarize, a typical back-end provides a data storage API for

cloud storage where you can upload and download files and also access these files,

some kind of a binary storage for your data,

perhaps device synchronization and caching capabilities.

So, for example, when you build your front-end,

the back-end data will be automatically cached in the front-end.

They may also support offline operation of your front-end.

So, even with your user device disconnected from the network,

you will still provide sufficient amount of

information to the user with offline capabilities.

So, both online and offline workflow so you can even allow the user to

perform their activities offline and then later on synchronize with the back-end.

Third party integration.

So, many times many of these back-end as a service providers

allow third party developers to develop plugins that can then

be leveraged together with the back-end to provide

extensions to the services that the back-end already provides for you.

Secure connectivity between the front-end application and the back-end,

and also many times automatically generate

the REST API endpoints for you based upon the data that you store in the back-end.

We will see examples of this especially with

LoopBack as we will see later on in the exercises.

And also as I mentioned,

many of these back-end as a service providers provide

their own software development kits so that you

can easily get started with your front-end development.

The SDK comes with all the code necessary for

your front-end application to automatically interact with your back-end application.

So, for example, the SDK might already contain

services that your angular application can leverage to talk to

the back-end automatically so you may be left only with implementing

the components and the front-end templates for your application.

All the interaction with the back-end is automatically

managed by the package SDK that is provided for you.

You will see examples of this both with

Firebase that we will look at in a little bit later,

and also with LoopBack that we will discuss in the next lesson.

Of course, any approach has two sides to the coin.

So, let's examine some of the advantages and disadvantages of back-end as a service.

Now, one advantage of course is that with

the back-end it provides you pre-built tried and tested components.

So, the back-end is packaged for you

so the back-end service provider would have ensured that

the entire back-end is well tested and will deliver the service as promised to the users,

to the front-end developers.

So, you don't need to spend additional time having

to worry about testing and ensuring that your back-end works correctly or not.

Unlike when you build your own custom

back-end using the frameworks that we have seen earlier,

you are fully responsible to ensure that your back-end works correctly.

The second advantage is of course,

the concomitant reduction in the server-side efforts that you need to put in.

So since the server-side comes as a packaged unit,

you can concentrate primarily on the front-end development and leave

the server-side for the backend as a service provider to deal with.

And you're simply leveraging the flexibility that they

provide for you in developing the front-end.

And the typical backend as a service provider will

take care of integrating any recent technological developments

into their backend and provide

updated versions of the backend as and when the newer technologies become available.

So, that way you as a front-end developer is

completely freed up from worrying about how the backend needs to evolve.

That is automatically taken care of by the BaaS provider for you.

Of course, everything comes with the flip side of the card.

So lets examine what are some of the downsides of going backend as a service.

First and foremost, most backends operate as a black box.

You do not know exactly how the backend is implemented.

If you are using an open source backend like LoopBack,

for example, you do have access to that entire backend code,

but still why would you want to spend time exploring the details of the backend,

when you have been guaranteed that the backend has been

built well and tested well for you.

So you can simply treat it as a black box as long.

As you have confidence that this black box is going to

deliver the services that you expect it to deliver,

you can simply use the backend without

having to worry about how it is actually implemented.

The second aspect is that,

if you choose to go with one backend as a service provider,

there is the issue of vendor lock-in.

So once you choose one of the BaaS providers,

you'll be locked into their environment and the way they store their data.

Many a time once you adopt one of these backend as a service providers,

all your data gets locked in to their service and you may have to go

through an inordinate effort in order to

retrieve the data that you have already stored in the backend,

should you choose to migrate from one backend as a service provider to another.

So deploying your service using one backend is a very straightforward task,

but then if you choose to change your BaaS provider,

that is going to be an uphill battle for you.

So that is something that you should be fully aware of before committing

to using one of the backend as a service providers.

This issue does not become a problem when you are

doing your full fledged backend development on your own.

Again, your win some and you lose some.

So we always take that with their whole picture in mind.

So, the loss of flexibility that you

entail by using one of the backend as service providers may be something that

you're willing to live with because of the fact that you have reduced amount of

backend development time and you can concentrate

more on delivering your product to the market.

So, if you trust the BaaS provider,

then you can simply go with your selected BaaS provider and then

not worry too much about the loss of flexibility that ensues because of that.

Again, as I said, not everything comes with only advantages,

there are always advantages and disadvantages to any approach that you

choose for developing and deploying your backend.

BaaS is just one alternative that might be the approach

that you choose to for your specific needs.

And finally, of course,

not every BaaS comes without its own set of additional training requirements.

If you need to use one of the BaaS providers,

instead of the black box, you need to learn the API,

you need to learn how to configure it,

you need to learn how to customize parts of it should you choose to do so, and so on.

So the training effort you spent learning

specific or generic frameworks like Express and databases like MongoDB,

instead you will be spending time learning

their specifics of their backend as a service that you choose to use.

So, it is a question of where you want to spend your time.

The additional training will always be involved,

except that with a BaaS provider you might be able to get started more

quickly than building your own custom backend.

The BaaS market is full of a number of choices.

And indeed, these choices keep increasing by the day.

Now when you go into the BaaS market,

you might see commercial vendors.

Here is a small list of commercial vendors.

Again, there are more and more that get added by the day to this list,

and I have just listed only a small subset of them.

Of course, if your favorite BaaS provider is not in this list, don't blame me,

maybe I'm just unaware of them or maybe they are just too

new to the market and so I haven't come across them.

But here is a list of some of the commercial vendors that provide BaaS services for us.

In particular, I'm going to concentrate on firebase,

which is provided by Google.

In this lesson we'll explore how to make use of firebase in a

little bit detailed in this lesson in the exercises that follow.

Now, if you want to go with an open source provider,

there are plenty of open source alternatives that are available for us,

of course there you will be

acquiring this open source software and then building your server end and deploying it.

Except that it'll come as

a prepackaged entity that you can quickly configure and deploy to the backend.

We will look at LoopBack as one of the examples of an open source software that

can be deployed very quickly for building your backend.

And as I said, more and more choices are coming into the market, day by day.

So, should you explore the market tomorrow to find new BaaS providers?

By all means, examine what is provided by them,

what kind of services that they provide.

Will those services that they provide meet to your requirements and can you quickly

leverage the service that they provide to get to the market quickly.

So these are issues that I will leave you within a day.

As I said, we should look at

all the possible alternatives and then make our own decisions independently.

But unless we are aware of the alternatives we won't be able to make informed choices.

So that is why the last few lessons of this course I'm spending

on exploring some examples of backend as service providers.

Backend as a Service

Server-side Development with NodeJS, Express and MongoDB

Meet the Instructors