Finqware API
  • Quick start
  • Overview
    • Skills
    • Servicers
    • Tenants
    • Security model
      • Tenant-level elements
      • User-level elements
  • Dev guide
    • Intro
    • User onboarding
      • Detailed flow
    • Consuming data
      • About caching
    • Designing a tenant app
      • The back-end
      • The front-end
    • Signing API requests
      • RS256 infrastructure
      • Computing the digest
      • Signing HTTP requests
  • API
    • Sessions
    • Tokens
    • Accounts
    • Balances
    • Transactions
    • Payments
    • Consents
    • Catalogs
    • Errors
Powered by GitBook
On this page
  1. Dev guide

Designing a tenant app

As mentioned before, building an application on top of Finqware means in general that you have to build a front-end (web/mobile) and a backend. It is unsafe to build a client-only app unless it will run on trusted devices.

It will be possible to build your app entirely on the backend though. This is targeted to enterprise applications.

The example architecture presented here is following a pattern mainly used by native mobile apps and web applications that render data inside the browser:

  • the back-end handles the main database, business logic, sensitive information, communication with 3rd party APIs (eg: Finqware) etc. It also exposes a private API (eg: REST or GraphQL) that is available only to a known front-end. It may be developed in any popular language (eg: Java, PHP, NodeJS etc).

  • the front-end is an application developed with Android, Swift, JavaScript (React, Angular etc). It only consumes data from its own backend. It initiates external API calls only in exceptional situations. An example Js/React app is running at https://play.finqware.com/.

NOTE: Classic architectures based on server-side rendering (PHP, JSP etc) are perfectly possible but here we chose a more generic example that applies to both mobile & web front-end types. The data model and state management still apply.

What the Finqware API is not

We do not offer at the moment a backend-less solution. That means there is work to be done in your own backend:

  • user management

  • extra processing of data (eg: custom data transformations)

  • caching for improving your SLAs

PreviousAbout cachingNextThe back-end

Last updated 3 years ago