Making the Case for a UI Service Layer

Ask a front-end developer to list the biggest obstacles to delivering on-time, quality user interfaces and “complex service integration” will be near the top of that list. In this article, we discuss issues surrounding front-end/back-end integration and present the case for a User Interface (UI) Service Layer. We’ll compare Falcor and GraphQL as possible solutions.

The Challenge

Representational State Transfer (REST) has been the de facto architectural style for accessing web resources using a uniform and predefined set of stateless operations. Its success is due to simplicity, ease of testing and scalability. RESTful APIs are now treated as core to business and often delivered as a product to end customers and internal constituents.

The challenge is tailoring a RESTful service layer to suit the particular needs of a given application.  Does the current set of available APIs meet the needs of the application UI?  Typical issues include:

  • API response needs to be manipulated and or formatted to before it can be consumed by the UI
  • Resulting dataset is larger than necessary affecting bandwidth usage
  • Several APIs must be called to satisfy the data requirements for a single UI component
  • APIs may have been designed for a desktop application and are not ideal for mobile performance considerations

For optimal user experience both web and native applications must:

  • Avoid multiple round trip calls to the network
  • Fetch only needed data from the remote API services to fit for the data shape of the UI
  • Avoid manipulation of resulting data set to achieve desired layout
  • Enable lazy-loading/pagination of information to handle large result sets

Why a User Interface Service Layer?

Implementing a user interface service layer addresses the challenges identified above.  In a traditional development scenario, the RESTful service contract is developed by a back-end team with little to no input from front-end developers responsible for building out the UI.  Once delivered, the disconnect between expectations and reality become apparent. The development process is either delayed due to API changes or the UI must be compromised.  The preferred scenario is to have the front-end team own the service signature once it is defined. Subsequent changes must be reviewed.  It is the job of the back-end developer to provide a solution that delivers the desired experience.  The User Interface Service layer achieves this goal.

The benefits of a user interface layer:

  1. Services are tailored to user interface needs
  2. Ability to leverage investment in existing services through orchestration
  3. Minimal impact on performance
  4. Enable user interface developer to move forward while back-end services are being completed.
  5. Reduced friction between service layer and user interface needs

Potential drawbacks:

  1. Increased solution complexity with need for one more server
  2. Ramp-up on the technology (GraphQL, Falcor)

In our experience, reducing friction at the point of service integration for a user interface (desktop, mobile, voice, or other), has a significant return on investment with improved efficiency of development teams and reduced defect rates.

A Comparison of GraphQL and Falcor

In this article, we look at two technologies that address these challenges using different approaches. Leveraging these technologies simplifies building Data Service API at the orchestration layer in addition to current existing micro services and UI clients. Both Falcor and GraphQL have been introduced to solve these challenges. We review them to understand similarities and differences before deciding which one should be used at the orchestration layer.

Similarities between Falcor and GraphQL

  • Single end point – In contrast to REST APIs with multiple end points, both Falcor and GraphQL only have one end point to fetch data
  • Only fetch data needed from perspective of the UI – Reduced payload benefits mobile clients with limited bandwidth. Faclor uses the JSON route path to fetch only the needed data in virtual JSON data model while GraphQL specifies the needed data in response from the query.
  • Reduces multiple API calls – Both reduce multiple API calls via remote network because they can fetch all needed data in one API call. Both enable a single endpoint to aggregate resulting data from multiple services (RESTful, Database, …)
  • Additional orchestration layer – Falcor and GraphQL need corresponding servers as an additional orchestration layer in addition to current clients and API services. The advantage is that existing micro services can keep their APIs to evolve at its own speed while the UI client can assert a client-specific specification on the orchestration layer with either Falcor or GraphQL servers. Of course, the disadvantage is that additional deployment and support on the orchestration layer are needed to support the UI change requirement. It is worth adding this additional orchestration layer when enterprise businesses must support multiple clients and complicated backend API services.
  • Pagination – Both support pagination via their own client.
  • Client caching – Falcor supports client caching behind virtual data model seamlessly. GraphQL client caching can be achieved by caching query variables and the unique JSON object id.

