Why BaaS APIs should be proxied via Edge

Google Cloud Apigee Knowledge Hub
1

We always recommend that you should proxy the BaaS apis via EDGE. And this is why we say so:

1. You can change the authentication mechanism.

By default BaaS supports certain flows of Oauth for accessing the data. You may not like it. You may want to have basic auth, web server flow of Oauth, SAML etc. If you proxy the BaaS APIs via edge you can change the authentication schemas in any ways suitable.

b. Have the same credentials for accessing BaaS APIs and any other APIs

BaaS credentials are different than all other APIs. You want same set of credentials for access all APIs.

2. You can change the URL structure

The URLs of BaaS looks in a certain way. Which may be different from your URL structure. Using Edge you can do URL transform to make the APIs look similar.

3. Error codes may be different

BaaS error codes may be different from your backend error codes.

If you create a proxy of BaaS APIs you can normalize the error codes.

4. Payload structure may be different

BaaS payloads may vary significantly from your backend and you may want to apply transformations to them to make the payloads look similar. BaaS supports only JSON whereas your other APIs may support XML as well. You can transform Json - XML in BaaS.

5. Analytics data

BaaS has some analytics in built, but it is rudimentary.

Once you proxy the BaaS APIs via EDGE you can start getting the rich analytics offered by Edge.

6. BaaS + node is powerful tool in your arsenal

You can use BaaS as your data store and write business logic in node and expose the APIs quickly to the consumers. This is a very powerful way to expose experimental APIs, sandbox environments etc. and in some cases may also be used for production APIs.

7. Sanitize the data to your liking

Each entity in BaaS stores a few data elements of its own like - created,modifiedat,path etc. You may not like these elements and create a policy in Edge to remove all of these.

8. Validate payloads for the POST/PUT operations

There is no way in BaaS to directly validate the incoming request schema/check for various threats like sql injection/CSRF etc. You can enforce these via Policies in Edge.

9. Offer BaaS apis to your consumers like any other API

You can open up the BaaS apis for consumption like any of your other APIs. For doing that you need to represent BaaS APIs as part of API products, document the BaaS APIs in dev portal etc.

10. Create mashups with BaaS data

Often data in BaaS in spread over multiple collections. And you might need to do mashups of these data before serving up to the consumers. There are multiple ways to do mashup in edge and is a very common use case.

11. Cache BaaS data in Edge

A lot of data from BaaS should be cacheable. BaaS is extremely optimized for very high read rate. By caching a good portion of the data in Edge will make data access even faster.

12. Don’t expose the BaaS query language to the outside world

BaaS has a very powerful query language built in which is awesome but proprietary. You may wanna hide that and expose a generic rest layer to your api consumers.

4 Likes
2

@sarthak , Great Article… Really helpful…

3

This is so awesome, @sarthak! It’s exactly what we’ve been doing/discovering with our StreetCarts project. We’ll create an article about that and link it to this. Nicely done.

4

Hi @Sarthak,

Thanks for this detailed post.

I wanted to understand below points here.

  1. If we want to hide the baas query language from api consumers, what is the best way to obtain the input parameters from api consumer, especially while asking to provide parameters for GET call when there are lot of permutations and combinations are possible like order by, select all or few fields, select data based on one or more conditions etc.

  2. If we want to expose baas apps via a generic API is it a good practice. I am asking this on the basis of below observations/points.

a. From a security perspective I have read that generally we should follow the practice to get the access token specific to a particular baas app so that it will restrict the use of that token only till that baas app and not entire baas org(if we obtain access token using the org level client id and secret values). Can we configure this dynamically?

b. Also there will not be any control of Apigee Edge on the number of apps that will be added in org and the collections that will be added any apps for that specific org. How will this be handled in the generic API so that it will work without any additional configuration?

Guidance here will be great help.

Thanks,

Santosh

5

@santosh_ghalsasi

  1. I recommend that you put together a swagger file that describes the collections and the input parameters. That way you are essentially doing a level of validation before forwarding the request onto BaaS - otherwise you are allowing for unbounded queries.

This a127 app shows you some code modeling this:

https://github.com/apigee/insights-samples/tree/master/apps/recommendations-app/recommendations-api

2a. By dynamically, I’m assuming the ability to get a new app level client id and secret ?

(see Application Client Authentication)

http://docs.apigee.com/app-services/content/authenticating-users-and-application-clients

Also, application client credentials do not have the ability to create new apps.

2b. My personal recommendation is that you create one API proxy per BaaS app. That way you can enforce the right types of controls. Basically, anything that is /{org_id}/{app} should have its own proxy. Anything that is /management should not be directly accessible - therefore you will never have a situation where outside users are creating apps that you don’t want them too.

http://docs.apigee.com/app-services/content/rest-endpoints

Let me know if that makes sense.

2 Likes
6

Hi Alan,

Thanks for inputs here.

I will try the a127 option and will let you know the output.

Also I went through the authentication process link and got the understanding of the process.

I want to create one API per org so that org credentials can be used to obtain an org-wide access token that can access any app in that org.

Will try this way and will let you know if I get stuck anywhere.

Thanks,

Santosh