Building theme-based Mobile app for a Multi Backend Architecture

Problem statement:

We got a use case to create a mobile app for a client having multiple backends for different clients and having a different theme of the app. We are not sure what kinda data will be coming to the mobile app from different servers as XML or JSON.

Challenge:

The least change is at the business layer and service layer of the mobile app.

The solution is Graph QL:

The Graph QL is a query language for APIs and a runtime for fulfilling those queries with Application existing data. Graph QL is a medium to interact with the apollo client and apollo server.

The theme app will have an apollo client in a mobile app that will interact with the apollo server.

Apollo server will have the responsibility to switch the backend and call the required backend system out of either making query to the API’s or calling database or calling existing apollo server.

The switching can happen in two ways.

• The Apollo client will register a different apollo server as per the app which calls a single backend system with respect to each client app

// Initialize Apollo Client
const client = new ApolloClient({
  uri: 'https://api.example.com', // change apolo server as per //client
  cache: new InMemoryCache()
});

const App = () => (
  <ApolloProvider client={client}>
    <MyRootComponent />
  </ApolloProvider>
);

• The Apollo client will send a different flag (to differentiate between themes of the mobile app ) to a single apollo server and the apollo server will have logic to redirect the query to a specific backend as per the flag.

Some of the concerns and their solution while using GraphQL mentioned below,

Authentication:

• App authentication implementation should eventually provide the current user to the resolvers
• Graph QL resolvers should not know about the authentication logic (separation between the business logic and the authentication logic)
• App wishes to protect only parts of your GraphQL schema and not all of it.
• App wants to be able to authenticate parts of your schema, on a field level.

However, Authentication can be done by sending HTTP headers and JSON web tokens by apollo link context.

Authorization:

• App wishes to protect some fields, according to custom rules.
• App wishes to run custom logics that protect parts of your GraphQL schema.
• Our custom rules should not be coupled to a specific resolver.

However, Authorization should be done on the server-side itself in the case of third-party APIs or servers. In the case of dealing with the database, a resolver should implement permission checks on the level of the node.

How does the Apollo client manage the cache?

Apollo Client uses a normalized, in-memory cache to dramatically speed up the execution of queries that don’t rely on real-time data.

The InMemoryCache normalizes query results before saving them to the cache by:

• Splitting the results into individual objects
• Assigning a unique identifier to each object
• Storing the objects in a flattened data structure

Syncing with the Server

Apollo Client caches the results of queries and then uses this cache to resolve queries when possible. You can control this behavior with the fetch policy you use when asking for query data.

There are a few strategies you can implement to make sure that Apollo Client is eventually consistent with the information available to your server.

Refetch:

Refetches are the simplest way to force a portion of your cache to reflect the information available to your server. Essentially, a refetch forces a query to immediately hit the server again, bypassing the cache. The result of this query, just like all other query results, updates the information available in the cache, which updates all of the query results on the page.

When to refetch?

In order for refetch to be a viable strategy, you need to know when to refetch a query. There are a few different use cases where refetching makes sense.

• Manual refresh: Many apps have a way for the user to manually request an updated view of their data, via a refresh button or pull-down gesture. refetch is perfectly suited for this case.
• In response to the event: Sometimes, you know when an event has happened that might invalidate data. For example, you might have some sort of event pushing that tells you when data might have changed. Then, a refetch can be the best way to avoid polling unnecessarily.
• After a mutation: There are several ways to make sure the store is up to date after a mutation, but the easiest way is to do a full refetch of the relevant queries. In this case, in addition to using the refetch method on the query itself, you can also use the refetchQueries options on the mutation.

Polling

If you have a query whose results can change frequently, and you want to be looking at a fresh view of the world, it makes sense to consider making a polling query. A polling query is fired on a particular time interval but otherwise works similarly to a refetch.

Subscriptions

Get real-time updates from your GraphQL server with help of subscriptions. Subscriptions are useful for notifying clients in real-time about changes to back-end data, such as the creation of a new object or updates to an important field.

In most cases, The Apollo client app should not use subscriptions to stay up to date with the current backend. Instead, we should poll intermittently with queries, or re-execute queries on demand when a user performs a relevant action (such as clicking a button).

We should use subscriptions for the following:

• Small, incremental changes to large objects. Repeatedly polling for a large object is expensive, especially when most of the object’s fields rarely change. Instead, you can fetch the object’s initial state with a query, and your server can proactively push updates to individual fields as they occur.
• Low-latency, real-time updates. For example, a chat application’s client wants to receive new messages as soon as they are available.

Security Factor:

Risk Factor :

• Performance issues with complex queries.
• Overkill for small applications.
• Web caching complexity
• SSL Pinning is not available from GRAPH QL Directly. we have to use additional packages or third parties for SSL Pinning in React native.

Why React Native App with Redux and Redux Observable:

For this, I will write a different article and many are floating online. So I will not go on that. My main focus was Graph QL to support multi-backend architecture.