Differences between GraphQL and Falcor

  • Schema – GraphQL has a defined schema with static data type as a contract between the GraphQL server and client. The schema can be viewed in GraphQL browser which is used as the API documentation. In contrast, Falcor does not have schema.
  • Query language – GraphQL has declarative query language for query, mutation and subscription. In contrast, Falcor does not have its own query language. It uses JSON route path to specify the JSON path for the needed data in request.
  • JSON response – JSON response for Falcor is JSON graph while JSON response for GraphQL is just a simple JSON tree.
  • Client implementation – Since only Falcor client can interpret JSON graph, Falcor must use both Falcor client and Falco server together. Although not required, it is preferable to use Apollo client or Relay as client for GraphQL.
  • Server implementation – While both Falcor server and GraphQL server have node.js implementations. GraphQL server also has implementations in other languages, such as Java, Scala, Python and Golang.
  • Subscription via web socket – GraphQL server and Apollo client support cutting edge features for the client to subscribe as an observer of changed resources on GraphQL server via web socket. Falcor has not delivered this capability yet.
  • Developer learning curve – Falcor is easier to learn since UI developers only needs to get and set from a virtual data model seamlessly. In contrast, GraphQL has a higher learning curve because it has more powerful features than Falcor.
  • Popularity and support – Falcor was originally developed by Netflix and kept steady popularity while GraphQL was invented by Facebook and has seen exponential growth as a new actor in API world. Recently, Github, Contentful and Coursera.org have adopted GraphQL API, providing public GraphQL APIs.

Falcor GraphQL
Similarities
Single End Point Yes Yes
Fetch Only Needed Data Specify in JSON Route Path Specify in Query
Reduce Multiple API Calls Yes Yes
Orchestration Layer Falcor Server GraphQL Server
Pagination Yes Yes
Caching Falcor Client Caching Client Caching
Differences
Schema No Static Type
Query Language No Declarative
JSON Response JSON Graph JSON Tree
Client Implementation Falcor Client Apollo Client, Relay
Server Implementation Falcor Server, Node.js GraphQL Server, Node.js, Java, Go, etc.
Subscription Via Web Socket Not Yet Yes, Observer for Changed Reasource
Learning Curve Easy to Learn Steep but Powerful
Popularity Steady Growing Exponentially
Inventor Netflix Facebook

Summing It Up

Utilizing a UI Services layer ensures that the resulting integration(s) to the back-end are optimized for the user interface to deliver the optimal experience for the end-user. This approach also improves the efficiency of the front-end developers by reducing the effort for integration. When making this decision consider the benefits of leveraging a technology like GraphQL or Falcor against the additional complexity of managing another server-side technology.

Both GraphQL and Falcor meet the requirements of the UI developer, enabling them to simplify fetching data, increase development efficiency and deliver a higher quality product. They also reduce payload and multiple network API calls. When there are multiple clients in addition to a complicated back-end data model from multiple API end point services, it is worth adding a Data Service API at the orchestration layer with GraphQL or Falcor.

Compared with Falcor, GraphQL is more promising due to its rate of adoptions, level of maturity, such as its ability to aggregate data from multiple end points seamlessly. In addition, it has added powerful features such as client subscription of changed data from GraphQL server via web socket and works seamlessly with multiple user interface frameworks, including React Vue and Angular.

References

  1. REST https://en.wikipedia.org/wiki/Representational_state_transfer
  2. APIs as a product https://www.thoughtworks.com/radar/techniques/apis-as-a-product
  3. Falcor https://netflix.github.io/falcor/
  4. GraphQL http://graphql.org/
  5. A new actor in the API world http://blog.octo.com/en/graphql-a-new-actor-in-the-api-world/
  6. Apollo client http://dev.apollodata.com/react/
  7. Subscription via web socket https://github.com/apollographql/subscriptions-transport-ws

Ask a front-end developer to list the biggest obstacles to delivering on-time, quality user interfaces and “complex service integration” will be near the top of that list. In this article, we discuss issues surrounding front-end/back-end integration and present the case for a User Interface (UI) Service Layer. We’ll compare Falcor and GraphQL as possible solutions.

The Challenge

Representational State Transfer (REST) has been the de facto architectural style for accessing web resources using a uniform and predefined set of stateless operations. Its success is due to simplicity, ease of testing and scalability. RESTful APIs are now treated as core to business and often delivered as a product to end customers and internal constituents.

The challenge is tailoring a RESTful service layer to suit the particular needs of a given application.  Does the current set of available APIs meet the needs of the application UI?  Typical issues include:

  • API response needs to be manipulated and or formatted to before it can be consumed by the UI
  • Resulting dataset is larger than necessary affecting bandwidth usage
  • Several APIs must be called to satisfy the data requirements for a single UI component
  • APIs may have been designed for a desktop application and are not ideal for mobile performance considerations

For optimal user experience both web and native applications must:

  • Avoid multiple round trip calls to the network
  • Fetch only needed data from the remote API services to fit for the data shape of the UI
  • Avoid manipulation of resulting data set to achieve desired layout
  • Enable lazy-loading/pagination of information to handle large result sets

Why a User Interface Service Layer?

Implementing a user interface service layer addresses the challenges identified above.  In a traditional development scenario, the RESTful service contract is developed by a back-end team with little to no input from front-end developers responsible for building out the UI.  Once delivered, the disconnect between expectations and reality become apparent. The development process is either delayed due to API changes or the UI must be compromised.  The preferred scenario is to have the front-end team own the service signature once it is defined. Subsequent changes must be reviewed.  It is the job of the back-end developer to provide a solution that delivers the desired experience.  The User Interface Service layer achieves this goal.

The benefits of a user interface layer:

  1. Services are tailored to user interface needs
  2. Ability to leverage investment in existing services through orchestration
  3. Minimal impact on performance
  4. Enable user interface developer to move forward while back-end services are being completed.
  5. Reduced friction between service layer and user interface needs

Potential drawbacks:

  1. Increased solution complexity with need for one more server
  2. Ramp-up on the technology (GraphQL, Falcor)

In our experience, reducing friction at the point of service integration for a user interface (desktop, mobile, voice, or other), has a significant return on investment with improved efficiency of development teams and reduced defect rates.

A Comparison of GraphQL and Falcor

In this article, we look at two technologies that address these challenges using different approaches. Leveraging these technologies simplifies building Data Service API at the orchestration layer in addition to current existing micro services and UI clients. Both Falcor and GraphQL have been introduced to solve these challenges. We review them to understand similarities and differences before deciding which one should be used at the orchestration layer.

Similarities between Falcor and GraphQL

  • Single end point – In contrast to REST APIs with multiple end points, both Falcor and GraphQL only have one end point to fetch data
  • Only fetch data needed from perspective of the UI – Reduced payload benefits mobile clients with limited bandwidth. Faclor uses the JSON route path to fetch only the needed data in virtual JSON data model while GraphQL specifies the needed data in response from the query.
  • Reduces multiple API calls – Both reduce multiple API calls via remote network because they can fetch all needed data in one API call. Both enable a single endpoint to aggregate resulting data from multiple services (RESTful, Database, …)
  • Additional orchestration layer – Falcor and GraphQL need corresponding servers as an additional orchestration layer in addition to current clients and API services. The advantage is that existing micro services can keep their APIs to evolve at its own speed while the UI client can assert a client-specific specification on the orchestration layer with either Falcor or GraphQL servers. Of course, the disadvantage is that additional deployment and support on the orchestration layer are needed to support the UI change requirement. It is worth adding this additional orchestration layer when enterprise businesses must support multiple clients and complicated backend API services.
  • Pagination – Both support pagination via their own client.
  • Client caching – Falcor supports client caching behind virtual data model seamlessly. GraphQL client caching can be achieved by caching query variables and the unique JSON object id.

Differences between GraphQL and Falcor

  • Schema – GraphQL has a defined schema with static data type as a contract between the GraphQL server and client. The schema can be viewed in GraphQL browser which is used as the API documentation. In contrast, Falcor does not have schema.
  • Query language – GraphQL has declarative query language for query, mutation and subscription. In contrast, Falcor does not have its own query language. It uses JSON route path to specify the JSON path for the needed data in request.
  • JSON response – JSON response for Falcor is JSON graph while JSON response for GraphQL is just a simple JSON tree.
  • Client implementation – Since only Falcor client can interpret JSON graph, Falcor must use both Falcor client and Falco server together. Although not required, it is preferable to use Apollo client or Relay as client for GraphQL.
  • Server implementation – While both Falcor server and GraphQL server have node.js implementations. GraphQL server also has implementations in other languages, such as Java, Scala, Python and Golang.
  • Subscription via web socket – GraphQL server and Apollo client support cutting edge features for the client to subscribe as an observer of changed resources on GraphQL server via web socket. Falcor has not delivered this capability yet.
  • Developer learning curve – Falcor is easier to learn since UI developers only needs to get and set from a virtual data model seamlessly. In contrast, GraphQL has a higher learning curve because it has more powerful features than Falcor.
  • Popularity and support – Falcor was originally developed by Netflix and kept steady popularity while GraphQL was invented by Facebook and has seen exponential growth as a new actor in API world. Recently, Github, Contentful and Coursera.org have adopted GraphQL API, providing public GraphQL APIs.

Falcor GraphQL
Similarities
Single End Point Yes Yes
Fetch Only Needed Data Specify in JSON Route Path Specify in Query
Reduce Multiple API Calls Yes Yes
Orchestration Layer Falcor Server GraphQL Server
Pagination Yes Yes
Caching Falcor Client Caching Client Caching
Differences
Schema No Static Type
Query Language No Declarative
JSON Response JSON Graph JSON Tree
Client Implementation Falcor Client Apollo Client, Relay
Server Implementation Falcor Server, Node.js GraphQL Server, Node.js, Java, Go, etc.
Subscription Via Web Socket Not Yet Yes, Observer for Changed Reasource
Learning Curve Easy to Learn Steep but Powerful
Popularity Steady Growing Exponentially
Inventor Netflix Facebook

Summing It Up

Utilizing a UI Services layer ensures that the resulting integration(s) to the back-end are optimized for the user interface to deliver the optimal experience for the end-user. This approach also improves the efficiency of the front-end developers by reducing the effort for integration. When making this decision consider the benefits of leveraging a technology like GraphQL or Falcor against the additional complexity of managing another server-side technology.

Both GraphQL and Falcor meet the requirements of the UI developer, enabling them to simplify fetching data, increase development efficiency and deliver a higher quality product. They also reduce payload and multiple network API calls. When there are multiple clients in addition to a complicated back-end data model from multiple API end point services, it is worth adding a Data Service API at the orchestration layer with GraphQL or Falcor.

Compared with Falcor, GraphQL is more promising due to its rate of adoptions, level of maturity, such as its ability to aggregate data from multiple end points seamlessly. In addition, it has added powerful features such as client subscription of changed data from GraphQL server via web socket and works seamlessly with multiple user interface frameworks, including React Vue and Angular.

References

  1. REST https://en.wikipedia.org/wiki/Representational_state_transfer
  2. APIs as a product https://www.thoughtworks.com/radar/techniques/apis-as-a-product
  3. Falcor https://netflix.github.io/falcor/
  4. GraphQL http://graphql.org/
  5. A new actor in the API world http://blog.octo.com/en/graphql-a-new-actor-in-the-api-world/
  6. Apollo client http://dev.apollodata.com/react/
  7. Subscription via web socket https://github.com/apollographql/subscriptions-transport-ws
Interested in partnering with us?

Send a message and we will work with you to understand your needs.

UX360 - Enterprise Journey Mapping Platform

Power Platform

UX360 - Enterprise Journey Mapping Platform
Related Insights from Our Experts

2018-02-05T09:37:16+00:00